mirror of
https://github.com/troglobit/finit.git
synced 2026-10-17 10:49:34 +00:00
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>
101 lines
3.8 KiB
Markdown
101 lines
3.8 KiB
Markdown
SysV Init Compatibility
|
|
=======================
|
|
|
|
It is not possible to run unmodified SysV init systems with Finit. This
|
|
was never the intention and is not the strength of Finit. However, it
|
|
comes with a few SysV Init compatibility features to ease the transition
|
|
from a serialized boot process.
|
|
|
|
SysV Init Scripts
|
|
-----------------
|
|
|
|
**Syntax:** `sysv [LVLS] <COND> /path/to/init-script -- Optional description`
|
|
|
|
> `<COND>` is described in the [Services](services.md) section.
|
|
|
|
Similar to `task` is the `sysv` stanza, which can be used to call SysV
|
|
style scripts. The primary intention for this command is to be able to
|
|
reuse much of existing setup and init scripts in Linux distributions.
|
|
|
|
When entering an allowed runlevel, Finit calls `init-script start`, when
|
|
entering a disallowed runlevel, Finit calls `init-script stop`, and if
|
|
the Finit .conf, where `sysv` stanza is declared, is modified, Finit
|
|
calls `init-script restart` on `initctl reload`. Similar to how
|
|
`service` stanzas work.
|
|
|
|
Forking services started with `sysv` scripts can be monitored by Finit
|
|
by declaring the PID file to look for: `pidfile = "/path/to/file.pid"`.
|
|
Finit does not create that file, it watches it for the resulting
|
|
forked-off PID, which is the default; `pidfile-create = true` is what
|
|
asks Finit to write it instead. This
|
|
syntax also works for forking daemons that do not have a command line
|
|
option to run it in the foreground, more on this below in `service`.
|
|
|
|
> [!TIP]
|
|
> See also [SysV Init Compatibility](#sysv-init-compatibility).
|
|
|
|
`runparts DIRECTORY`
|
|
--------------------
|
|
|
|
For a directory with traditional start/stop scripts that should run, in
|
|
order, at bootstrap, Finit provides the `runparts` directive. It runs
|
|
in runlevel S, at the very end of it (before calling `/etc/rc.local`)
|
|
making it perfect for most scenarios.
|
|
|
|
For syntax details, see the [Run-parts Scripts](runparts.md) section.
|
|
Here is an example take from a Debian installation:
|
|
|
|
runparts /etc/rc2.d
|
|
|
|
Files in these directories are usually named `SNNfoo` and `KNNfoo`,
|
|
which Finit knows about and automatically appends the correct argument:
|
|
|
|
/bin/sh -c /etc/rc2.d/S01openbsd-inetd start
|
|
|
|
or
|
|
|
|
/bin/sh -c /etc/rc0.d/K01openbsd-inetd stop
|
|
|
|
Files that do not match this pattern are started similarly but without
|
|
the extra command line argument.
|
|
|
|
Start/Stop Scripts
|
|
------------------
|
|
|
|
For syntax details, see [SysV Init Scripts](#sysv-init-scripts), above.
|
|
Here follows an example taken from a Debian installation:
|
|
|
|
sysv inetd {
|
|
description = "OpenBSD inet daemon"
|
|
runlevel = "2345"
|
|
conditions = { "pid/syslogd" }
|
|
command = "/etc/init.d/openbsd-inetd"
|
|
}
|
|
|
|
The init script header could be parsed to extract `Default-Start:` and
|
|
other parameters for the `sysv` command to Finit. There is currently no
|
|
way to detail a generic syslogd dependency in Finit, so `Should-Start:`
|
|
in the header must be mapped to the condition system in Finit using an
|
|
absolute reference, here we depend on the sysklogd project's syslogd.
|
|
|
|
`/etc/rc.local`
|
|
---------------
|
|
|
|
One often requested feature, early on, was a way to run a site specific
|
|
script to set up, e.g., static routes or firewall rules. A user can add
|
|
a `task` or `run` command in the Finit configuration for this, but for
|
|
compatibility reasons the more widely know `/etc/rc.local` is used if
|
|
it exists, and is executable. It is called very late in the boot process
|
|
when the system has left runlevel S, stopped all old and started all new
|
|
services in the target runlevel (default 2).
|
|
|
|
> In Finit releases before v4.5 this script blocked Finit execution and
|
|
> made it as good as impossible to call `initctl` during that time.
|
|
|
|
`init q`
|
|
--------
|
|
|
|
When `/sbin/finit` is installed as `/sbin/init`, it is possible to use
|
|
`init q` to reload the configuration. This is the same as calling
|
|
`initctl reload`.
|