43

Supervisor is running on 3.0:

pip freeze | grep supervisor
supervisor==3.0

When starting supervisord from the command line:

sudo $VIRTENV/supervisord --nodaemon --configuration $PATH_TO_CONFIG/supervisord.conf

I get this error:

2013-11-11 23:30:50,205 CRIT Supervisor running as root (no user in config file)

But I can't start supervisord without sudo, it complains:

Error: Cannot open an HTTP server: socket.error reported errno.EACCES (13)

What is the right way to deal with it?

(I get the same error if starting it as root but setting user = foobar under the [supervisord] section in supervisord.conf)

Update: Here is my supervisord.conf

[unix_http_server]
file = /opt/run/supervisord.sock

[inet_http_server]
port = 9001
username = foobar
password = foobar

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisord]
logfile = /opt/logs/supervisord.log
loglevel = debug
pidfile = /opt/run/supervisord.pid

[supervisorctl]

[program:foo1]
user = foobar
autostart = True
autorestart = True
command = foo1
stdout_logfile = /opt/logs/foo1.stdout.log
stderr_logfile = /opt/logs/foo1.stderr.log
stdout_logfile_maxbytes = 10MB
stderr_logfile_maxbytes = 10MB

[program:foo2]
user = foobar
autostart = true
autorestart = true
command = foo2
priority = 100
stdout_logfile_backups = 0
stderr_logfile_backups = 0
stdout_logfile_maxbytes = 10MB
stderr_logfile_maxbytes = 10MB
stdout_logfile = /opt/logs/foo2.stdout.log
stderr_logfile = /opt/logs/foo2.stderr.log
kev
  • 8,928
  • 14
  • 61
  • 103
  • Are you sure you want to start another copy of the `supervisord` daemon, rather than running `supervisorctl` or something? What exactly are you trying to do here? – abarnert Nov 11 '13 at 23:42
  • I don't try to start multiple copies of supervisord, just one. As I wrote, I am confused. Starting supervisord as root gives me a CRIT, but I can't start it as non-root. – kev Nov 12 '13 at 00:20
  • Does it work when you remove the [inet_http_server] section? – pors Feb 19 '14 at 18:29
  • I am wondering the same thing. The doc is not clear on that and seeing the CRIT error makes me wonder as well if it's not better to run supervisor with a supervisor user created for this purpose. What did you end up doing? Thanks. – Michael Oct 09 '14 at 13:51
  • 1
    **TL;DR** set `user=root` in `supervisord.conf`. ([Explanation](https://stackoverflow.com/a/47566747/4528364)) – Kyan Nov 30 '17 at 05:55

5 Answers5

28

Supervisord switches to UNIX user account before any processing.

You need to specify what kind of user account it should use, run the daemon as root but specify user in the config file

Example:

[program:myprogram]
command=gunicorn --worker-class socketio.sgunicorn.GeventSocketIOWorker app.wsgi:application -b 127.0.0.1:8000
directory=/opt/myprogram
user=user1
autostart=true
autorestart=true
redirect_stderr=True

Visit http://supervisord.org/configuration.html#program-x-section-values for more information

Jan Vorcak
  • 19,261
  • 14
  • 54
  • 90
  • I'm doing that now, but it still says "CRIT Supervisor running as root (no user in config file)" when starting supervisord. – kev Nov 12 '13 at 00:23
  • @user1252307: Have you actually specified a user in the config file, as in javo's example? Because the error message seems to be saying that you haven't. (Maybe you've put it in the wrong section, or made a silly typo?) – abarnert Nov 12 '13 at 01:10
  • I just double checked with the config above (I replaced the program names) – kev Nov 12 '13 at 04:47
15

When you start supervisor as root, you need to specify a user for supervisor to drop to for security reasons

From the supervisor docs (http://supervisord.org/configuration.html):

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.

Put this in your conf file:

[supervisord]
user=nobody

The user should be a user which exists, but does not have sudo permissions (nobody can work).

Rylan
  • 151
  • 3
  • 5
  • 7
    This prevented supervisor from being able to save to the logfile which required root level permissions. – nu everest May 26 '14 at 01:06
  • 3
    Alternatively you can use `logfile=/path/to/logfile` to specify the directory to save the logfile, and make sure the user you drop to has permission to write to that directory. You also don't need to drop to nobody, you may drop to ubuntu, or a similar user. – Rylan May 26 '14 at 22:10
  • You can change the log dir permission and it'll stick. But the init.d script keeps overwriting the /var/run/supervisord owner to root, which makes supervisord fail to start when started from the init.d script (at least on OpenSUSE). – Artem Russakovskii Sep 13 '17 at 22:49
  • 1
    Ah, /usr/lib/tmpfiles.d/supervisord.conf is responsible for the dir creation. Change the user there from root to "nobody." `D /run/supervisord 0700 nobody nobody` – Artem Russakovskii Sep 13 '17 at 22:51
  • Hi Rylan, can you explain why the user should not have sudo permissions? I set user=nobody, then got error like "supervisor: couldn't setuid to 0: Can't drop privilege as nonroot user". – Jzou Jul 02 '18 at 16:33
  • Hi @JialinZou, you would prefer for the user to not have sudo permissions because it reduces your attack surface. If supervisor runs as root an attacker may be able to take over your system if supervisor is compromised. It may not ever happen, but the rule-of-thumb for UNIX systems is to avoid running things as root, if possible, for this exact reason. The error you're seeing is because you're not starting supervisor as root (using sudo). If you're not starting supervisor as root then you don't need the `user=nobody` line and should remove it. – Rylan Jul 10 '18 at 14:42
14

For me, I received this error while running as a non-root user:

Error: Cannot open an HTTP server: socket.error reported errno.EACCES (13)

This went away after I chowned the directory holding the sock file to that user.

In your case:

[unix_http_server]
file = /opt/run/supervisord.sock

Either chown username /opt/run/, or point the file to another directory that is owned by the user.

I learned this approach from this link.

Additionally, my sysadmins installed an init.d script I wrote. The init.d script is run as root, but the script can get supervisord to start on myuser with this command:

SUPERVISORD=/path/to/supervisord
PIDFILE=/path/to/supervisord.pid
OPTIONS='-c /path/to/supervisord.conf'
daemon --pidfile=$PIDFILE --user=myuser $SUPERVISORD $OPTIONS
Matthew Moisen
  • 16,701
  • 27
  • 128
  • 231
12

You got:

Per my understanding, you got this CRIT message which is bothering you:

CRIT Supervisor running as root (no user in config file)

The words in brackets is a clue. This message indicates that you may be running Supervisor as root unintentionally.

Do this:

So the solution is pretty simple: Tell Supervisor that you are doing this intentionally.
(in /etc/supervisor/supervisord.conf)

[supervisord]
user = root

Once you run Supervisord as root, it sets uid to the user you assigned, which is, root. (#308)

Not important:

Although now you may get this message:

CRIT Set uid to user 0

No worries, this message should be a INFO level rather than a CRIT level. (#693)

Kyan
  • 383
  • 3
  • 7
1

My environment :

Homestead+laravel ubuntu18 LTS

I had the same problem,
Be sure to control that the file belongs to the correct owner.

1.Starting supervisor must use root

example:

vagrant@homestead:~$ sudo supervisord -c /etc/supervisord.conf
vagrant@homestead:~$ ps -aux|grep supervisord
root     12145  0.0  0.8  71144 16744 ?        Ss   07:20   0:00 /usr/bin/python /usr/bin/supervisord -c /etc/supervisord.conf

you may kill all processing of supervisor and re-run

2.Try not to use root run job.

My job conf is /etc/supervisor/conf.d/lara*.conf,user is vagrant

my job conf

chown log file to vagrant,involve file related supervisor.conf

my supervisor conf

then

run supervisorctl status use vagrant

job run

zzr
  • 11
  • 3