[Supervisor-users] Persisting a "stop" across reboots ?

Discussion:

Jonathan Vanasco

11 years ago

This might be a bit of an edge case, not sure. I'm wondering how others handle this.

We shut down one of the processes run by supervisord during an extended deployment ( i.e. `supervisorctl stop process`)

Part of the maintenance window included updating some packages on the server and provisioning some new resources for the VPS. a reboot got triggered.

on reboot, supervisod started up and then did what we'd normally want it to -- start all the processes. except we didn't want this process started -- as it had been purposefully shut off before the reboot.

Does anyone have tips/tricks for persisting an "off" across reboots?

Marcos Cano

11 years ago

Permalink

This might sound "stupid". but I use the include files in the
supervisord.conf and make supervisor to lookup for *.ini file, so if I want
a process to be "ignored" by supervisor I rename the file to file.ino

That's the only way I've come up to handle a manual add to a process I'm
"debugging "

...

Jonathan Vanasco

11 years ago

Permalink

THANKS!!!

I totally forgot that programs can be listed in separate files.

i migrated to that model in a few minutes

in nginx, we do something similar:

/sites-available
all config files

/sites-enabled
symlinks to config files that are active ( in the form of `ln -s ../sites-available/NAME .`

so i set supervisord up with the same system.

everything is managed in a source repo, so the solution was:

1. split files out in source repo.
/config/environments/production/supervisor/supervisord.config
/config/environments/production/supervisor/supervisord-sites-available

2. update the deployment tool (which is Fabric) to mount the 'available' directory onto /etc, create an enabled directory, and build out symliks

it's working super smoothly now.

i'll probably update the fabric tool to be a single interface to both issuing a `supervisorctl` command and updating a symlink for persistance.

but we're also able to cheat a bit in nginx too -- there's an old (common?) trick to use the existence of a file as a control semaphore. if the file exists ( /path/to/maintenance.on ), everything gets redirected to a maintenance page. if the file doesn't exist, things serve as normal. its useful for situations where you can't (or don't want to) reload the daemon.

Marcos Cano

11 years ago

Permalink

...