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]

:+1:

[vincent-io]

:+1:

[muffl0n]

:+1:

[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.

[varunpalekar]

@jvanasco I just suggest a simple tweak through which you can gain what you need.

You can achieve your goal by just following point:

1. Create a single program in a single file, this is how you should structure your configuration file.
2. For enable and disable service create a script for that.

3. For enable service script,

   ln -s /etc/supervisor/conf-available.d/program1.conf /etc/supervisor/conf.d/program1.conf
   supervisorctl update 

4. For disable service script.

   rm /etc/supervisor/conf.d/program1.conf
   supervisorctl update

You can also make above script parameterized and move to any PATH folder so that you can access from anywhere

Above process is just a tweak, it will help in your scenario. If you want it in supervisor itself PR requests are welcome.

[jvanasco]

@varunpalekar Please read the entire thread, as everything you say has been addressed.

1. I offered to write a PR for this. A package maintainer rejected the proposal for a PR, saying that it should be done as a plugin -- so a PR request is officially "unwelcome" for this feature. I can only implement this within the core distribution, not as a plugin. Hopefully a package maintainer will change their mind as this ticket grows.
2. Do you have experience with Supervisor? You are describing command-line ways for a linux administrator to get around a deficiency in needed features by altering server configurations -- you are not addressing how to persist a "down" status across restarts. Any suggestion that is "configuration" based is not a solution and these "workarounds" have already been brought up and dismissed as not applicable. supervisorctl is a daemon that listens for commands to stop/start services, so commands issued within that control process need to be persisted. There is no guarantee the entity acting as a "client" who starts/stops the service managed by Supervisor is a "system user" -- much less one who is privileged to edit the configuration files. Disabling as you suggest would remove the task from the list of manageable processes.

[mamluka]

+1

[tomekit]

+1 I've created the: https://github.com/Supervisor/supervisor/issues/877 as I it's a crucial feature for my use case. It's been closed, as we have #591, but in principal the idea is quite the same.

[tomekit]

@varunpalekar I think your approach renders supervisorctl stop and supervisorctl start command useless. Any time you use stop or start it will make your config being not in sync with the current process state. Yes we could only use the symlinks as you've suggested, but going even deeper why to use supervisord in first place, maybe we can "hack" around just upstart and systemd with some bash tooling around.

[jvanasco]

The lack of this feature has brought me to look for a new process manager.

This has happened twice in the past week:

• a managed service runs into issues, supervisorctl stop process
• while working on fixing the managed service, the system has a reboot
• the broken service starts up, because supervisorctl doesn't give a fuck about the fact that I explicitly turned the service off

Now either I've:

• re-corrupted a dataset that I was halfway through fixing
• somehow consumed a message queue that was not supposed to be consumed

The amount of extra coding and administration needed to support this lack of a basic feature is substantial. We're migrating off.

[Alexander3]

:+1:

[christophrumpel]

🙏🏻

[stevecassidy2b]

+1

[ivanleoncz]

@varunpalekar , seems a good workaround for now. But I believe that a "disable" and "enable" options, are still the best, since that it is something that is well-know for managing services, since SysV script managers like "chkconfig" and "update-rc.d". I understand that the purpose of Supervisor is a little bit different (better than SysV concept), but in fact, it gets easier to manage Supervisor services. Everyone gave a thumbs up here for this improvement. I feel in a kind of duty to also give my here :).

+1

Thanks for all the keep Supervisor. You rock :)!

[giladbeeri]

+1

[tdamsma]

Another +1 from me. Any progress on this matter?

[aicos]

+1

Quite bizarre supervisor doesn't have this feature.

[jachim]

+1

[Pezhvak]

+1 i really need such a feature

[ChenJhua]

+1

[dales]

+1

[HOSTED-POWER]

+1

[mx2s]

+1

[bangpradyumna]

+1 Really needed this today. Sadly there is no such feature

[Vvaltz]

+1

[marcbln]

+1

[thiras]

+1

[dlangille]

I was just reading the docs, looking for this feature.

Default: enable=true

adding enable=false means the program is not started.

[kennell]

@dlangille Not sure where you read that, but i can't see any mention of that behaviour in the docs.

Also: +1

[dlangille]

@dlangille Not sure where you read that, but i can't see any mention of that behaviour in the docs.

I don't know. I don't recall posting this, but I do recall reading this issue. I should have posted a link.

Closest I could find now was autostart.

[Shreduardo]

+1

[RiverC]

The simplest solution is actually to stop the supervisord service. Consider this bad? Supervisor should implement a disable/enable per-process option. As a workaround it obviously doesn't respect any processes you might want to keep running, but it involves zero hacks and tends to meet my 'maintenance mode' needs and is very clean. Your mileage may vary.

[xepozz]

+1

[praditha-hidayat]

I need this feature as well.

As a workaround, I'm doing like this: Rename the .conf file to be something like .conf.disable and then update it. For example:

root@123:/etc/supervisor/conf.d# mv supervisor-program-1.conf supervisor-program-1.conf.disable
root@123:/etc/supervisor/conf.d# supervisorctl update all

supervisor-program-1: stopped
supervisor-program-1: removed process group

[aommm]

Would also like this. Thanks for the mentioned workaround @praditha-hidayat!

[e-gor]

+1

[caio-vinicius]

+1

[zerthimon]

Wow, such basic and essential functionality is still not implemented. Unbelievable.

[julien6387]

This function is available in the version 0.13 of the Supvisors plugin: XML-RPC enable XML-RPC disable

supervisorctl disable <program_name> supervisorctl enable <program_name>

When disabled, all the processes linked to the program are stopped. When enabled, the processes are started depending on their autorestart configuration. The persistence is made through a simple JSON file that can be set in the plugin options (refer to the disabilities_file option in the section rpcinterface:supvisors

Trying to start a disabled process will raise a RPCError with a DISABLED code (Supervisor Faults is patched on-the-fly when Supvisors is starting).

The current disabled status is made available through the web UI (state in grey) or using: XML-RPC get_local_process_info

supervisorctl local_status <a process_name linked to program>

[dlangille]

Wow, such basic and essential functionality is still not implemented. Unbelievable.

This function is available in the version 0.13 of the Supvisors plugin:

Well, what you got to say now?