Bug 90100

Summary:	systemctl needs a --setenv option for per-unit environment modification
Product:	systemd	Reporter:	Will Rouesnel <w.rouesnel>
Component:	general	Assignee:	systemd-bugs
Status:	RESOLVED WONTFIX	QA Contact:	systemd-bugs
Severity:	enhancement
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Will Rouesnel 2015-04-19 16:47:17 UTC

systemd-nspawn in 218 has added the --setenv option to pass environment variables from the command line to the spawned init daemon.

A missing complement to this is allowing custom environment variables to be passed from systemctl to the unit file being run.

Proposed syntax:
systemctl --setenv KEY=VALUE --setenv KEY2=VALUE2 start SomeUnitFile

This is important since when scripting unit file launches, which in turn may launch containers (or simply other programs) it is desirable to set unknown environment parameters at runtime - i.e. pass a set of environment from systemctl to the unit file environment, to systemd-nspawn, to the container environment.

The current way around this is to write to a (hopefully) available file location, and have the unit file source that environment. Or have the unit file be dynamically generated under /run/systemd. Both of these needlessly increase script complexity.

systemctl already provides a separate set-environment option, but this acts globally on the session, which is undesirable when using local scripts.

A use case for this is when interacting with daemons which run shell scripts externally on certain actions and pass parameters by environment variables - or using units which may contain special debugging option calls.

Comment 1 Lennart Poettering 2015-04-20 13:32:58 UTC

I dont think we should support this. Services can have multiple triggers (think bus, socket, manual, hw activation), and it shouldn't depend on the trigger used with which parameter a service is called.

If you want behaviour like this, then make a template service, and then use %i to reference the instance identifier in the command line or environment block. This makes the parameter part of the service name, which fixes the issues I have.

Alternatively, dynamically create a service with systemd-run or an equivalent tool.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.