<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - systemctl needs a --setenv option for per-unit environment modification"
href="https://bugs.freedesktop.org/show_bug.cgi?id=90100">90100</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>systemctl needs a --setenv option for per-unit environment modification
</td>
</tr>
<tr>
<th>Product</th>
<td>systemd
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>general
</td>
</tr>
<tr>
<th>Assignee</th>
<td>systemd-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>w.rouesnel@gmail.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>systemd-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>