After an update from supervisor 3.0 to 3.2 (happened while upgrading 14.04 to 16.04), our configuration we use for supervisor doesn't seem to work properly any more.
The default supervisor configuration is completely unchanged and the only important parameter in there is:
[include]
files = /etc/supervisor/conf.d/*.conf
In the conf.d directory there are two files; one that is only used on this system and one that symlinks into the application directory, so we can use the same configuration across installations.
000-generic-environment.conf
[supervisord]
directory = /home/applicationuser/domains/<domain>/current
001-programs.conf (symlink to /home/applicationuser/domains//current/supervisord.conf)
[program:push-notifications]
rabbitmq:consumer device_notifications --env=prod --no-debug -m 100
autorestart = true
user = applicationuser
command = bin/console rabbitmq:consumer device_notifications --env=prod --no-debug -m 100
When I start supervisor, the only thing the log says is:
supervisord[11599]: 2018-06-21 08:00:16,549 INFO spawnerr: can't find command 'bin/console'
It tries a few times and then decides to go into FATAL state because of the retries. This setup has always worked for us, but now seems to be broken. Am I overlooking something here? I have been breaking my head on this issue for a while now and I could use some fresh eyes on the matter.
I eventually found the issue. I noticed in the documentation that the directory parameter is only used when daemonizing.
In supervisor 3.0, this was the default; apparently after upgrading ubuntu and supervisor, this default behaviour got changed and supervisor ran with the -n flag on the command line.
Removing this flag in systemd crashed the daemon for some reason, while running supervisord from the commandline worked perfectly. Chosing the easy way out because I wanted to continue with more important stuff, I downgraded supervisor to 3.0 and everything worked like a charm again.