The responsibility of the kernel event daemon is to relay kernel events
to Finit. At shutdown and reboot it is too late for more events and the
daemon should just shut down with other services.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Fix copy-paste of error message from cond-w.c
A read-only root filesystem may have /var/lock, while we want to remove
it and add a symlink to ../run/lock. Ignore errors from this since we
cannot do anything about it. It is up to the user to fix their skeleton
or use an overlay.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Inspired by Alpine Linux, add /dev/mqueue if missing. We should check
the /proc/filesystems first, but this is quicker.
The sticky bit ensures only the owner of files in /dev/shm can delete or
rename files. This is also what Alpine Linux use.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
A service with notify:pid is 'ready' when the pidfile has been created,
the converse also holds true -- when a pidfile is removed the service is
no longer 'ready'.
The state transition for the service has probably already been done, in
svc_set_state(), clearing all <service/foo/*> conditions when the PID
was collected. The pidfile event may arrive later, so for completeness
we make sure the 'ready' condition is not recreated at least.
Problem introduced in 912a281 with the original supoport for service
readiness notification.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
There exist two possible basename functions, a xpg compliant one in libgen.h
and a GLIBC exclusive one declared in string.h, that was previously also declared by musl libc.
Both implementations are expecting different parameter types (`const char *` for GLIBC and `char *` for xpg)
With the removal of the basename function from string.h in musl libc, we could only rely on the xpg implementation.
Unfortunately, the xpg implementation of basename does modify the contents of whatever you put in it,
even though that there really is no need for it.
This is an issue in some cases, where we might want to get the basename of a read-only variable, e.g. a `const char *`,
as trying to modify something read-only is undefined behavior.
So in order to keep things consistent for us, we implement our own version of basename called `basenm`,
that does not modify the passed argument.
As of Finit v4.6 we no longer assert the PID condition for services
declaring themselves as notify != pid. We replace D with a forking
service to catch any future regressions in the pidfile plugin.
No need to check reload PID of D, it is enough to check PID of C.
Also, reduce the number of retries at startup. If we haven't gone
up within 10 sec with this tiny config something is really wrong.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Premise, a service declaring itself 'notify:none' should never assert a
pid condition. However, forking services still need to be supported and
the only way to do that is if they create a pid file. Hence, instead of
skipping pidfile_update_conds() completely we need to filter the type.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
2023-11-13T04:02:23 [WRN]: conf_change_act():failed registering /etc/finit.conf/ event mask 00000004: Not a directory
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This fixes an issue when finding a global environment variable with
spaces in the variable name:
set COLORTERM=yes
Literally, 'set COLORTERM' was the name of the variable.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This change expands the readiness notification system in Finit with the
native 'pid' style, which will remain the default readiness in Finit 4.x
For systems that want to transition to Finit 5.x early, a global option
to set 'readiness none' in /etc/finit.conf, has been added. This change
the service default notification mode to 'notify:none', which can also
be set by Finit 4.x ('readiness pid') for select services.
Fixes#386.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Joachim Wiberg