New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
oschaaf opened this Issue Sep 19, 2014 · 34 comments

Comments

Projects
None yet
8 participants
@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

This comment has been minimized.

Copy link

centminmod commented Sep 22, 2014

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

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

This comment has been minimized.

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

logging: delay factory init so we log to error.log
Prevent logging to stdout/stderr

Fixes #808

oschaaf added a commit that referenced this issue Sep 26, 2014

logging: delay factory init so we log to error.log
Prevent logging to stdout/stderr

Fixes #808
@oschaaf

This comment has been minimized.

Copy link
Member

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

logging: delay factory init so we log to error.log
Prevent logging to stdout/stderr, make sure we log to error.log for
early messages during initialization.

Fixes #808
@msva

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

oschaaf commented Sep 27, 2014

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

@oschaaf

This comment has been minimized.

Copy link
Member

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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

This comment has been minimized.

Copy link
Member

oschaaf commented Sep 29, 2014

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

@msva

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

centminmod commented Oct 3, 2014

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

centminmod commented Oct 4, 2014

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

This comment has been minimized.

Copy link

msva commented Oct 4, 2014

systemctl

@msva

This comment has been minimized.

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

This comment has been minimized.

Copy link

centminmod commented Oct 4, 2014

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

logging: init logging early, hand ProxyFetchFactory correct server log
- 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 oschaaf closed this in #818 Oct 16, 2014

@Mr-Anonymous

This comment has been minimized.

Copy link

Mr-Anonymous commented Oct 31, 2014

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

Mr-Anonymous commented Oct 31, 2014

Perfect. Thank you @crowell

oschaaf added a commit that referenced this issue May 13, 2015

logging: init logging early, hand ProxyFetchFactory correct server log
- 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

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Dec 17, 2015

Looks like this is back.

@jeffkaufman

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Dec 17, 2015

@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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Dec 17, 2015

Fixed in 37e1c36

@mysexyDate24com

This comment has been minimized.

Copy link

mysexyDate24com commented Jun 20, 2017

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

This comment has been minimized.

Copy link
Member

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 .
@mysexyDate24com

This comment has been minimized.

Copy link

mysexyDate24com 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

This comment has been minimized.

Copy link
Member

oschaaf commented Jun 21, 2017

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

@mysexyDate24com

This comment has been minimized.

Copy link

mysexyDate24com commented Jun 21, 2017

Great, that fixed it. Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment