Problem description
Recently, the author encountered some problems when configuring supervisor and hoping to use supervisor for process service management, specifically:
- When running
supervisorctl status, I encountered the problem ofunix:///var/run/supervisor/supervisor.sock no such file. - I encountered the following error when running
sudo service supervisor status
sudo service supervisor status
● supervisor.service - Supervisor process control system for UNIX
Loaded: loaded (/lib/systemd/system/supervisor.service; enabled; vendor >
Active: activating (auto-restart) (Result: exit-code) since Thu 2023-10->
Docs: http://supervisord.org
Process: 190236 ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supe>
Main PID: 190236 (code=exited, status=2)
CPU: 249ms
Generally speaking, there is something wrong with the supervisor.
Reproduction process and solution
The following error occurred when querying supervisor status:
sudo service supervisor status
● supervisor.service - Supervisor process control system for UNIX
Loaded: loaded (/lib/systemd/system/supervisor.service; enabled; vendor >
Active: activating (auto-restart) (Result: exit-code) since Thu 2023-10->
Docs: http://supervisord.org
Process: 190236 ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supe>
Main PID: 190236 (code=exited, status=2)
CPU: 249ms
According to the information displayed by status, the Supervisor service is currently active and set to restart automatically. The primary PID (Process ID) is shown as 190236, indicating that the service exited with exit code 2.
Exit code 2 usually indicates an error. In order to determine the specific problem, check the logs of the Supervisor service. The logs may provide more detailed information about why the service failed to start.
You can view the logs of the Supervisor service by running the following command:
sudo journalctl -u supervisor.service
This command will display logs related to the Supervisor service. Look for any error messages or clues to help determine the problem.
The log output looks like this:
September 28 02:35:20 zeeland-virtual-machine systemd[1]: Started Supervisor proces> September 28 02:35:21 zeeland-virtual-machine supervisord[36451]: 2023-09-28 02:35:> September 28 02:35:21 zeeland-virtual-machine supervisord[36451]: 2023-09-28 02:35:> September 28 02:35:21 zeeland-virtual-machine supervisord[36451]: 2023-09-28 02:35:> September 28 02:35:21 zeeland-virtual-machine supervisord[36451]: 2023-09-28 02:35:> September 28 02:35:21 zeeland-virtual-machine supervisord[36451]: 2023-09-28 02:35:> September 28 03:09:14 zeeland-virtual-machine systemd[1]: Stopping Supervisor proce> September 28 03:09:15 zeeland-virtual-machine supervisorctl[38468]: Shut down September 28 03:09:15 zeeland-virtual-machine systemd[1]: supervisor.service: Deact> September 28 03:09:15 zeeland-virtual-machine systemd[1]: Stopped Supervisor proces> -- Boot 4f9509fffa594d7b8b1d628356c22065 -- September 28 03:09:36 zeeland-virtual-machine systemd[1]: Started Supervisor proces> September 28 03:09:37 zeeland-virtual-machine supervisord[895]: 2023-09-28 03:09:37> September 28 03:09:37 zeeland-virtual-machine supervisord[895]: 2023-09-28 03:09:37> September 28 03:09:37 zeeland-virtual-machine supervisord[895]: 2023-09-28 03:09:37> September 28 03:09:37 zeeland-virtual-machine supervisord[895]: 2023-09-28 03:09:37> September 28 03:09:37 zeeland-virtual-machine supervisord[895]: 2023-09-28 03:09:37> September 28 05:21:44 zeeland-virtual-machine systemd[1]: Stopping Supervisor proce>
You can see in the log when the supervisor started and when it stopped, but you cannot view the specific error information. Next, I directly used supervisorctl status to check whether the service started normally. The results were as follows:
unix:///var/run/supervisor/supervisor.sock no such file
As you can see, a new error has occurred here. supervisorctl has not been started, and supervisord must not have been started, so I went to the official website to read the documentation.
The tutorial on the official website says to use $BINDIR/supervisord to start supervisord. Here $BINDIR should be replaced with the actual path of the directory containing the supervisorod executable file. For example, if the supervisorord executable is located in the /usr/local/bin directory, the command would be /usr/local/bin/supervisord.
Enter ls /usr/bin | grep supervisor to confirm whether the file exists.
echo_supervisord_conf supervisorctl supervisord zeeland@zeeland-virtual-machine:/etc/supervisor$
So we ran /usr/bin/supervisord directly. At this time, I got the following error:
zeeland@zeeland-virtual-machine:/var/run/supervisor$ /usr/bin/supervisord
Error: Format string 'kubectl --context %(ENV_KUBECTL_CONTEXT)s port-forward -n babel-system services/babel-controller 8080:80' for 'program:port-forward-ctrl.command' contains names ('ENV_KUBECTL_CONTEXT') which cannot be expanded. Available names: ENV_AMENT_PREFIX_PATH, ENV_COLORTERM, ENV_DBUS_SESSION_BUS_ADDRESS, ENV_DESKTOP_SESSION, ENV_DISPLAY, ENV_GDMSESSION, ENV_GIO_LAUNCHED_DESKTOP_FILE, ENV_GIO_LAUNCHED_DESKTOP_FILE_PID, ENV_GJS_DEBUG_ OUTPUT, ENV_GJS_DEBUG_TOPICS, ENV_GNOME_DESKTOP_SESSION_ID, ENV_GNOME_SETUP_DISPLAY, ENV_GNOME_SHELL_SESSION_MODE, ENV_GTK_MODULES, ENV_HOME, ENV_IBUS_DISABLE_SNOOPER, ENV_IM_CONFIG_PHASE, ENV_INVOCATION_ID, ENV_JOURNAL_STR EAM, ENV_LANG, ENV_LANGUAGE, ENV_LC_ADDRESS, ENV_LC_IDENTIFICATION, ENV_LC_MEASUREMENT, ENV_LC_MONETARY, ENV_LC_NAME, ENV_LC_NUMERIC, ENV_LC_PAPER, ENV_LC_TELEPHONE, ENV_LC_TIME, ENV_LD_LIBRARY_PATH, ENV_LESSCLOSE, ENV_LESSOPEN, ENV_LOGNAME, ENV_LS_COLO RS, ENV_MANAGERPID, ENV_OLDPWD, ENV_PATH, ENV_PWD, ENV_PYTHONPATH, ENV_QT_ACCESSIBILITY, ENV_QT_IM_MODULE, ENV_ROS_DISTRO, ENV_ROS_LOCALHOST_ONLY, ENV_ROS_PYTHON_VERSION, ENV_ROS_VERSION, ENV_SESSION_MANAGER, ENV_SHELL, ENV_SHLVL, ENV_SSH_AGENT_LAUNCHER, ENV_SSH_AUTH_SOCK, ENV_SYSTEMD_EXEC_PID, ENV_TERM, ENV_TERMINATOR_DBUS_NAME, ENV_TERMINATOR_DBUS_PATH, ENV_TERMINATOR_UUID, ENV_USER, ENV_USERNAME, ENV _VTE_VERSION, ENV_WAYLAND_DISPLAY, ENV_XAUTHORITY, ENV_XDG_CONFIG_DIRS, ENV_XDG_CURRENT_DESKTOP, ENV_XDG_DATA_DIRS, ENV_XDG_MENU_PREFIX, ENV_XDG_RUNTIME_DIR, ENV_XDG_SESSION_CLASS, ENV_XDG_SESSION_DESKTOP, ENV_XDG_SE SSION_TYPE, ENV_XMODIFIERS, ENV__, group_name, here, host_node_name, numprocs, process_num, program_name in section 'program:port-forward-ctrl' (file: '/etc/supervisor/conf.d/babel.conf')
For help, use /usr/bin/supervisord -h
This is the port mapping I need to configure. I have /etc/supervisor/conf.d/babel.conf below. %(ENV_KUBECTL_CONTEXT)s is used in conf as variable.
Since this variable is not recognized, just change it to an actual value.
You can configure variables like this in supervisor conf, but I haven’t found the variable %(ENV_KUBECTL_CONTEXT)s yet. Where did I declare it before? I’ll look for it later when I have the energy.
kubectl --context %(ENV_KUBECTL_CONTEXT)s port-forward -n babel-system services/babel-controller 8080:80
Therefore, after I deleted the variables in conf, I could start normally after running /usr/bin/supervisord.
Enter sudo service supervisor status and it will start normally.
zeeland@zeeland-virtual-machine:/etc/supervisor$ sudo service supervisor status
● supervisor.service - Supervisor process control system for UNIX
Loaded: loaded (/lib/systemd/system/supervisor.service; enabled; vendor >
Active: active (running) since Thu 2023-10-19 19:15:57 CST; 1min 26s ago
Docs: http://supervisord.org
Main PID: 255641 (supervisord)
Tasks: 238 (limit: 28698)
Memory: 327.6M
CPU: 43.548s
CGroup: /system.slice/supervisor.service
├─255641 /usr/bin/python3 /usr/bin/supervisord -n -c /etc/superv>
├─255708 kubectl --context kind-babelcloud port-forward -n babel>
├─255709 kubectl --context kind-babelcloud port-forward -n babel>
├─255715 kubectl --context kind-babelcloud port-forward -n babel>
├─255716 kubectl --context kind-babelcloud port-forward -n babel>
├─255723 kubectl --context kind-babelcloud port-forward -n babel>
But in fact, if you want to use services for management, this is problematic.
Optimization measures
/usr/bin/supervisord is a way to run the /usr/bin/supervisord executable directly, which will start the supervisord process and use the default configuration file (usually /etc/supervisor/supervisord.conf) to manage the process. This approach is suitable for starting supervisord manually, and you can specify other options and configuration files as needed.
In actual development, we generally use systemd or service to manage services, so below we use systemctl to control supervisor,
To create a new Supervisor service file, use the following command:
sudo nano /etc/systemd/system/supervisor.service
Add the following content to the file:
[Unit] Description=Supervisor process control system Documentation=http://supervisord.org [Service] ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf ExecStop=/usr/bin/supervisorctl $OPTIONS shutdown ExecReload=/usr/bin/supervisorctl $OPTIONS reload KillMode=process Restart=on-failure RestartSec=50s [Install] WantedBy=multi-user.target
Save and close the file.
Start the Supervisor service:
Start the Supervisor service by running the following command:
sudo service supervisor start
If you want Supervisor to start automatically at system startup, you can run the following command:
sudo service supervisor enable
Now you have installed Supervisor and used service for startup management. You can manage more applications by modifying the Supervisor configuration file and start, stop, and restart them using the appropriate commands.