We use strtok() quite extensively in .conf parser. Parsing of a service
line is split in two, with the command arguments being parsed very late.
Adding a new sub-option parser, based on strtok(), risk losing command
arguments. Thus, change to use strtok_r() so that we always know where
the arg parser is.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
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>
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>
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>
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>
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 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>
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>
The whole point of pre: scripts is that they run just before the actual
run/task/service process, hence they need to be locked behind the same
conditions as the process. Otherwise pre: scripts would be nothing more
than plain tasks.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Prior to this change only service stanzas respected the manual:yes
option, now it (should) work on any svc_t type. Not tested on ttys.
The initctl tool has been given an extra manual=yes output for these
types of run/task/service entries, shown only when the manual option
is set.
Example:
root@anarchy:~# initctl status foo.sh
Status : stopped (code=exited, status=0/SUCCESS, manual=yes)
Identity : foo.sh ~~~~~~~~~~~~
Description : Hej foo
Origin : /etc/finit.d/enabled/foo.conf
Environment :
Condition(s):
Command : /root/foo.sh
PID file : none
PID : 0
User : root
Group : root
Uptime : N/A
Starts : 1
Restarts : 0 (0/10)
Runlevels : [--2345----]
Notice also the new `Starts : 1` which is a counter for the number of
starts in the current runlevel. On runlevel change it is reset to 0.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When adding a new service option recently, I copy-pasted and forgot to
update the length argument to strncasecmp(), so it was time to fix that
once and for all.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change allows endless restarts, similar to `respawn` but honors
`restart_sec`. There is no upper limit on the number of times Finit
tries to restart a crashing service. Same as `restart:-1`
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Move the stop+start from initctl to the state machine by allowing
stopped tasks to restart once it has been collected. This should
prevent finit from blocking, allowing it to handle other requests
while waiting for the service's PID to be collected.
Effectively, this will allow a service to call initctl to restart
itself, as reported in issue #280.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Drop basename() of svc->cmd from remaining code
- Replace uses of svc->cmd with svc_ident(svc)
- Use svc_ident() as default log tag
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Init script return pretty quickly after launch, so we cannot use that to
detect if they, or the daemon they launched, have crashed. So we start
the service_retry() with a 2 sec delay, which should be ample time to
allow the pidfile plugin to detect a forking service's new PID.
In release-cycle regression, no public issue needed.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
In some conditions, typically when the same command is used for multiple
services, e.g. the modules-load plugin, the svc_find() function returned
an existing "similar" entry instead of NULL, causing loss of config.
When creating, and searching for, a run/task/service we must follow the
new name:id paradigm to the letter. Always create based on name:id and
always search for matching name:id. The name may be derived from the
command, but they cannot be used interchangably.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change makes it possible to see the new service's resulting name
and id before we create it with svc_new(). We extend the debug output
slightly to see what's going on and why we sometimes lose modules from
the modules-load plugin ...
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
For many usecases, e.g. the modules-load plugin, the same command can be
used to create multple run/task/services makeing it real difficult to
debug such systems when Finit does not show the correct task name. It
also hides nasty bugs, as will be shown in a later commit.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Drop the config.h include from helpers.h after a report from a colleague
trying to build an external plugin from the latest GIT sources.
Instead, make sure config.h is included, and properly commented, in all
.c files that have configure #ifdefs and other deps. Also, move more
ot the includes from helpers.h to their respective .c file instead to
reduce the amount of headers an external plugin pulls in.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change basically add this for pre/post scripts:
sh -ac '. /path/to/env; exec ./pre-post.sh'
Meaning the env file can be a simple foo=bar file, which Finit reads and
call setenv() on all variables, and the user do not need to call export
on all variables -- additionally, any functions defined in an env file
can be used by the pre-post scripts, but are ignored by Finit. I.e.,
the service only gets the variables set, no functions.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Since a forking service, e.g. a sysv init script, will exit very early
we cannot log the same as for regular services "Starting foo[123]", so
instead we log "Started bar[321]" when we get the pidfile update and
the same when stopping a forking service, log "Stopped bar[321]" when
we collect the PID.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change adds the following service conditions, which can be used to
synchronize other stanzas:
- service/foo/running
- service/foo/halted
- service/foo/missing
- service/foo/crashed
- service/foo/stopped
- service/foo/busy
- service/foo/restart
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This reverts commit c63279630b which
clearly was not needed to fix the problem. After this revert the
test(s) still pass, but now we can also start bridge-stp, e.g.
bridge-stp br0 start
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
A forking service, e.g. a SysV init script, that returns is no longer
running, even though the monitored service may still be starting. We
must mark the svc->pid as terminated until we know more -- otherwise
we may stall on a shutdown at that exact point.
Also, when shutting down, and stopping all services, ensure we do not
start the carousel for non-existing PIDs. This might also cause our
stalling at shutdown.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Add `type:forking` service option to trigger guessing pidfile to
watch for, instead of `pid:!foo` option, which is not intuitive.
This option may likely also survive into the new file format :)
- Update docs and add examples
- Update start-stop-serv.sh test case with this new variant
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Before this fix, a service declared with respawn could not be changed at
runtime to remove the respawn flag.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Joachim Wiberg