Supervisor: Unable to specify log file owner or permissions

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.

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

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

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

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

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)

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

Any resolution to this?

oh supervisord.

Just another user looking for exactly the same thing!

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

+1 please - this is a pretty big deal

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. ;)

+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 ( https://github.com/Supervisor/supervisor/issues/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

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:

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

@sidnei should there be a chmod after mkstemp here ?

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

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.

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

:cry:

+1

Yes please! +1

+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!

+1

+1

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

:'(

:+1:

+1

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

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

+1

+1

Hi guys,
you can run your command as following:

command= bash -c "your_command first_param second_param 2> error_file.txt > stdout.txt"

and REMOVE these tags:

redirect_stderr
stderr_logfile
stdout_logfile

@BahmaniAlireza: sure we can. but then we'll miss these goodies features... :(
stderr_logfile_maxbytes
stderr_logfile_backups
stderr_capture_maxbytes

+1

+1

+1

When is this going to be fixed????

When is this going to be fixed????

when it annoys someone enough that they dont work around it externally and
they submit a PR... :)

+1

+1

I found that using setgid looks to be decent method of getting some of the functionality we want to see from the (non-functional) umask parameter in supervisor. In my case I needed logs from programs managed by supervisor to be visible to a log aggregator, so I used setgid to make that happen: like this:
chmod u=rwx,go=rx,a+s /var/log/myapplogs/

Then in the supervisor configs, I just had to set logfile, user, pidfile, stdout_logfile, stdout_events_enabled (true), stderr_logfile, stderr_events_enabled (true), etc.

Sample setup: https://gist.github.com/jpsandiego/a7927d14fc23efc0eae049d1466656b0

To everyone leaving separate comments for +1, thumbs up, etc.: FUCK OFF.

Seriously, the issues section is a developer tool, and all you are doing is annoying the developers (and the rest of us) by spamming all of us with your useless message. I really don't understand why it's necessary to school you on this basic fact of etiquette. If you have nothing useful to add, simply thumbs-up the issue and move along.

(Sorry to everyone for this spam, but this issue has gotten out of control.)

"To everyone leaving separate comments for +1, thumbs up, etc"
...
"If you have nothing useful to add, simply thumbs-up the issue and move along."

Just to FUCK OFF back - reactions (which is the thumbs up you are referring to) were added in march of 2016. https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

That's almost FOUR YEARS after this issue was started. Prior to that moment in time (and I'll note that I actually hadn't noticed the feature was added yet) the proper and only way to thumbs up an issue was a comment.

If you don't like people upvoting, CLOSE THE ISSUE. It's open, so presumably the development team has interest in this - and we the users expressing interest in it still care too.

If you represent the development team, and feel that it's not something that will ever be resolved, then state that and close it. If you dont, unsubscribe. :)

So, FUCK OFF.

Indeed.

Ryan FUCK OFF

On 10/01/17 17:18, david raistrick wrote:
>

"To everyone leaving separate comments for +1, thumbs up, etc"
...
"If you have nothing useful to add, simply thumbs-up the issue and
move along."

Just to FUCK OFF back - reactions (which is the thumbs up you are
referring to) were added in march of 2016.
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

That's almost FOUR YEARS after this issue was started. Prior to that
moment in time (and I'll note that I actually hadn't noticed the
feature was added yet) the proper and only way to thumbs up an issue
was a comment.

If you don't like people upvoting, CLOSE THE ISSUE. It's open, so
presumably the development team has interest in this - and we the
users expressing interest in it still care too.

If you represent the development team, and feel that it's not
something that will ever be resolved, the state that and close it.

So, FUCK OFF.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-271686060,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzKDJ3bty9ezBMMR8ObCeV_8hIazqPTks5rQ-edgaJpZM4AA4dF.

+1

+1

+1

+1

On 12/01/17 06:31, Eugen Ivanov wrote:
>

+1

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-272115994,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzKDKMUhFVHCN1C03WXOSUsuRSmv48Tks5rRfMMgaJpZM4AA4dF.

Hey everyone, first of all I don't approve being aggressive when talking on forums, for whatever reason, as we all deserve respect and it's obvious that no one here means any harm but show that this issue affects many people. However, @keen99 has a valid point, I have subscribed to this issue a while back and every time I get a notification I wonder "wow, do we have any valid news on that?" but then I open it and find a +1 😞 .

By hitting subscribe and giving thumbs up on the first comment of the issue, in my opinion is a more productive way to show interest, since it's way more visual to how many people have the same problem.

That said, doing +1s will not make the maintainers of the project go any faster with the issue as we already have many +1s and this wasn't fixed (obviously they don't have to, whoever is deeply affected is free to open a pull request as with any OSS). But in my opinion this bothers many subscribers for no real good reason and no benefit taken.

I hit this and probably don't know what I'm doing, but setgid and setting umask in [supervisord] and in the init script didn't do the trick. I'm probably going to go with the magical syslog value for logfile settings:
stdout_logfile=syslog stderr_logfile=syslog
And wrangle things from the there. This isn't the first (and I doubt the last) time I personally solved permissions issues for log aggregation by just using syslog. Works fine!

+1

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:

https://github.com/Supervisor/supervisor/issues/114
https://github.com/Supervisor/supervisor/issues/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.

@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!).

@lukeburden, thanks, we will do that.

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

@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.

@mristin that would do the trick for me too.

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

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.

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!

@keen99 +1