I'll have to ask Jacques what this was for, because it doesn't seem to
be needed to run and monitor the test. Also, it lingers at shutdown,
causing some unintended side effects in Finit.
Commenting out for now, as a reminder to myself.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When a SysV init script starts a daemon, Finit knows nothing of the PID
it should monitor. The PID is written, by start-stop-daemon or the
daemon itself, to the PID file. Finit monitors for new PID files and
can match the PID in such files with an svc_t.
For the regular use-case, we prefer first looking up the matching svc_t
based on the PID -- assuming we start and monitor the service. As a
fallback we resort to mathching the svc_t's declared PID file with the
new file we just discovered.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
We want to find the PID of the daemon the init script starts, so we need
a way to declare this to Finit.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
SysV init scripts should not go to "done" state but "halted" so we can
do: `initctl stop foo; initctl start foo`, like we do for our regular
monitored services.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Install start-stop-daemon in test root. Add S01-service.sh, which uses
start-stop-daemon to start service.sh. Modify service.sh to respect
signals, and not exit immediately when sleep exits due to SIGTERM.
Remove PID file in signal callback and make sure to exit OK
The test itself is basically a copy of the start-stop-service.sh test.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The slay script checks for common errors and gives some logs and status
of Finit when something goes wrong. Helps detect issue #226 when the
start-kill-service.sh test runs at 100000 laps.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When running in a container we still want to use any syslog daemon
available for our logging needs. However, the time between the first
logit() in Finit and any such daemon having started can be long. In a
normal (non-containerized) setup we log to the kernel ring buffer, but
that's not available in a container scenario. At least not for
unprivileged containers. So we need to detect all these cases and be
prepared to fall back to log to the console, either using these LOG_CONS
flag to openlog(), or by simply calling vfprintf() to stderr.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This trick can also be used by others who want to run Finit in an
unshare. Set the container environment variable to 'unshare',
like lxc and docker do for their products.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Turns out the kill(2) syscall returns ENOENT, not ESRCH, in our test
suite. Don't know why, the man page never mentions ENOENT, only the
ESRCH code. Let's check for both, either way ithe PID is not there.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
A service may have unexpectedly died, and we never got the signal, so
when stopping services we must set the new state after we've tried to
stop the service. Otherwise the svc_set_state() function starts a
background timer for the SIGKILL job, which may block a reboot.
The kill() syscall tells us if the service was there or not, if not we
must clean up and go to HALTED state.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
At startup (and reconf) of systems with lots of services there is a risk
of losing inotify events, e.g., PID file creation/delete events. This
patch increase the receive buffer (doubles it).
On Linux the getsockopt() for SO_RCVBUF returns double the set size, due
to housekeeping in the kernel. So we don't have to do any adjustments
when setting it.
Issue #226
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
In some (error) cases the PID known to Finit may no longer exist, or may
not have been added to a cgroup (yet). Handle this case by skipping the
output of cgroup info in such conditions.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
On, e.g., a container based system logs may not be available so check
also that the messages fallback exists instead of causing confusing
error in the status output for the service.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
To silence warnings at startup/shutdown, check for existance of swapon
and swapoff before calling them.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When a run task is started with svc->started = 1, it should be
considered started successfully or failed on the other hand.
Signed-off-by: Sergio Morlans <sergio.morlans@atlascopco.com>
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
This patch adds support for optional logging of output from all run()
commands. For run_interactive() we've opted to log instead of just
redirect, meaning output on error is till on console but also in log.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
We've been discussing, over the years, that we'd like to have an easier
way to debug bringup with Finit. Network bringup is one such case where
it's hard to debug if/what you've misspelled in /etc/network/interfaces
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This fixes a seemingly long-running bug; we only brought down networking
in shutdown/halt and for runlevel 1, single-user mode -- not reboot.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
In commit f0f358a13:
[ service.c: set/clear condition 'done' for run tasks ]
a runtask done condition would be set/cleared when entering DONE/HALTED
states, but it did not cover all the user cases, for instance, sometimes
an end user may want to know if a runtask has finished sucessfully or
to decide what to do on its failures.
So we now change the conditions to: tsktype/tskname/success and
tsktype/tskname/failure.
And this change not only applies to run/task types, but also applies to
sysv type, in case it fails, a sysv/tskname/failure condition would be
set.
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Refactor new kill/shutdown implementation from 3e0063e to fix the
regression in compiler output:
sig.c: In function ‘kill_callback’:
sig.c:222:12: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
222 | kill(pid, (int)context);
| ^
Also, some minor renames and simplificactions to match project style.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Check all pointers
- Declaratons always at top of func/scope
- Use established variable nomenclature
- Skip useless if() stmt
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Comments preferably at beginning of func/sect
- Reorder code slightly, add whitespace for readability
- Drop useless comment
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit implements a test for the signal feature of initctl. The
existing service used in tests (`common/service.sh`) has been extended
with a signal trap handler. When SIGUSR1 is received, it will write the
string `'USR1'` to `/tmp/usr1.log`. The test will run `initctl signal
service.sh SIGUSR1` and assert that the contents of the file
`/tmp/usr1.log` really is `USR1`.
The implementation looks up the named service by using
`svc_parse_jobstr`. The callbacks for `svc_parse_jobstr` has been
augmented to accept a user data parameter. For this use case,
a carrier for the actual signal was needed. The address of the
signal parameter is taken and passed on as a `void *`. The
callback then simply deferences it as an int - the signal number.
In the test framework for finit, a set of shell scripts are used to
setup a test harness, run tests, and finalize tests. In the setup, a
file system is created for the virtualized/containerized environment in
which all tests are run, located at `$FINIT_SRC/test/tenv-root`. In the
tear down phase of each test, the file `/var/lock` is made readable
using `chmod +r`. It is not clear _why_ the teardown code does this, as
there are no references in the test framework to this path anywhere
else. It is conceivable that the teardown phase attempted to "reset the
state" for next test.
The code that that this commit removes does not always work. When
`/var/lock` is a symlink, and resolves to an absolute path, the test
framework does not function properly. The teardown code is run in the
context of the host computer, and touching files outside of the
virtualized environment is not ok.
The removal of the offending code does not seem to affect tests: all
tests pass without it, so its existence is questionable.
Signed-off-by: Jörgen Sigvardsson <jorgen.sigvardsson@gmail.com>
Joachim Wiberg