doc: update service modifiers with all new options

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit is contained in:
Joachim Wiberg committed 2025-07-10 13:29:38 +02:00
1 parent cd0ddd6bfc
commit ab82e6f696
2 files changed
+52 -28

No files matched your search

+47 -24
View File
@@ -1,23 +1,29 @@
If a service should not be automatically started, it can be configured Service Options
as manual with the optional `manual` argument. The service can then be ===============
started at any time by running `initctl start <service>`.
manual:yes The run/task/tty/service/sysv directives take modifiers, or options, to
control their behavior. This section lists them with their limitations.
All modifiers must be placed between the directive and its command.
The name of a service, shown by the `initctl` tool, defaults to the The name of a service, shown by the `initctl` tool, defaults to the
basename of the service executable. It can be changed with the basename of the service executable. It can be changed with the `name:`
optional `name` argument: option:
name:<service-name> name:<service-name>
If multiple instances of a service, with the same `name`, exist. Set For multiple instances of a service, with the same `name`, set the
the identifier `:ID` to prevent Finit from replacing previous instances: identifier `:ID` to prevent Finit from replacing previous instances:
service :eth1 ssdpd eth1 -- Windows discovery on eth1 service name:ssdp :eth1 ssdpd eth1 -- Windows discovery on eth1
service :eth2 ssdpd eth2 -- Windows discovery on eth2 service name:ssdp :eth2 ssdpd eth2 -- Windows discovery on eth2
If you have conflicting services and want to prevent them from starting, The [`initctl`](../initctl.md) tool will list these two services as:
use the `conflict:` argument:
- ssdp:eth1
- ssdp:eth2
Conflicting services that must be prevented from starting, use the
`conflict:` option:
service [S12345789] udevd -- Device event management daemon service [S12345789] udevd -- Device event management daemon
run [S] conflict:udevd mdev -s -- Populating device tree run [S] conflict:udevd mdev -s -- Populating device tree
@@ -28,8 +34,25 @@ Multiple conflicting services can be separated using `,`:
service :2 abc service :2 abc
service conflict:abc:1,abc:2 cde service conflict:abc:1,abc:2 cde
As mentioned previously, services are automatically restarted, this is If a service should not be automatically started, it can be configured
configurable with the following options: as manual with the optional `manual` argument. The service can then be
started at any time by running `initctl start <service>`.
manual:yes
Other run/task/service options are:
* `cgroups:...` -- see the [Cgroups](cgroups.md) section
* `env:[-]/path/to/env` -- see the [Service Environment](service-env.md) section
* `log:...` -- see [Redirecting Output](logging.md#redirecting-output)
* `nowarn` -- see [Conditional Loading](services.md#conditional-loading)
* `notify:...` -- see [Service Synchronization](service-sync.md)
* `if:...` -- see [Conditional Execution](services.md#conditional-execution)
* `type:forking` -- see description of the [service](services.md) directive
As mentioned previously, services are automatically started, restarted,
and stopped, depending on the configuration and conditions. Within the
confines of that the following options are available:
* `restart:NUM` -- number of times Finit tries to restart a crashing * `restart:NUM` -- number of times Finit tries to restart a crashing
service, default: 10, max: 255. When this limit is reached the service, default: 10, max: 255. When this limit is reached the
@@ -49,14 +72,14 @@ configurable with the following options:
has *crashed*, if this option is set the system is rebooted has *crashed*, if this option is set the system is rebooted
* `oncrash:script` -- similarly, but instead of rebooting, call the * `oncrash:script` -- similarly, but instead of rebooting, call the
`post:script` action with exit code `crashed`, see below `post:script` action with exit code `crashed`, see below
* `reload:script [args]` -- some services do not support `SIGHUP` but * `reload:'script [args]'` -- some services do not support `SIGHUP` but
may have other ways to update the configuration of a running daemon. may have other ways to update the configuration of a running daemon.
When `reload:script` is defined it is preferred over `SIGHUP`. Like When `reload:script` is defined it is preferred over `SIGHUP`. Like
systemd, Finit sets `$MAINPID` as a convenience to scripts, which in systemd, Finit sets `$MAINPID` as a convenience to scripts, which in
effect also allow `reload:'kill -HUP $MAINPID'` effect also allow `reload:'kill -HUP $MAINPID'`
* `stop:script [args]` -- some services may require alternate methods * `stop:'script [args]'` -- some services may require alternate methods
to be stopped. When `stop:script` is defined it is preferred over to be stopped. If a `stop:script` is defined it is preferred over
`SIGTERM` and `stop` for `service` and `sysv` stanzas, respectively. `SIGTERM` and `stop`, for `service` and `sysv`, respectively.
Similar to `reload:script`, Finit sets `$MAINPID` Similar to `reload:script`, Finit sets `$MAINPID`
> [!CAUTION] > [!CAUTION]
@@ -66,12 +89,12 @@ configurable with the following options:
When stopping a service (run/task/sysv/service), either manually or when When stopping a service (run/task/sysv/service), either manually or when
moving to another runlevel, Finit starts by sending `SIGTERM`, to allow moving to another runlevel, Finit starts by sending `SIGTERM`, to allow
the process to shut down gracefully. However, if the process has not the process to shut down gracefully (unless a `stop:'script'` is used).
been collected within 3 seconds, Finit will send `SIGKILL`. To stop the However, if the process has not been collected within 3 seconds, Finit
process using a different signal than `SIGTERM`, use `halt:SIGNAL`, will send `SIGKILL`. To stop the process using a different signal than
e.g., `halt:SIGPWR`. To change the delay between the stop signal and `SIGTERM`, use `halt:SIGNAL`, e.g., `halt:SIGPWR`. To change the delay
KILL, use the option `kill:<1-60>`, e.g., `kill:10` to wait 10 seconds between the stop signal and KILL, use the option `kill:<1-60>`, e.g.,
before sending `SIGKILL`. `kill:10` to wait 10 seconds before sending `SIGKILL`.
Services, including the `sysv` variant, support pre/post/ready and Services, including the `sysv` variant, support pre/post/ready and
cleanup scripts: cleanup scripts:
+5 -4
View File
@@ -10,7 +10,7 @@ they have to be manually restarted with `initctl restart NAME`. The
limits controlling this are configurable, see the options below. limits controlling this are configurable, see the options below.
> [!TIP] > [!TIP]
> To allow endless restarts, see below option `respawn` > To allow endless restarts, see the [`respawn` option](service-opts.md)
For daemons that support it, we recommend appending `--foreground`, For daemons that support it, we recommend appending `--foreground`,
`--no-background`, `-n`, `-F`, or similar command line argument to `--no-background`, `-n`, `-F`, or similar command line argument to
@@ -151,7 +151,7 @@ which also provides a service named `udevd`.
run nowarn if:udevd <pid/udevd> :1 udevadm settle -t 0 run nowarn if:udevd <pid/udevd> :1 udevadm settle -t 0
This line is only loaded if we know of a service named `udevd`. Again, This line is only loaded if we know of a service named `udevd`. Again,
we do not warn if `udevadm` is not found, Execution will also stop here we do not warn if `udevadm` is not found, execution will also stop here
until the PID condition is asserted, i.e., Finit detecting udevd has until the PID condition is asserted, i.e., Finit detecting udevd has
started. started.
@@ -165,9 +165,10 @@ can also be written as:
run nowarn if:!udevd [S] mdev -s -- Populating device tree run nowarn if:!udevd [S] mdev -s -- Populating device tree
The reason for using `confict` in this example is that a conflict can be The reason for using `conflict` in this example is that a conflict can be
resolved. Stanzas marked with `conflict:foo` are rechecked at runtime. resolved. Stanzas marked with `conflict:foo` are rechecked at runtime.
Conditional Execution Conditional Execution
--------------------- ---------------------
@@ -188,7 +189,7 @@ in true sequence. If loading the file `startup-config` fails confd sets
the condition `usr/fail-startup`, thus allowing the next run statement the condition `usr/fail-startup`, thus allowing the next run statement
to load `failure-config`. to load `failure-config`.
Notice critical the difference between `<pid/sysrepo>` condition and Notice the critical difference between the `<pid/sysrepo>` condition and
`if:<usr/fail-startup>`. The former is a condition for starting and the `if:<usr/fail-startup>`. The former is a condition for starting and the
latter is a condition to check if a run/task/service is qualified to latter is a condition to check if a run/task/service is qualified to
even be considered. even be considered.