supervise service
supervise switches to the directory named service and starts ./run. It restarts ./run if ./run exits. It pauses for a second before starting ./run, so that it does not loop too quickly if ./run exits immediately.
If the file service/down exists, supervise does not start ./run immediately. You can use svc to start ./run and to give other commands to supervise.
supervise maintains status information in a binary format inside the directory service/supervise, which must be writable to supervise. The status information can be read by svstat.
supervise may exit immediately after startup if it cannot find the files it needs in service or if another copy of supervise is already running in service. Once supervise is successfully running, it will not exit unless it is killed or specifically asked to exit. You can use svok to check whether supervise is successfully running. You can use svscan to reliably start a collection of supervise processes.
Starting in version 0.70: supervise pauses for a second after starting ./run.
#!/bin/sh
exec clockspeed
The exec here tells sh
to replace itself with clockspeed.
This lets you use svc to send signals directly to clockspeed.
Note that the service should not run in the background:
#!/bin/sh
# will be repeatedly restarted by supervise
exec clockspeed &
You can use fghack
to let supervise monitor (but not control) some programs
that put themselves into the background:
#!/bin/sh
exec fghack inetd
If you have root privileges, you can use setuidgid to run a service under another account:
#!/bin/sh
exec \
setuidgid qmaill \
multilog t ./main '-*' '+* status: *' =status
It is generally not a good idea to use shell pipelines:
#!/bin/sh
generate-crucial-data | save-crucial-data
If save-crucial-data fails to start up,
any data already written to the pipe by generate-crucial-data
will be discarded.
You can use svscan to reliably start a pipeline of supervise
processes, with
#!/bin/sh
exec generate-crucial-data
in ./run
and
#!/bin/sh
exec save-crucial-data
in ./log/run.
Sometimes data is piped to supervise to be processed by ./run. Beware that many programs will discard unprocessed input data when they receive a TERM signal. The multilog program is specially designed to process all data it has read before it exits.