Joachim Wiberg
b9ad9bcb21
The syntax overview no longer describes a line-based format, since that is not what the rest of the documentation shows. It now covers the grammar, the two naming conventions, the nine aliases, and the leading '-' on a path, and it says plainly that both formats are still read and told apart per file by content. Without that, a reader with an existing configuration is left wondering what happened to it. service-opts.md was a list of modifiers to place between a directive and its command, so it needed rewriting rather than translating: there are no positions left to describe. It is now grouped by what the settings do. conditions.md needed correcting. It presented '!' as a condition prefix alongside '~'. It is neither a condition nor a negation, it is a flag on the block that means one thing on a service and another on a run or task, so it is spelled reload-signal and required here, and the page maps the old form to both. Two things the pages claimed are not true. The kill delay range is 1-300, not 1-60, and stop and reload scripts are no longer run without a timeout. ChangeLog.md keeps its line-based examples. Those sit in historical release entries, and rewriting them in a syntax that did not exist at the time would misdate the format. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
2.4 KiB
Starting & Monitoring
Finit can start and monitor the following types of daemons:
- Forks to background, creates a PID file
- Runs in foreground and signals ready by:
- creating a PID file
- does not create a PID file -- Finit can create it for you (optional)
- other mechanism (systemd, s6)
Finit can not start and monitor a daemon that:
- Forks to background and does not create a PID file
| Forking | Creates PID File | Finit creates PID File | |
|---|---|---|---|
| ✔ | Yes | Yes | No |
| ✔ | No | Yes | No |
| ✔ | No | No | Yes, optionally |
| ✘ | Yes | No | No |
Note
PID files is one mechanism used to assert conditions to synchronize the start and stop of other, dependent, services. Other mechanisms are described in the Service Synchronization section.
Forks to bg w/ PID file
There are two variants. The former names the pidfile to watch, as for
sysv start/stop scripts, and the latter is inspired by systemd, with a
twist -- it lets Finit guess the pidfile based on the standard path and
the basename of the command.
service serv {
description = "Forking service, type 1"
pidfile = "/run/serv.pid"
command = "serv"
}
service serv {
description = "Forking service, type 2"
type = "forking"
command = "serv"
}
In this example the resulting files to watch for are /run/serv.pid and
/var/run/serv.pid, respectively. On most modern Linux systems this is
the same directory (/var/run is a symlink to ../run).
Runs in fg w/ PID file
service serv {
description = "Foreground service w/ PID file"
command = "serv -n -p"
}
Runs in fg w/o PID file
Same as previous, but we tell Finit to create the PID file, because we need it to synchronize start/stop of a dependent service.
service serv {
description = "Foreground service w/o PID file"
pidfile = "/run/serv.pid"
pidfile-create = true
command = "serv -n"
}
Runs in fg w/ custom PID file
service serv {
description = "Foreground service w/ custom PID file"
pidfile = "/run/servy.pid"
command = "serv -n -p -P /run/servy.pid"
}