Question about rotating log files with USR1 signal

Fabiano Furtado Pessoa Coelho fusca14 at gmail.com
Tue Jul 19 21:59:32 UTC 2022


Thanks!

This ticket https://trac.nginx.org/nginx/ticket/376 is exactly my doubt.

You helped me a lot.


On Tue, Jul 19, 2022 at 12:17 AM Maxim Dounin wrote:
>
> Hello!
>
> On Mon, Jul 18, 2022 at 01:37:47PM -0300, Fabiano Furtado Pessoa Coelho wrote:
>
> > As described in the official documentation
> > http://nginx.org/en/docs/control.html#logs "The master process will
> > then re-open all currently open log files and assign them an
> > unprivileged user under which the worker processes are running, as an
> > owner.", the owner of the log file changes after the USR1 signal is
> > sent to NGINX master process.
> >
> > Why does this behavior happen? Is there a way to keep the original
> > root owner of the log file?
>
> Log files owned by root generally cannot be open by worker
> processes for writing.  To make sure worker processes can reopen
> the log files, master process chowns them and ensures appropriate
> permissions for the owner.
>
> Unless you are willing to run nginx worker processes under root
> (which is unwise), there is no way to preserve the root as the
> owner of log files during fast log rotation.
>
> If for some reason you must keep root as the owner of log files,
> using reconfiguration instead of log rotation might work.
> Obviously enough, this isn't a good solution either.
>
> A better solution for reopening log files would be to implement
> file descriptor passing on systems which support it, see
> https://trac.nginx.org/nginx/ticket/376.  So far attempts to
> implement this did not result in a reasonably reliable code.
>
> > The "systemctl reload nginx" is capable of creating a new log file
> > with the original root owner, but I think this isn't a clever
> > solution.
>
> More importantly, this won't work.  By pre-creating log files you
> can fine-control permissions on the files, but during log rotation
> nginx will change the owner anyway.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org



More information about the nginx mailing list