[systemd-devel] Question: path-based deactivation or equivalent

[Matthew Giassa]

* Matthew Giassa <matthew at giassa.net> [2017-09-26 21:07:16 -0700]:

>I know there are workarounds for ExecStart for example, using /bin/bash to evaluate environment variables, but I think that special case only applies to ExecStart, ExecStartPre, and Executor, as they actually get executed rather than just assigned, allowing for some degree of variable expansion.

Correction: ExecStart, ExecStartPre, and ExecStop.

>
>Thank you.
>
>Sent from my BlackBerry 10 smartphone on the Bell network.
>  Original Message  
>From: matthew at giassa.net
>Sent: Tuesday, September 26, 2017 4:15 PM
>To: systemd-devel at lists.freedesktop.org
>Subject: Question: path-based deactivation or equivalent
>
>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.
>

-- 

============================================================
Matthew Giassa, MASc, BASc, EIT
Principal Developer; Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail:   matthew at giassa.net
website:  www.giassa.net


The information contained in this e-mail is intended only for the
individual or entity to whom it is addressed. Its contents (including
any attachments) are confidential and may contain privileged
information. If you are not the intended recipient you must not use,
disclose, disseminate, copy or print its contents.