CRIT Can't drop privilege as nonroot user

[ngton]

If I understand correctly, this is being generated because supervisord is started as a non-root user and the user parameter is specified in the config file.

As per the documentation:

user

If supervisord is run as the root user, switch users to this UNIX user account before doing any meaningful processing. This value has no effect if supervisord is not run as root.

If run as a non-root user, this parameter should not then cause a CRIT message in the logs when supervisord is working as designed.

[mnaberez]

If run as a non-root user, this parameter should not then cause a CRIT message in the logs when supervisord is working as designed.

You have run supervisord as non-root. At the same time you have asked it to drop privileges by specifying user=, which it can't do because it is non-root. This is not a valid configuration.

You can comment out user= if you want to run it as the current user, and it will not log this message.

[ngton]

Hang on, the docs do not say this is an invalid configuration, quite the opposite. "This value has no effect if supervisord is not run as root"

Therefore it should not attempt to switch user and not generate a CRIT message. I believe this issue has been closed incorrectly.

[mnaberez]

I think the existing behavior is much more sane than just ignoring it would be. You asked to switch users by specifying user=, but supervisord can't switch users because it was not started as root, so you got a message logged saying it can't. If you don't want that error message, don't set user=.

It would be fine to clarify the docs to mention the log message, so I'll leave this open as a docs issue.

[ngton]

This isn't a docs issue.

The logical extension of what you're saying is that supervisord cannot be configured to be able to run as root and non-root. I don't think this is either intended or desirable. Why cripple functionality like that?

The real problem here is that supervisord is running wrong code path. It should not attempt to change user and should simply ignore user= when running as non-root, as per the docs.

[mnaberez]

The logical extension of what you're saying is that supervisord cannot be configured to be able to run as root and non-root. I don't think this is either intended or desirable. Why cripple functionality like that?

I can't see where you are coming from with this statement. supervisord works fine when run as root or as non-root, and many people run it both ways.

If you started supervisord as non-root, you can't switch users with user= in the config file. It can't switch users because the operating system won't allow it to do that unless it is root. Remove user= and you won't get the message.

The real problem here is that supervisord is running wrong code path. It should not attempt to change user and should simply ignore user= when running as non-root, as per the docs.

Running the wrong code path would be trying to setuid when non-root and failing. It doesn't do that. If you set user= in the config file, then supervisord checks if it is running as root. If it's not, then it logs a message telling you it can't switch the user like you asked it to do.

[ngton]

What I mean is that what if you want to be able to run supervisord as root and non-root without configuration changes. The docs are clear that this is possible. "This value has no effect if supervisord is not run as root"

There is no way this should be CRIT message.

[mnaberez]

Sorry but I'm not going to keep going around and around on this. I'm fine admitting the docs aren't perfect and can make an update to clarify that it logs this message. Your configuration file asked it to switch users, it can't because it's not root, so it logged the message saying it can't do what you asked. I'm not going to change that.

[ngton]

Well at least don't make it a CRIT. This doesn't require "immediate user attention". The product is working as designed