logrotate (?) screws it badly
Hi guys.
I run off distro's vanilla-default logrotate, like so:
```
/var/log/nginx/*log {
daily
rotate 10
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null`
2>/dev/null || true
endscript
}
```
and I wonder...
if it is logrotate's _fault_ or perhaps I screwed Nginx's
configs somewhere? For after logs got rotated Nginx logs into:
access.log.1 & error.log.1
and now as it should, you know
access.log & error.log
many thanks, L.___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
wordpress - Primary script unknown
Hi guys.
This must be trivial - I certainly thought - but it confused
the hell out of me:
I'm doing - what many must have done before me - this:
...
root /var/www/ale.xyx_wordpress;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires max;
log_not_found off;
}
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
index index.php index.html index.htm;
location ~ \.(php|phar)(/.*)?$ {
fastcgi_split_path_info ^(.+\.(?:php|phar))(/.*)$;
fastcgi_intercept_errors on;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
#fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass php-fpm;
}
# upstream
upstream php-fpm {
server unix:/run/php-fpm/www.sock;
}
when I go to web root, Nginx logs:
...
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
copy: "SERVER_PORT"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
var: "443"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "SERVER_PORT: 443"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
copy: "SERVER_NAME"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
var: "ale.xyz"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "SERVER_NAME: ale.xyz"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
copy: "REDIRECT_STATUS"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
copy: "200"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "REDIRECT_STATUS: 200"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
copy: "SCRIPT_FILENAME"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
var: "/var/www/ale.xyx_wordpress"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 http script
var: "/index.php"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "SCRIPT_FILENAME: /var/www/ale.xyx_wordpress/index.php"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_HOST: ale.xyz"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_CACHE_CONTROL: max-age=0"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_UPGRADE_INSECURE_REQUESTS: 1"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_USER_AGENT: Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0
Safari/537.36"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_ACCEPT:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_SEC_GPC: 1"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_ACCEPT_LANGUAGE: en-GB,en;q=0.9"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_SEC_FETCH_SITE: none"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_SEC_FETCH_MODE: navigate"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_SEC_FETCH_USER: ?1"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_SEC_FETCH_DEST: document"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_ACCEPT_ENCODING: gzip, deflate, br"
2023/08/03 13:50:24 [debug] 1112963#1112963: *27 fastcgi
param: "HTTP_COOKIE:
wordpress_test_cookie=WP%20Cookie%20check;
wp-settings-time-1=1686766849;
PHPSESSID=caa771c30b66d7bf6c86ab15b132479f"
...
and eventually:
...
2023/08/03 13:50:24 [error] 1112963#1112963: *27 FastCGI
sent in stderr: "Primary script unknown" while reading
response header from upstream, client: 10.3.9.144, server:
ale.xyz, request: "GET / HTTP/2.0", upstream:
"fastcgi://unix:/run/php-fpm/www.sock:", host: "ale.xyz"
...
This is pretty much vanilla-default on Centos 9, those
configs are - what am I missing?
I hope it's be trivial for some people here and I could get
some pointers.
many thanks, L.___
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
Re: listen on IPs but do not fail if one is absent - ?
On 03/08/2022 10:54, Igor Ippolitov wrote: Hello, I would give a try to 'net.ipv4.ip_nonlocal_bind' sysctl knob. Set it to true and bind() won't fail. Regards, Igor. Does the trick for Nginx too! wielkie! dzięki L. ___ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org
Re: listen on IPs but do not fail if one is absent - ?
On 13/02/2022 11:24, Francis Daly wrote: On Sun, Feb 13, 2022 at 07:56:16AM +, lejeczek via nginx wrote: On 12/02/2022 13:26, Francis Daly wrote: On Sat, Feb 12, 2022 at 10:11:25AM +, lejeczek via nginx wrote: Hi there, having multiple 'listen' with IPs or, just one 'listen' with a hostname which resolves to more than one IP - is it possible to tell Nginx not fail when one of IPs is absent, does not exist? I think that stock nginx does not support that. There are possibly ways to avoid the failure; but they all fundamentally are different ways to do "only bind to locally-existing addresses". I can confess I return to Nginx after long many years of a divorce and this curious fact - if Nginx cannot do that - will be a surprise to me. Use cases tend to be addressed when a developer has the incentive to write the code. If the feature that you are hoping for, has not been implemented in a way that you are hoping for, then probably no-one cared enough to ensure that it was done in that way. Which amazes me a bit - I'd think that in this age of clouds/virtualization/containers etc. removing iface or IP or both(even hot-plugin hardware) is something what must happen often, if not daily - why people would not need that 'feature' and not think it's silly of Nginx to fail for that reason? - amazes me. Certainly this use case where IP does not exists - perhaps different case would be where IP does exist but cannot be bound to - should be allowed & easy to give to end users an option to "bind" to such non-existent IP with 'continue/remain/insist' or however devel want to call. I read people replies and think they thought it was about 'port' in my case, but I tried to make it clear it's the IP/iface - so "*" does not address the issue I described. many thanks, L. I thought such a "feature" would be in Nginx by now, if not devised by developers than included by popular demand - looking at the options/params to 'listen', something like 'remain' or 'insist' which would instruct Nginx to start & continue to work and hook onto the IP when/after it appeared(but also continue to work after IP disappeared) As Maxim indicates in the parallel reply: nginx will not fail if it does not try to bind() to a non-existing address:port. And you can arrange that, by making sure that your "listen ip:port" directive does not include any of the parameters that require a bind(); and by making sure that, for each port that you listen on, there is also a "listen *:port"-equivalent directive somewhere in the config. So possibly the feature that you want already exists with restrictions that you are happy to work within? Cheers, f ___ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org
Re: listen on IPs but do not fail if one is absent - ?
On 12/02/2022 13:26, Francis Daly wrote: On Sat, Feb 12, 2022 at 10:11:25AM +, lejeczek via nginx wrote: Hi there, having multiple 'listen' with IPs or, just one 'listen' with a hostname which resolves to more than one IP - is it possible to tell Nginx not fail when one of IPs is absent, does not exist? I think that stock nginx does not support that. There are possibly ways to avoid the failure; but they all fundamentally are different ways to do "only bind to locally-existing addresses". Cheers, f I can confess I return to Nginx after long many years of a divorce and this curious fact - if Nginx cannot do that - will be a surprise to me. I thought such a "feature" would be in Nginx by now, if not devised by developers than included by popular demand - looking at the options/params to 'listen', something like 'remain' or 'insist' which would instruct Nginx to start & continue to work and hook onto the IP when/after it appeared(but also continue to work after IP disappeared) thanks, L. ___ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org
listen on IPs but do not fail if one is absent - ?
Hi guys a novice here so go easy on me with this question: having multiple 'listen' with IPs or, just one 'listen' with a hostname which resolves to more than one IP - is it possible to tell Nginx not fail when one of IPs is absent, does not exist? many thanks, L. ___ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org
