[systemd-devel] Question: path-based deactivation or equivalent
matthew at giassa.net
matthew at giassa.net
Tue Sep 26 23:15:47 UTC 2017
I have a project where I'm adding some services to a Raspberry Pi 3,
and have decided to go with systemd being (mostly) responsible for
launching all of the services. All of the server processes use a common
API to do some initial setup (argument parsing, init, etc), drop root
permissions, and then carry out their normal duties. One of these
services is the "master" service, which I want to use to
activate/deactivate other services on-demand.
I started out with path-based activation via systemd, and that
worked fine for bringing up the services as I requested them. However,
it seems there is no equivalent path-based deactivation functionality at
this time [1], so it's definitely not an option on the older OS deployed
on my dev board.
I've looked into finding a suitable workaround, but the only viable
option so far is a hack that involves creating two separate systemd
scripts for a single service [2]. Is there some other functionality to
systemd that would permit me to:
-Activate and deactivate a service on demand (i.e. start it; stop it via
SIGNIT and after a timeout send it SIGKILL).
-Only have a single systemd script per service rather than the
two-scripts-per-service hack noted in [2].
-Allow a non-root (unprivileged) user to invoke my API/wrapper to
start/stop the services/daemons I maintain.
-Provide similar activation logic to path-based activation (i.e. only
start the service if both its dependencies on other services has been
met, AND the path/socket/etc exists).
Some of these services are provided to me in binary-only form, so I
can't necessarily modify all of them from source. Also, I'm not allowed
to use the LD_PRELOAD approach to injecting features. For all intents
and purposes, let's assume I can only modify my "manager" service, and
the systemd scripts for all services.
Thank you for your time and assistance.
Addendum:
------------------------------------------------------------------------
I'm doing this to automate a test suite that evaulates how the
various services handle failure cases when one or more random services
goes up and down. The test suite, like the services/daemons themselves,
is not permitted root access, and has to be able to run as an
unprivileged user (i.e. no "systemctl $SERVICENAME start|stop" is
permitted via the command line). If there's an equivalent to the
path-based activation/deactivation as noted in [2], it makes my life a
lot easier.
Eventually, some services may be able to sidestep the "master"
service, and kill off other services (i.e. dependencies), so having the
"master" service just kill() the other services is not viable long-term.
References:
------------------------------------------------------------------------
1. "RFE: systemd.path should support deactivation #3642",
<https://github.com/systemd/systemd/issues/3642>, Last accessed 2017-09-26.
2. "Can I use systemd to start and stop a service based on the presence
of a file?",
<https://unix.stackexchange.com/questions/286769/can-i-use-systemd-to-start-and-stop-a-service-based-on-the-presence-of-a-file>,
Last accessed 2017-09-26.
More information about the systemd-devel
mailing list