# Issue/Bug with USR1 signal, and unnecessary chowning of log files **URL:** \ **Category:** NGINX\ **Created:** [October 18, 2010, 2:37pm UTC](https://www.ruby-forum.com/t/issue-bug-with-usr1-signal-and-unnecessary-chowning-of-log-files/197655 "2010-10-18T14:37:05Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Dobai-Pataky\_BSSSSl](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/77aa72/32.png) [@Dobai-Pataky\_BSSSSl](https://www.ruby-forum.com/u/Dobai-Pataky_BSSSSl)\ **Post date:** [October 18, 2010, 2:37pm UTC](https://www.ruby-forum.com/t/issue-bug-with-usr1-signal-and-unnecessary-chowning-of-log-files/197655/1 "2010-10-18T14:37:05Z")
I have found that when sending USR1 signal to Nginx that Nginx chowns the log files even if log files already exist and are already writable (but have different user/group). Let me elaborate on the situation: Nginx runs as www-data for its user/group, in a virtual hosting environment. I use Webmin/Virtualmin to create the logs, and handle log rotation in an automated manner. Log files exist like follows: ```auto -rw-rw---- 1 domain1 www-data 0 Oct 18 11:06 domain1.com_access_log -rw-rw---- 1 domain1 www-data 0 Oct 18 11:06 domain1.com_error_log -rw-rw---- 1 domain2 www-data 0 Oct 18 11:19 domain2.org_access_log -rw-rw---- 1 domain2 www-data 0 Oct 18 11:19 domain2.org_error_log ``` These are located centrally and then symlinked to from the domain user’s home folder. Now, for instance, AWStats runs for each domain user, under the domain user’s user/group. This works just fine, for now. Now, the logrotate script for each domain rotates the files, creating a new, empty file with the same permissions and owner/group. But if I send a post-logrotate USR1 signal to Nginx, it will chown the log files to www-data/www-data, even though it does not need to, since the files are already writable given that the log files maintain their 0660 permissions, and are in the www-data group. I of course can not feasibly chown these log files back manually, or even in an automated way, and elevated run permissions (have to jump all the way to root) for AWStats are out of the question. The problem then is that once Nginx chowns the log files to www-data/www-data, the domain user can no longer read/write these files for anything. I think that Nginx should first test for log file existence, then if so, test for writability. Then, if the log file is already writable, NOT chown the log file, as there is no point. It is of course not as simple as checking that either user or group match with Nginx user/group, since in my case www-data has all domain user groups as secondary groups, so technically the log files do not even need the www-data group (domain2/domain2 would work just fine). Anyway, it seemed that Nginx sometimes needlessly chowns the log files, and was wondering if this was intentional, an oversight, or an outright bug that should be fixed. For one, this bug then is only present when log files are kept at 0660 or higher. I would think fixing it would not affect any people negatively, unless of course they have made the assumption that the log files will be chowned. If there are in fact any reasons that Nginx must always chown the log files, even if they are already writable under their current pemissions/ownership, I would like to know as well (so I can better my understanding of Nginx :)) Thank you Posted at Nginx Forum: > **[Issue/Bug with USR1 signal, and unnecessary chowning of log files](https://forum.nginx.org/read.php?2,141866,141866#msg-141866)** > > I have found that when sending USR1 signal to Nginx that Nginx chowns the log files even if log files already exist and are already writable (but have different user/group). Let me elaborate on the situation: Nginx runs as www-data for its...