When a service starts up the pidfile.so plugin automatically detects any
new pidfiles that show up in the system. If it finds a matching service
which does not have a custom configured pidfile, it auto-assigns the
detected pidfile to the service.
However, when the user later calls `initctl reload` to update the
running configuration set, Finit service_register() mistakenly will
set the service to forking since it now suddenly has a pidfile ...
The new style way of configuring a forking service is to set the
type:forking
option. The old compat way was to set `pid:!/path/to/pidfile`, so
in service_register() we must be very careful not to interpret the
registered pidfile as confiugred by the user -- i.e., check the pid
option.
Bug #313
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When a service crashes Finit launches a restart timer that periodically
will try restart the service. If a user calls `initctl stop foo` finit
must cancel this timer callback, otherwise we may end up with a weird
state where Finit thinkgs the service is running, but pid: 0, i.e., not
started.
Note: this fix has been expanded upon from the proof of concept
submitted by Jack Newman.
Bug #313
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change adds support for a new command line option finit.config=PATH
which can be used to tell Finit to start with /etc/factory.conf instead
of /etc/finit.conf.
For the complete experience a new top-level configuration file directive
`rcsd PATH` has aslo been added. It in turn can be used by factory.conf
as follows to override /etc/finit.d:
rcsd /etc/factory.d
Manually verified in myLinux
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Since the s6 readiness notification mechanism closes the notification
socket to Finit (as per s6 spec.) the 'ready' condition should then
always be asserted, even across system reconfiguration events.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change adds support for JSON output to `initctl status` using a
`-j` or `--json` command line option.
Example:
root@anarchy:~# initctl status -j mdevd
{
"identity": "mdevd",
"description": "MDEVD Extended Hotplug Daemon",
"status": "crashed",
"exit": { "code": 100 },
"origin": "built-in",
"command": "/bin/mdevd -C -O 4",
"restarts": 10,
"pidfile": "/run/mdevd.pid",
"pid": 0,
"user": "root",
"group": "root",
"uptime": 0,
"runlevels": [ "S", 1, 2, 3, 4, 5, 7, 8, 9 ]
}
The excellent tool `jq` can be used to extract certain parts of the
output for further scripting. E.g. `initctl status -j foo | jq .exit`
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This was added for the benefit of `initctl status foo`, but we have
other users of these functions that don't expect a leading slash.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The condition subsystem starts very late, this should not affect running
callbacks in plugins. In d810ac0 an extra return statement was included
in a new if() statement block that run plugins hooks. This caused a
massive regression in how Finit starts up and runs.
- drop return; statement that causes regression
- move #ifdefs to surround if() statement
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change adds support for running hook scripts at two new hook points
during the shutdown process:
- HOOK_SVC_DN: after all services and non-reserved processes have been
killed (and collected)
- HOOK_SYS_DN: after all file systems have been unmounted, *just prior*
to Finit calling reboot() to shut down or reboot the system
See doc/plugins.md for details and an example.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Leave the system as it was when we found it. Also, we'll build things
on top of cond_is_available() to handle pre bootstrap and pre shutdown
tasks.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Always use the configured restart delay for crashing services. If no
delay is configured, we default to an initial 2000 msec for forking
daemons and start-stop scripts, and 1 msec for non-forking daemons.
We must track the increasing delay in the svc_t because processes can
fail quickly in differing ways. E.g, the test daemon 'serv' behaves
extra evil by crashing right after having created its pidile (i.e.,
when it's signaled to Finit it is 'ready' and all is dandy ...). If
we don't track the delay per svc_t we would restart 'serv' after only
1 msec every (other) time.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When there is no log daemon, and we are running in a container, or we
cannot log to the kernel ring buffer, then we log to stderr. This patch
improves the log output by prefixing each message with a timestamp.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch adds the oncrash:script option to call the post:script
action, if defined, for a crashing service. The EXIT_CODE variable
sent to the script is set to `crashed`.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
By definition, the readiness notification is reserved for daemons. May
possibly be extended also to sysv services later. If you arrive hare
with that request, please file an issue with the project.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Follow-up to abcb3ce, calling the service ready:script when readiness
has been signaled to or detected by Finit.
Issue #300
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Always better to have at least one sulogin available, if the system
provided sulogin isn't available we fall back to the built-in one.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch adds service readiness notification to support daemons
employing systemd and s6 notification. Complementing the native
Finit readiness support using PID files that exist already.
The two have slightly different ways of implementing readiness:
- https://www.freedesktop.org/software/systemd/man/sd_notify.html
- https://skarnet.org/software/s6/notifywhenup.html
Finit now provides both a NOTIFY_SOCKET environemnt variable, for
systemd, and a way to start s6 daemons with a descriptor argument.
For details on the syntax, see the `service` documentation.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This delays the start of the .conf monitor and service initialization
slightly to allow the event loop to run earlier to process any events
from the initial setup.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch renames the internal states for run/task/services to avoid
any confusion with the introduction of 'ready:scripts'.
* WAITING -> PAUSED
* READY -> WAITING
A service condition that used, e.g., <service/foo/ready> should now
instead use <service/foo/waiting>.
Note: A new condition with the old name <service/foo/ready> will be
introduced shortly to signify service "readiness", a concept
used in other PID 1, like systemd and s6.
For details, see issue #299.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
In Finit a daemon can signal its readiness by creating/touching its PID
file. An ancient UNIX concept -- a daemon creates its PID file when it
has set up signal handlers and is ready to receive IPC (signals), right
before entering its while(1) loop.
Finit took the concept a bit further, adding readiness signalling also
to daemon's by touching their PID file after having processed a SIGHUP.
For both these conditions Finit now supports a ready:script, called when
readiness is detected. In later commits support for s6 and systemd
style readiness notification will be added that will hook the mechanism
implemented in this commit as well.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This support API is for running things like pre:script, post:script and
the upcoming ready:script for services. A ready:script will be called
when a service notifies Finit of its readyness.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Service/task/run are today identified by name:id this means the path to
a command is not necessarily the basis for the identity. Hence, an
svc_t can now be updated with new the correct path to a command.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
As a real life example, this can be useful for a mfgtest mode for the
device, wherein the bootloader can be set to finit.cond=test_mode or
finit.cond=user_mode and then specific services can start up in test
mode which wouldn't normally start.
Or even custom firmware update mode such as finit.cond=fw_update_mode
which performs some specific firmware update steps and doesn't launch
normal processes.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This is a follow-up to #274, in which Andy pointed out that ending up in
state 'stopped' was a bit confusing for manual:yes run/tasks.
With the following change we let all run/tasks end in state 'done', yet
still allow manual:yes ones to transition to 'ready' when the user calls
`initctl start foo`.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Joachim Wiberg