After reports from the field, see issue #397, of lockups at reboot,
we've decided to drop this code from PID 1. It was added before the 4.x
series, when the current progress output was introduced. For the older
style progress it served a purpose since the placement of [OK]/[FAIL]
was on the right hand side.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When the system shuts down, or user changes runlevels, we don't have to
call cond_clear_update(), because this can lead to nested service_stop()
calls, which in turn lead to out of sync progress updates:
[ .. ] Stopping Foo
[ OK ] Stopping Bar
[ OK ]
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The /etc/issue file on Alpine Linux says "Kernel \r on an \m (\l)", so
\r needs to return the uts release rather than os-release VERSION.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
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>
Joachim Wiberg