RFE: Custom service actions/commands

[gdamjan]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

any

Used distribution

any / Arch

Explanation

systemd unit files can/do keep a lot of state about services, for example: the user/group, capabilities, the working directory, environment variables, possibly also private mounts (private tmp, #3439 etc)…

it would be very usefull to run commands in the same exact environment as the service itself, examples are:
dropdb/initdb/migrate-data/filescan/populatecache and similar.

one approach would be for the .service file to have ExecAction=initdb=command directives that would be invoked with systemctl action initdb a-service.service. Another approach would be extending systemd-run:
with something like systemd-run --inherit=a-service command. (--inherit, --use, --unit or some such).

[poettering]

This has been requrested before, and I understand why you want it, but I am still not convinced this is a good idea...

[gdamjan]

(couldn't find a previous discussion, that's why I opened the issue)

@poettering in what way do you think it's not a good idea? regarding complicating pid1 or more general?
do you have some other suggestions/ideas?

afiak, a systemd-run implementation wouldn't need pid1 modifications, so that might be more acceptable?

[gdamjan]

One way to do it in systemd-run would be:

• dump all the service configuration
• remove all Exec* directives,
• add ExecStart= to the command supplied to systemd-run
• set Type= (oneshot by default)
• add JoinsNamespaceOf=the-original.service

now run this

[septatrix]

In general I agree with poettering that this is not in the scope of an init system. There are two inherently contradictory sides here which are very hard to accommodate for:

• People want custom verbs for all kinds of things (logrotate, graceful-restart, initialize-database, migrate, check-config, ...).
• People want a new, fixed set of verbs for clearly defined actions (graceful-restart, check-config, ...).

The problem with allowing only specific verbs is that they (as lennart already said) are inherently application specific. Should a graceful restart use protocol-specific packets to indicate connection termination (e.g. would an LDAP server send NoticeOfDisconnection), should it wait for those connections to terminate themselves, what about very long-running connections (e.g. websockets), would it still terminate connections after some timeout...? Does logrotate rotate the log files itself or does it rely on another process like logrotate to already have renamed the underlying log file and simply performs a new open of the log file under the usual name?
On the other hand if systemd adds verbs for all of these (or custom verbs) they can no longer have a specific meaning and it becomes unclear what they do: systemctl most-graceful-restart, systemctl gracefulish restart etc. Also there would be no standardization (or at least no more than there is today): One developer might implement it as check-config and another one as verify-config etc.

One of the verbs which systemd supports and is one marginally related to process lifecycle is system-log-level using the org.freedesktop.LogControl1 API. And even in that case the interface is rather static and does not accommodate several use cases: e.g. for a web server I could want to reduce the verbosity of each log line (omit IP) but still log every connection...
So yeah, there is a lot of complexity which one might not think about when support more/custom verbs.

This does not mean that there are no areas where systemd could improve. I could certainly image a world in which systemd would add a send-notify [MESSAGE] verb which would just send the message to the service using sd_notify. This, of course, is only possible for actions where the service is already active, e.g. logrotate, or graceful-restart. Something like config verification or migration might not fit into the execution model of the service.

So yeah, a whole lot of complexity for arguably little use... Instead services should rather adopt modern practices:

• Always perform a graceful restart, for other purposes there is systemctl kill [--signal],
• do not log to files but directly to stdout or journald,
• allow for online config reloading and return an error when it is not valid but still keep running,
• initialize database on first start, and migration on every start - optionally as a ExecPreStart=,
• ...

[gdamjan]

my use-case is a bit more broad and currently hard to use in systemd.

One example, I'm running Nextcloud as a portable service (so DynamicUser=yes, StateDirectory=nextcloud, Environment=NEXTCLOUD_CONFIG_DIR=/var/lib/nextcloud/config, etc etc).

Nextcloud has its occ tool, which is mandatory for operating Nextcloud (not only if the web-ui is non-working). That tool really needs to run in the same context as the service itself, same uid, same mounts, same environment variables, otherwise it will not work at best, break file permissions and run havoc at worst.

Now, I can do that with an elaborate systemd-run invocation, but it's tedious and error-prone.

something like sudo systemd-run --uid nextcloud --shell -p StateDirectory=nextcloud -p DynamicUser=yes -E NEXTCLOUD_CONFIG_DIR=/var/lib/nextcloud/config -E PHP_INI_SCAN_DIR=:/etc/php/nextcloud works, but again, it's not really using all of the same directives as the service.