stdout_logfile and stderr_logfile should be created as user specified in program section

[benmccann]

I have supervisord running as root. I've set a user in my program section as well as stdout_logfile and stderr_logfile. However, those two files are being created as root and not as the user that owns the process. It's strange to me that the user I've specified should be able to kill the process, but not read the log files. It would be very nice if there were a chown option for the log files.

Mailing list thread on the issue indicates others have run into this as well: http://lists.supervisord.org/pipermail/supervisor-users/2012-May/001069.html

[mnaberez]

Related: #107

supervisord run as root automatically puts the logs of processes, even those run as user, into /var/log/supervisor/ as root:root 0600 -- which is quite unfortunate if you'd like to start user processes at boot, and still have the user to be able to read the logs of the processess.

I'd propose you to implement a configfile directive to either setting the user or the permissions on thesestdout/stderr-logfiles. Ideally settable in the "program:"-section.

[budlight]

I basically don't use supervisord for this exact reason

[rockfruit]

You can use the stdout_logfile setting to point to a location on which the setgid or setuid flags have been set.

[adamlwatson]

+1 this would be a very welcome addition.

[neuromusic]

+1 for me this isn't just about log files... the processes which I am running from supervisor (using the user= option) are ipython shells from which users need to be able to save arbitrary files in any location which they have permissions on the server. however, anything that gets saved follows the root umask rather than the user's umask or user/group-specific ACL

my expected behavior is for processes run as a user to act like that user is running the process themselves

[carlcarl]

Want this feature, too.

[galindro]

+1 I don't understand why there is an option that permits a process to run with another user and supervisor is creating the log file of that process with the user that supervisor was started (in my case, root user) not by the user the process was started!

What is suggested by @rockfruit will not works because the files are created by the user that supervisor was started, using with these permissions: 0644 (-rw-r--r--), even if you set another umask value, like 0077. If I set SGID and/or SUID bits on /var/log/supervisor for example, it will not works because the files will only assume the same group and/or user of the parent directory, not the permissions of the parent directory.

I think the better solution for this case, until the supervisor code is updated by developers, is to set ACLs to the directory in which the log files will be placed. But I don't know if it is supported by all know *UNIX filesystems...

[Codefor]

+1

[thiagomgo]

+1

[tehfink]

This seems to still be an issue (FreeBSD 11.2 & Supervisor 3.3.3).

[qiulang]

I am using 4.2.1 and still have this problem. So it seems that, just as https://github.com/Supervisor/supervisor/issues/123 said "we celebrate the 10 year anniversary of this bug"

-rw-r--r-- 1 root root 5468 Jun 21 12:07 horizon.log

BUT

[program:laravel-worker]
user=www-data
process_name=%(program_name)s_%(process_num)02d
command=/usr/local/bin/php /var/www/html/artisan horizon
autostart=true
autorestart=true
redirect_stderr=true
stderr_logfile=/var/www/html/storage/logs/horizon_err.log
stdout_logfile=/var/www/html/storage/logs/horizon.log