Unable to specify log file owner or permissions

[lra]

When I start supervisor, the log files of my programs have 0600 permissions, while the supervisor.log is 0644.

ubuntu@sentry:/var/log/supervisor$ ls -l /var/log/supervisor/
total 20
-rw------- 1 root root 7975 May 31 18:54 sentry_celeryd-stderr---supervisor-1gPFQa.log
-rw------- 1 root root    0 May 31 18:16 sentry_celeryd-stdout---supervisor-dZn9PW.log
-rw------- 1 root root 4561 May 31 19:02 sentry-stderr---supervisor-GUllAv.log
-rw------- 1 root root    0 May 31 18:16 sentry-stdout---supervisor-8HXvhm.log
-rw------- 1 root root    0 May 31 18:16 sentry_udp-stderr---supervisor-uAlO19.log
-rw------- 1 root root    0 May 31 18:16 sentry_udp-stdout---supervisor-PhobKI.log
-rw-r--r-- 1 root root 4039 May 31 18:16 supervisord.log

How can I specify another umask that will be applied to program's logs ?

[sidnei]

Apparently the problem is that in AUTO mode the logfiles are created with mkstemp, which has very restrictive perms by default. If you specify the stdout/stderr logfile explicitly the logfiles are created with the expected permissions.

[fzaninotto]

I did specify the stdout/stderr files explicitly, they still use the root user rather than the one specified in the program conf.

[jpauli]

Same here, and the umask is always x77 so log files get created by root with 600 and are not readable by others, this is a problem for me

[cmbuckley]

I have in supervisord.conf:

[supervisord]
logfile=/var/log/supervisord/supervisord.log
user=supervisor
umask=022

and in conf.d/foo.conf:

stdout_logfile=/var/log/supervisord/%(program_name)s-stdout.log
stderr_logfile=/var/log/supervisord/%(program_name)s-stderr.log

The directory /var/log/supervisord is present and owned by supervisor. This results in 3 log files:

-rw-r--r-- 1 supervisor supervisor   0 2013-02-20 19:26 foo-stderr.log
-rw-r--r-- 1 supervisor supervisor  82 2013-02-20 19:29 foo-stdout.log
-rw-r--r-- 1 supervisor supervisor 649 2013-02-20 19:29 supervisord.log

[jpauli]

Not for me, I tried this in the [supervisord] section and in each conf.d/* file for each process to launch, with no success, supervisord keeps creating log files with 600 perms. It seems to work for the main log file supervisord.log though, which seem to honor my umask param

[palmkevin]

I do have a similar problem. I have set a umask 000 at SV and process level, nevertheless all log files are created with a mask of 022.
(I do not use the AUTO mode)
(I also have the problem for the supervisor's log file)

[mnaberez]

Related: #312, requesting an option to set the log owner.

[pandeiro]

Any resolution to this?

[yeago]

oh supervisord.

[jonnywilliamson]

Just another user looking for exactly the same thing!

[grvhi]

Setting user=<user> on the supervisord program works for me... All logs are chown'd to that user by supervisord.

[HelloGrayson]

+1 please - this is a pretty big deal

[gkertai]

We were also struggling with this. The workaround we came up with involves pre-creating all log files as part of our deployment process before supervisord restarts. Basically we run a grep | awk | xargs (touch ; chown; chmod) command against the supervisor configs. This works fine as long as the logs don't rotate, which they rarely do.

A nicer solution would be appreciated though. ;)

[neuroticnerd]

+1
As @gkertai mentioned, we also have to do a lot of provisioning and double-checking in our deploy process to be able to use supervisor (such as pre-creating log files with correct permissions), and that really just feels cumbersome. That includes having to make sure that the main log file directories exist ( #120 ), just so that supervisord will even start to run anything, or not take down a bunch of processes with it. I really like the idea of Supervisor, and I loathe the thought of having to maintain Upstart or initd scripts, but using Supervisor in a production environment thus far has not proved to be as reliable as we would like. Cleaner handling of log files would go a long way, and be much appreciated, especially the creation of the main log file directory (I can understand not creating program log directories, but I wholeheartedly feel like the main log directory for supervisord itself should be its responsibility). At the very least I feel like it should fall back to a default log location that is expected to always be accessible (e.g. /tmp/supervisord.log) so that warning messages about the lack of existence of the desired log directory are easily accessible

[netsamir]

For me, the best solution was to change the umask in the parent process:

#!/usr/bin/env bash

umask 0000
supervisord -c supervisord.conf

The child process will inherit the umask of the parent process, as a result all files that will be created will have the good permissions:

-rw-rw-rw-

[mnaberez]

You can also set the umask using the umask= option in the [supervisord] section of the config file.

[schemacs]

@sidnei should there be a chmod after mkstemp here ?

[jschilling1]

similar problem here, crazy this hasn't been deal with yet

[program:test1]
user = user1
stdout_logfile = user1.log

correctly starts the app as user1 but creates user1.log as root
instead of user1, this seems more like a bug than an enhancement

[o10g]

And +1 from me.
Looks like it's a bug, as I don't expect that if you specify user in program:x section logfiles will be created from root.

[keen99]

oh the fun of +1'ing a 3 year old unresolved issue.

😢

[mdelaney]

+1

[cmsimike]

Yes please! +1

[lukeburden]

+1 - had log rotation happen and a range of services flip out with permissions errors on the log file handles .. and sure enough the shiny new log files are owned by root. Nasty surprise!

[patrickhulce]

+1

[liminspace]

+1

[slotlocker2]

It is sad to see so many people resorting to clumsy workarounds. nginx handles this really well.
+1

:'(

[marinpurgar]

👍

[elsmorian]

+1

[coleplx]

+1. I don't think anyone will ever fix it.

[mirfilip]

@coleplx keep +1ing. If that's not gonna get fixed, we'll at least create a nice community here ^_^

[tehfink]

+1

[mristin]

We are using supervisor on our machines to monitor and control the processes. We would like to improve the security of our instances and noticed that it is not possible to easily change the permissions of the log files. Here are the other relevant issues:

#114
#107

Is somebody working on these or related issues?

What about having a separate, global configuration field called stdout_log_user and stdout_log_permissions (likewise for stderr_*) that would let the user specify who owns the logs (e.g., only root) and with what permissions (e.g., 0o600)?

You could have these fields in the program sections as well to override the global one if necessary.

If nobody is working on this issue, our team at Parquery AG would be glad to help and make a pull request. Please let me know what the next steps would be.

[lukeburden]

@mristin I'd suggest submitting a PR and using your own fork until it is merged in here .. which may take some time as it seems this project suffers from a lack of active contributors (not finger-pointing, I haven't got time to jump in and contribute either, sadly!).

[mristin]

@lukeburden, thanks, we will do that.

Could some of the users interested in the feature quickly confirm that our proposal would suit them?

[lukeburden]

@mristin that would do the trick in my case. I'd use the program level settings to ensure when log rotation happens on my celery process that the new log files are owned by the right user celery and that the perms are appropriate. At the moment, supervisor creates the new log files as root, and then the celery process cannot write to the new log file.

My only additional thought is that it might be a good idea to have a setting to allow specification of group as well? This might be important for some people's configuration.

[easydevmixin]

@mristin that would do the trick for me too.

I can also help you test it if you need me to.

[gkirkpatrick]

I know this is old, but I was having a hard time getting supervisor to NOT rotate logs, and apparently, at some point the config name for the setting that turns that off changed from "logfile_maxbytes" to "stdout_logfile_maxbytes".

What I found to get around the changing of logfile permissions back to root was that turning off supervisors log rotation and using logrotate did the trick. However, if the files grow fast enough logrotate will fire off because of the file size.

Maybe this helps somebody.

[tonnelj]

Hi all,

I found this answer on this topic : http://supervisor-users.10397.x6.nabble.com/Supervisor-users-Changing-owner-of-log-files-td4945286.html

By creating the log file with the desired user (like the one who owns the supervisor child process), the ownership is kept during the supervisor process.

Hope that helps!

Best regards and stay safe!

[NickstaDB]

@keen99 +1

[alterEgo123]

+1

[alterEgo123]

I hope this gets fixed before the end of time

[lijinglin3]

+1

[vlad4ernyshov]

+1

[arifai]

Yup +1

[kirov117]

I guess we'll soon celebrate the 10 year anniversary of this bug.

[ekoka]

I think this bug is old enough that, short of fixing it, it could at least be mentioned in the documentation, for the sake of saving people time when they're faced with it. Debugging mysterious behavior can be an incredible time pit and silence about a well known and explainable issue is akin to tacit misleading.

[rgallart101]

I think this bug is old enough that, short of fixing it, it could at least be mentioned in the documentation, for the sake of saving people time when they're faced with it. Debugging mysterious behavior can be an incredible time pit and silence about a well known and explainable issue is akin to tacit misleading.

Agreed, if it was a child would be in 5th grade right now...

[kissifrot]

We will soon reach max 32-bit Unix time limit 😅

[gkirkpatrick]

I feel like we should have a party somewhere to celebrate this bug. I know that microsoft has had bugs in Excel for like 30 years, but they're terrible.

My ultimate solution to this was to stop using supervisor. the benefits of using it just didn't outweigh the fact that I had to go so deep into log rotation, that I still feel the need 5 years after I stopped using it to point out how annoying this bug is.

[Sophist-UK]

As an alternative to everyone whining about this not being fixed, how about someone coding a PR to fix it?

Edit: That said, looking at the PR list suggests that this project is a one man project, with the owner / developer uninterested in accepting functional improvement PRs and only working on maintaining support for e.g. current versions of Python and fixing bugs (like recent #1597). I guess it might be time for someone to fork this project and create a more responsive, community supported version.

[keen99]

Edit: That said, looking at the PR list suggests that this project is a one man project, with the owner / developer

yeah, a few years after this was opened the project appears to have lost half of it's active devs. sad, considering how heavily used this project still is.

perhaps it's time to replace chris with someone more active? (even if this is getting pretty far off the original topic...)

[Sophist-UK]

This was a useful tool when it was first launched, but in recent years since Docker has become so prevalent its usefulness has grown substantially. So it is indeed a pity that it is "functionally stabilised".

This is one of the major problems of open source generally - that the owner can lose interest and then evolution stalls unless someone takes the major step of publicly forking the project (as opposed to forking the repo).

[gkirkpatrick]

To bring it back somewhat to the topic of this bug, there was no right way to deal with this, although better ways exist. Sure the logs being created having the wrong user permissions was straight up wrong, but probably the best answer was just to take out log rotation entirely and just leave it to another and better tool.

But with open source things, Sophist is 100% correct, this is a long term issue. Lots of previously useful tools have their utility start to fail, and their documentation often remains locked in time. I've taken to first thing just going right to the Issues part of github to see if the repo is still actively being worked on and then scroll down to the oldest issues to see what's there.

[NickstaDB]

To get this back on track...

+1

[mostafaznv]

first upvote of 2024 for this issue +1

[BarnabasSzabolcs]

Maybe it is time to move on to pm2?

https://pm2.keymetrics.io/

It was created for node, but as I found out it can handle anything, including a startup script for django. I've been using it for some of my django websites already without problem.