New Feature: `disable`/`enable`
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.
Posted by jvanasco on Mar 13, 2015, 3:31 PM
Tags
Related issues
- 2026 - Microsoft Office 365
- [Ubuntu] `ubuntu-latest` label will use Ubuntu 26.04 in November 2026
- Gamut mapping
- [Codex Desktop] Editing and resending a queued message triggers "App-server queued follow-up no longer exists"
- [Windows] ChatGPT 26.820.60940 fails with "invalid transport in mcp_servers.codex_app"; Beta 26.727.40816 works
- [BUG]: infinite loading of videos
Raise real-world problems, find people facing the same issue, and discuss solutions.7,500 issues0 comments
github (SaaS)
2026 - Microsoft Office 365
[Ubuntu] `ubuntu-latest` label will use Ubuntu 26.04 in November 2026
Gamut mapping
[Codex Desktop] Editing and resending a queued message triggers "App-server queued follow-up no longer exists"
[Windows] ChatGPT 26.820.60940 fails with "invalid transport in mcp_servers.codex_app"; Beta 26.727.40816 works
[BUG]: infinite loading of videos
Restore GPT-5.6 Sol’s 372k Codex context window, or provide an opt-in setting
Codex Desktop for macOS repeatedly triggers `syspolicyd` / `trustd` CPU and memory runaway
New Feature: `disable`/`enable`
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.
Comments (0)
No comments yet. Start the discussion.