New Feature: `disable`/`enable`

[jvanasco]

I'd like to suggest a new feature: disable/enable a program.

• disable stops the process (if running). sets a disabled flag on the disk. "disabled" processes will not be considered for "all" commands or on restart.
• enable unsets the disabled flag on the disk.

Rationale:

I often have to "disable" a process during maintenance, for fear that the system could restart and supervisord would restart the process. In order to do this, I have to essentially unregister the service by editing the supervisord config files. Even if using symlinks in a directory, this is awkward and tedious -- and I lose the program's status from within supervisor. Trying to find out if something is "disabled" is a chore, because I have to match a list of available configurations with active ones.

I think a better solution would be to simply mark the status as "disabled" and persist that to disk. The program would still be registered to supervisord and ready to enable at any time. The supervisorctl app and status command would clearly report that the configuration is "disabled".

I looked through the source and this seems relatively easy to do -- except for persisting the data to disk. I can't figure out a good place to store this.

If the maintainers think this is an acceptable idea and can suggest a place/mechanism for storing data, I think I can fork and PR.

[sudarkoff]

Yes, please!!!

[msabramo]

👍

[vincent-io]

👍

[muffl0n]

👍

[jvanasco]

When I first posted this, I was told by one of the package maintainers (in a private email, or comment since deleted?):

This will be pretty difficult to implement and will be confused with the existing machinery (add and remove commands). I would rather see this done in a plugin.

With my knowledge of Supervisor, I thought I could patch this into the core distro – but I have no idea how to do this as a plugin. I tried, and it didn't seem doable with the available hooks.

[muffl0n]

I know the possibility to disable services from Solaris' SMF. It feels pretty wird that supervisor does not have something similar.
Removing to disable a service feels like removing a symlink to the good old init.d-files.

[jvanasco]

The crusty workaround I've been using is managing servers with two directories:

• services-all
• services-enabled

The actual config files are in services-all, they are symlinked into services-enabled which is what supervisord reads. This is the same approach to how some os distros package apache and nginx.

The shortcoming is that you have to disable the process in supervisor AND on the disk; then enable the process in both places as well -- otherwise the service will start up on a reboot. It's really confusing, but it works.

[vincent-io]

@jvanasco not a direct fix, but you should give Ansible a try. Works very well once you invest a little bit of time to write proper playbooks.

[palmkevin]

+1

[suizman]

+200

[buzzijavier]

Anything new on this front?

[nguyenkims]

+1 as well!

[varunpalekar]

This can be easily implemented with the help of symlinks, in the same way http servers are doing like apache and nginx.

Please just create such folder structure to support the feature.
Please see for more details about site-available and site-enable https://help.ubuntu.com/lts/serverguide/httpd.html

[jvanasco]

@varunpalekar no, this can't be easily implemented with symlinks like apache/nginx (which I also covered above as a bad interim solution, and many people already do)

Apache and Nginx are entirely controlled by the presence of files in the include directories. If a file is in "/sites-enabled", then it is enabled on application setup. There is no in-process system to change that -- in order to start/stop a configured host, one would edit or symlink a file and then restart the service.

Supervisorctl is a process supervisor. Placing a configuration file in "/sites-enabled" or "/sites-available" makes the service available for Supervisor -- but Supervisor also has in-process controls that handle that service being started or stopped... and a configuration may or may not "autostart" a service. Supervisor itself wouldn't be able to use symlinks, because the process configurations could be inline within a single file -- meaning a feature like that would not work on many configurations in-the-wild.

Supervisorctl simply needs to persist into a small datafile (pickle, json, whatever) the name of "stopped" items, so they are not auto-started if the system reboots.

I think the best place to do this might be in a secondary config file called supervisor.status or similar, which would be created/read from the same directory as the active configuration file.