* Matthew Giassa <matt...@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: matt...@giassa.net Sent: Tuesday, September 26, 2017 4:15 PM To: systemd-devel@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: matt...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel