Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

Log: [info] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite. #808

Closed
oschaaf opened this issue Sep 19, 2014 · 35 comments · Fixed by #818
Closed

Log: [info] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite. #808

oschaaf opened this issue Sep 19, 2014 · 35 comments · Fixed by #818

Comments

@oschaaf
Copy link
Member

oschaaf commented Sep 19, 2014

Not a real problem, but the message isn't very helpful -- or actually seems to raise concerns.
Perhaps the message can be degraded to debug instead of info level.

@centminmod
Copy link

yes it would be great if there's an option to hide or disable verbose info messages like this. It's confusing quite a few users

@jsamuel
Copy link

jsamuel commented Sep 23, 2014

Unfortunately, we (ServerPilot) are going to have to skip 1.9.32.1 because of this message. We don't have time to build PSOL from source to remove this message and it's not an option for us to push out an nginx build to all of our users that will issue this warning. We know from past experience how much concern unnecessary debugging messages like this will create among our users.

@ghost
Copy link

ghost commented Sep 24, 2014

@jsamuel That is ridiculous; if your users are so sensitive that they can't handle a debug message, and instead would rather settle for a reduced quality of optimization (provided for free I might add), then you either need to provide more education on the subject or stop providing services to children.

@oschaaf
Copy link
Member Author

oschaaf commented Sep 24, 2014

@jsamuel Would an option to filter messages at the configuration level have helped here?
E.g. something like pagespeed MessageFilter "No threading detected*"?

@jsamuel
Copy link

jsamuel commented Sep 24, 2014

@alicemargatroid My comment was not meant to disrespect the developers or their efforts in any way. Rather, I felt they should know that in certain use cases, these types of messages have more impact on users than they may realize. I'm always glad when users of my software let me know when something small I may have overlooked is very important to them.

@jsamuel
Copy link

jsamuel commented Sep 24, 2014

@oschaaf An option to filter messages would not be a great solution for us. We don't mind informational messages going to the nginx log. The problem for us is when there are noncritical messages going to stdout/stderr when nginx is starting.

oschaaf added a commit that referenced this issue Sep 26, 2014
Prevent logging to stdout/stderr

Fixes #808
oschaaf added a commit that referenced this issue Sep 26, 2014
Prevent logging to stdout/stderr

Fixes #808
@oschaaf
Copy link
Member Author

oschaaf commented Sep 26, 2014

#815 sends messages that get logged early during initialization to error.log

oschaaf added a commit that referenced this issue Sep 26, 2014
Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization.

Fixes #808
@msva
Copy link

msva commented Sep 27, 2014

@oschaaf nah. It produces segfault (if nginx built without debug) or SIGABRT if nginx is built with debug info:

(gdb) cont
Continuing.
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

Program received signal SIGSEGV, Segmentation fault.
0x082d55b9 in ?? ()
(gdb) bt
#0  0x082d55b9 in ?? ()
#1  0x082daec4 in ?? ()
#2  0x082db6ce in ?? ()
#3  0x08173d39 in net_instaweb::NgxRewriteDriverFactory::~NgxRewriteDriverFactory() ()
#4  0x08173ea0 in net_instaweb::NgxRewriteDriverFactory::~NgxRewriteDriverFactory() ()
#5  0x0816d239 in ?? ()
#6  0x0808c9a2 in ngx_init_cycle ()
#7  0x0807d41a in main ()
(gdb) cont
Continuing.
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: third_party/chromium/src/base/memory/scoped_ptr.h:376: T* scoped_ptr<T, D>::operator->() const [with T = net_instaweb::SystemCaches, D = base::DefaultDeleter<net_instaweb::SystemCaches>]: Assertion `impl_.get() != __null' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff2c025c5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff2c025c5 in raise () from /lib64/libc.so.6
#1  0x00007ffff2c03a48 in abort () from /lib64/libc.so.6
#2  0x00007ffff2bfb6b2 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff2bfb762 in __assert_fail () from /lib64/libc.so.6
#4  0x000055555597c413 in scoped_ptr<net_instaweb::SystemCaches, base::DefaultDeleter<net_instaweb::SystemCaches> >::operator-> (this=0x555556fa6618) at third_party/chromium/src/base/memory/scoped_ptr.h:376
#5  0x0000555555977fef in net_instaweb::SystemRewriteDriverFactory::StopCacheActivity (this=0x555556fa6230) at net/instaweb/system/system_rewrite_driver_factory.cc:448
#6  0x0000555555977d7a in net_instaweb::SystemRewriteDriverFactory::ShutDown (this=0x555556fa6230) at net/instaweb/system/system_rewrite_driver_factory.cc:457
#7  0x00005555557844e0 in net_instaweb::NgxRewriteDriverFactory::~NgxRewriteDriverFactory() ()
#8  0x0000555555784629 in net_instaweb::NgxRewriteDriverFactory::~NgxRewriteDriverFactory() ()
#9  0x000055555577dcae in net_instaweb::(anonymous namespace)::ps_init_module(ngx_cycle_s*) ()
#10 0x000055555566bbfb in ngx_init_cycle ()
#11 0x000055555565978a in main ()

ngx info, if any:

# nginx -V
nginx version: nginx/1.7.5
TLS SNI support enabled
configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --with-file-aio --with-aio_module --with-ipv6 --with-pcre --with-pcre-jit --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_spdy_module --with-http_stub_status_module --with-http_sub_module --with-http_xslt_module --with-http_realip_module --add-module=ext/ngx_devel_kit-0.2.19 --add-module=ext/set-misc-nginx-module-0.26 --add-module=ext/echo-nginx-module-0.56 --add-module=ext/memc-nginx-module-0.15 --add-module=ext/lua-nginx-module-25c4bdd6b68e54f241fff9018ec4aa7a65426b31 --add-module=ext/lua-upstream-nginx-module-0.02 --add-module=ext/replace-filter-nginx-module-0.01rc5 --add-module=ext/encrypted-session-nginx-module-0.03 --add-module=ext/headers-more-nginx-module-0.25 --add-module=ext/srcache-nginx-module-0.28 --add-module=ext/rds-json-nginx-module-0.13 --add-module=ext/rds-csv-nginx-module-0.05 --add-module=ext/ngx_postgres-1.0rc5 --add-module=ext/ngx_coolkit-0.2rc1 --add-module=ext/ngx_pagespeed-762b05ed7816ff649580a6e87576e2e5a8925a6a --add-module=ext/passenger-release-4.0.52/ext/nginx --add-module=ext/nginx-push-stream-module-0.4.0 --add-module=ext/ngx_ctpp2-0.5 --add-module=ext/ngx_supervisord-1.4 --add-module=ext/xss-nginx-module-0.04 --add-module=ext/array-var-nginx-module-0.03 --add-module=ext/form-input-nginx-module-0.10 --add-module=ext/iconv-nginx-module-0.10 --add-module=ext/ngx-fancyindex-0.3.4 --add-module=ext/nginx-upload-progress-module-0.9.1 --add-module=ext/ngx_cache_purge-2.1 --add-module=ext/nginx-ey-balancer-0.0.8 --add-module=ext/ngx_slowfs_cache-1.10 --add-module=ext/nginx_upstream_check_module-0.1.9 --add-module=ext/ngx_metrics-0.1.1 --add-module=ext/naxsi-0.53-2/naxsi_src --add-module=ext/nginx-dav-ext-module-0.0.3 --add-module=ext/ngx_http_auth_pam_module-1.3 --add-module=ext/nginx-rtmp-module-5fb4c99ca93442c571354af6a40a4f3ef736af57 --with-http_ssl_module --with-google_perftools_module --add-module=ext/mod_rrd_graph-0.2.0 --add-module=ext/nginx-goodies-nginx-sticky-module-ng-bd312d586752 --add-module=ext/nginx_ajp_module-0.3.0 --with-mail --with-mail_ssl_module --user=web --group=web

@oschaaf
Copy link
Member Author

oschaaf commented Sep 27, 2014

@msva Ouch - thanks for letting me know! Back to the drawing board.
At which point does this happen? After a reload?

@oschaaf
Copy link
Member Author

oschaaf commented Sep 27, 2014

@msva Never mind, I can reproduce it - looking into it.

@oschaaf
Copy link
Member Author

oschaaf commented Sep 27, 2014

I closed #815, as it looks like a different approach is needed to accomplish forwarding log messages emitted during PageSpeed's configuration/initialisation phase to error.log.

oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init NgxServerContext's NgxMessageHandler to the correct
server{} - specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init NgxServerContext's NgxMessageHandler to the correct
server{} - specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init NgxServerContext's NgxMessageHandler to the correct
server{} - specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init NgxServerContext's NgxMessageHandler to the correct
server{} - specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init NgxServerContext's NgxMessageHandler to the correct
server{} - specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init NgxServerContext's NgxMessageHandler to the correct
server{} - specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init NgxServerContext's NgxMessageHandler to the correct
server{} - specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init NgxServerContext's NgxMessageHandler to the correct
server{} - specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init ProxyFetchFactories's NgxMessageHandler to the correct
server{} specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
@oschaaf
Copy link
Member Author

oschaaf commented Sep 29, 2014

@msva #818 should work better, could you try it?

@msva
Copy link

msva commented Sep 29, 2014

I tried. Firstly I decided it is okay, sinde id doesn't crash on nginx -t anymore.
Although, it still (or now) segfaults on "normal" start:

(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7f57940 (LWP 12060)):
#0  0x00005555558ca516 in net_instaweb::SystemCaches::StopCacheActivity() ()
#1  0x00005555558cff20 in net_instaweb::SystemRewriteDriverFactory::ShutDown() ()
#2  0x0000555555769430 in net_instaweb::NgxRewriteDriverFactory::~NgxRewriteDriverFactory() ()
#3  0x0000555555769579 in net_instaweb::NgxRewriteDriverFactory::~NgxRewriteDriverFactory() ()
#4  0x0000555555762d3e in net_instaweb::(anonymous namespace)::ps_init_module(ngx_cycle_s*) ()
#5  0x000055555566840b in ngx_init_cycle ()
#6  0x000055555565698a in main ()

+debug:

nginx: third_party/chromium/src/base/memory/scoped_ptr.h:376: T* scoped_ptr<T, D>::operator->() const [with T = net_instaweb::SystemCaches, D = base::DefaultDeleter<net_instaweb::SystemCaches>]: Assertion `impl_.get() != __null' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff2c025c5 in raise () from /lib64/libc.so.6
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7f57940 (LWP 8384)):
#0  0x00007ffff2c025c5 in raise () from /lib64/libc.so.6
#1  0x00007ffff2c03a48 in abort () from /lib64/libc.so.6
#2  0x00007ffff2bfb6b2 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff2bfb762 in __assert_fail () from /lib64/libc.so.6
#4  0x000055555597c3f3 in scoped_ptr<net_instaweb::SystemCaches, base::DefaultDeleter<net_instaweb::SystemCaches> >::operator-> (this=0x555556fa6628) at third_party/chromium/src/base/memory/scoped_ptr.h:376
#5  0x0000555555977fcf in net_instaweb::SystemRewriteDriverFactory::StopCacheActivity (this=0x555556fa6240) at net/instaweb/system/system_rewrite_driver_factory.cc:448
#6  0x0000555555977d5a in net_instaweb::SystemRewriteDriverFactory::ShutDown (this=0x555556fa6240) at net/instaweb/system/system_rewrite_driver_factory.cc:457
#7  0x00005555557844c0 in net_instaweb::NgxRewriteDriverFactory::~NgxRewriteDriverFactory() ()
#8  0x0000555555784609 in net_instaweb::NgxRewriteDriverFactory::~NgxRewriteDriverFactory() ()
#9  0x000055555577dc2e in net_instaweb::(anonymous namespace)::ps_init_module(ngx_cycle_s*) ()
#10 0x000055555566bbfb in ngx_init_cycle ()
#11 0x000055555565978a in main ()

@oschaaf
Copy link
Member Author

oschaaf commented Sep 29, 2014

@msva Thanks for having a look. I tested it manually carefully, and I it did pass the system tests and all for me. Yet it looks like I missed a flow. I'll have another look.

oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init ProxyFetchFactories's NgxMessageHandler to the correct
server{} specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
oschaaf added a commit that referenced this issue Sep 29, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init ProxyFetchFactories's NgxMessageHandler to the correct
server{} specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
@oschaaf
Copy link
Member Author

oschaaf commented Sep 29, 2014

@msva I updated #818 again. Just to make sure I catch them all this time, could you try one more time to see if this catches your case as well?

@msva
Copy link

msva commented Sep 29, 2014

yeah. Now it don't segfaults anymore ;)

// at least, at NgX start. But I'd test it to work fine in runtime for few days to be sure ;)

@centminmod
Copy link

interestingly, I only get the info notices on nginx restart for CentOS 6.5. Not getting any for CentOS 7.0 https://community.centminmod.com/threads/ngx_pagespeed-version-1-9-32-1.1427/#post-7225 ?

for both OS, Nginx is source compiled in the same manner with similar config options

@oschaaf
Copy link
Member Author

oschaaf commented Oct 3, 2014

@centminmod Are the nginx versions you tested the same for both? It looks like nginx 1.7.4 (nginx/nginx@1176952#diff-3fc9671d2e2bca2ceae49931fc0cc960L387) has a change that will change behaviour.

@centminmod
Copy link

same Nginx 1.7.6 versions source compiled

on CentOS 6.5

nginx -V
nginx version: nginx/1.7.6
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) 
TLS SNI support enabled
configure arguments: --with-cc-opt='-I/svr-setup/staticlibssl/include -I/usr/include' --with-ld-opt='-L/svr-setup/staticlibssl/lib -Wl,-rpath -lssl -lcrypto -ldl -lz' --sbin-path=/usr/local/sbin/nginx --conf-path=/usr/local/nginx/conf/nginx.conf --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_sub_module --with-http_addition_module --with-http_image_filter_module --with-http_secure_link_module --with-http_flv_module --with-http_realip_module --with-http_geoip_module --with-openssl-opt=enable-tlsext --add-module=../ngx-fancyindex-ngx-fancyindex --add-module=../ngx_cache_purge-2.1 --add-module=../headers-more-nginx-module-0.25 --add-module=../nginx-accesskey-2.0.3 --add-module=../nginx-http-concat-master --with-http_dav_module --add-module=../nginx-dav-ext-module-0.0.3 --with-openssl=../openssl-1.0.1i --with-libatomic --with-pcre=../pcre-8.35 --with-pcre-jit --with-http_spdy_module --add-    module=../ngx_pagespeed-release-1.9.32.1-beta

restart

[1004/040356:INFO:google_message_handler.cc(35)] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite.
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
Stopping nginx:                                            [  OK  ]
Starting nginx: [1004/040356:INFO:google_message_handler.cc(35)] No threading detected. Own threads: 1 Rewrite, 1 Expensive     Rewrite.
                                                           [  OK  ]

on CentOS 7.0

nginx -V
nginx version: nginx/1.7.6
built by gcc 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) 
TLS SNI support enabled
configure arguments: --sbin-path=/usr/local/sbin/nginx --conf-path=/usr/local/nginx/conf/nginx.conf --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_sub_module --with-http_addition_module --with-http_image_filter_module --with-http_secure_link_module --with-http_flv_module --with-http_realip_module --with-openssl-opt=enable-tlsext --add-module=../ngx-fancyindex-ngx-fancyindex --add-module=../ngx_cache_purge-2.1 --add-module=../headers-more-nginx-module-0.25 --add-module=../nginx-accesskey-2.0.3 --add-module=../nginx-http-concat-master --with-http_dav_module --add-module=../nginx-dav-ext-module-0.0.3 --add-module=../openresty-memc-nginx-module-1518da4 --add-module=../openresty-srcache-nginx-module-ffa9ab7 --add-module=../nginx-sticky-module-1.2.5 --add-module=../nginx_upstream_check_module-0.1.9 --with-openssl=../openssl-1.0.1i --with-libatomic --with-pcre=../pcre-8.35 --with-pcre-jit --with-http_spdy_module --add-module=../ngx_pagespeed-    release-1.9.32.1-beta

restart

Restarting nginx (via systemctl):                          [  OK  ]

@msva
Copy link

msva commented Oct 4, 2014

systemctl

@msva
Copy link

msva commented Oct 4, 2014

I mean, it (SystemD) intercepts stdio of services it run. That's why you do not see this, as you will not see critical fail on stderr (which you'd see on systemd-less system) until you run systemctl status nginx or journalctl -xn.

@centminmod
Copy link

thanks @msva for that info, explains why CentOS 7 doesn't show the info messages.. now all we need to do is hide it for CentOS 6 :)

oschaaf added a commit that referenced this issue Oct 9, 2014
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init ProxyFetchFactories's NgxMessageHandler to the correct
server{} specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
@Mr-Anonymous
Copy link

Hi @oschaaf I am also getting the same message when I test my nginx:

[1031/211301:INFO:google_message_handler.cc(35)] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite.

Since I see this ticket is closed, does it mean that it has been fixed in the next version or do we just ignore it since its just a debug message and I dont think it is causing any issues in anyways?

I get this message only when I test nginx using nginx -t. It doesnt show when I reload, start, stop, etc.. I have the following:

Debian 7.7
Nginx 1.6.2

Thanks.

@crowell
Copy link
Contributor

crowell commented Oct 31, 2014

This has been fixed in 1.9.32.2
On Oct 31, 2014 11:57 AM, "Neel" notifications@github.com wrote:

Hi @oschaaf https://github.com/oschaaf I am also getting the same
message when I test my nginx:

[1031/211301:INFO:google_message_handler.cc(35)] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite.

Since I see this ticket is closed, does it mean that it has been fixed in
the next version or do we just ignore it since its just a debug message and
I dont think it is causing any issues in anyways?

I get this message only when I test nginx using nginx -t. It doesnt show
when I reload, start, stop, etc.. I have the following:

Debian 7.7
Nginx 1.6.2

Thanks.


Reply to this email directly or view it on GitHub
#808 (comment)
.

@Mr-Anonymous
Copy link

Perfect. Thank you @crowell

oschaaf added a commit that referenced this issue May 13, 2015
- Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization. Note that nginx is still working
to setup its logging configuration, so these early messages will go
through its defaults. Which means that only warnings or worse will pass
for early logging messages.
- Make sure we init ProxyFetchFactories's NgxMessageHandler to the correct
server{} specific log so it will write to the error_log configured
in the server{} block instead of the global error_log.

Fixes #808
Helps #817
@jeffkaufman jeffkaufman reopened this Dec 17, 2015
@jeffkaufman
Copy link
Contributor

Looks like this is back.

@jeffkaufman
Copy link
Contributor

@oschaaf would you be able to look at this one? I'd like to put a fix for this in 1.10.33.2.

@oschaaf
Copy link
Member Author

oschaaf commented Dec 17, 2015

@jeffkaufman The following pull fixes the problem thoroughly, but introduces a smaller one where we log vague lines like

flush
.

#1071

@jeffkaufman
Copy link
Contributor

Fixed in 37e1c36

@Gonzo2O28
Copy link

Hello everybody, i am getting this again:

No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite.
2017/06/20 17:44:02 [info] 3378#3378: pagespeed: rollback gzip, explicit configuration in /etc/nginx/common.conf:37
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Server: nginx 1.13.1 with pagespeed and brotli
Domain: https://mysexydate24.com/en-DE
OS: archlinux, latest
OpenSSL 1.1.0f 25 May 2017

@oschaaf
Copy link
Member Author

oschaaf commented Jun 21, 2017

@mysexyDate24com testing the latest stable ngx_pagespeed release on ubuntu 14.04, I can't confirm a regression of this issue.

What version of ngx_pagespeed are you running? Does it help if you set the log level to warn?

oschaaf@ubuntu:/usr/local/nginx/sbin⟫ sudo  ./nginx -V
nginx version: nginx/1.13.1
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) 
configure arguments: --add-module=/home/oschaaf/ngx_pagespeed-latest-stable

oschaaf@ubuntu:/usr/local/nginx/sbin⟫ sudo  ./nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

tail of error.log shows the messages do end up there (with the log level set info):

2017/06/21 13:12:41 [info] 55579#0: [ngx_pagespeed 1.12.34.2-0] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite.
2017/06/21 13:12:41 [info] 55579#0: pagespeed: rollback gzip, explicit configuration in /usr/local/nginx/conf/nginx.conf:36
2017/06/21 13:12:41 [info] 55579#0: [ngx_pagespeed 1.12.34.2-0] SharedMemCache: pagespeed_default_shm/metadata_cache, sectors = 128, entries/sector = 2226,  64-byte blocks/sector = 4452, total footprint: 52445184
2017/06/21 13:12:41 [info] 55579#0: [ngx_pagespeed 1.12.34.2-0] Initializing shared memory for path: /tmp/npsinstalled/ flush .

@Gonzo2O28
Copy link

Gonzo2O28 commented Jun 21, 2017

ngx_pagespeed-1.12.34.2-beta

--prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/bin/nginx --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --user=http --group=http --build='smartMedia' --http-log-path=/var/log/nginx/access.log --error-log-path=stderr --http-client-body-temp-path=/var/lib/nginx/client-body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-pcre-jit --with-file-aio --with-http_auth_request_module --with-http_secure_link_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_ssl_module --with-openssl-opt=”enable-tlsext” --with-http_stub_status_module --with-http_v2_module --with-stream --with-stream_ssl_module --with-threads --without-http_autoindex_module --without-http_scgi_module --without-http_split_clients_module --without-http_ssi_module --without-http_userid_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-cc-opt='-O3 -march=native -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=native -DTCP_FASTOPEN=23' --with-ld-opt='-Wl,-z,relro -Wl,-E' --add-module=/tmp/nginx/ngx_brotli --add-module=/tmp/nginx/ngx_pagespeed-1.12.34.2-beta

@oschaaf
Copy link
Member Author

oschaaf commented Jun 21, 2017

@mysexyDate24com you have --error-log-path=stderr, which is what triggers it.

@Gonzo2O28
Copy link

Great, that fixed it. Thank you very much!

@dungvaph03374
Copy link

nginx version: nginx/1.10.3
pagespeed version: ngx-1.13.35.1-beta

built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
built with OpenSSL 1.0.2g 1 Mar 2016
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin/nginx --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads --add-module=/root/incubator-pagespeed-ngx-1.13.35.1-beta

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
9 participants