[Feature] Keep process state when restarting Supervisord or rebooting machine

[tomekit]

Problem

As far I am concerned there is no way to tell Supervisord that process state should not be changed when restarting Supervisord
or rebooting the machine that Supervisord runs on
or running supervisorctl update to update config of some of the newly added/removed/updated processes.

How autostart CAN'T solve it

There is an autostart option, quoting: If true, this program will start automatically when supervisord is started.

If true process will always be started, even though it wasn't running (e.g. it was explicitly stopped) prior to supervisord or machine restart or supervisord update. It will be started when you do the supervisorctl update, even if it's not running currently.
If false process won't be started, even though it was running prior to supervisord or machine restart or supervisord update. It will be stopped when you do the supervisorctl update, even if it's currently running (is that expected?).

My use case

I've some of the processes which are disabled most of the time, but from time to time I need to run them manually. Now, I wouldn't like this process to be automatically started without my knowledge (when machine reboots for instance), on the other hand if machine reboots (e.g. electricity issues) I would like my process to be started to carry on his work.

The other use case is quite vice versa. I've one process, 10 instances (numprocs) that run most of the time. From time to time I need to limit the number of instances from 10 to e.g. 5 and keep it running like this for few hours, until I might increase back to 10 or just 8. This happens e.g. when 10 instances are too much if there is excessive load on the system and I need to limit the amount of workers.

Do you also miss such a option or is it just my use case? Do you think that documentation is not telling all the truth? Restarting supervisord is not the only state when process state gets modified by autostart

[mnaberez]

This sounds very similar to #591, which is another request where the discussion thread also suggests some notion of persisting process state outside of the configuration file. Let's use #591 as the place for the discussion.