When some transient unit setting is received over D-Bus, we write it it to a transient unit file. We escape backslashes and specifiers. For most settings this is enough, because most settings only do parsing and interpolation of specifiers. When systemd-run is called (or something equivalent that gives us a command strv), we write ExecStart=, but when reading it, we not only do parsing and interpolation of specifiers, but also split on semicolons and do variable substitution. This results in an ugly situation where the commandline is interpolated twice, once on the caller side, and once in the manager. I think we need to treat this as a bug: current behaviour seems to be an accident of implementation and hard to explain in a reasonable way. If we *were* doing specifier expansion, then it'd be somewhat reasonable so say that "the commandline is handled the same as ExecStart=". But since we explicitly prevent specifier expansion, we best we could say is "the commandline has some subset of features of ExecStart=". I think this is not useful, and unexpected by users. Since most people use use a shell to call systemd-run, one level of variable expansion is already done on the caller side, and having to take into account another level of expansion (with slightly different rules), creates a big mental overhead when the commandline needs to include a dollar character or such. Not doing any expansion is much cleaner and easier to explain or use. Thus I think it's better to change behaviour here, even though in principle some people could be relying on current behaviour. I think it's more likely that nobody noticed, because people generally don't use systemd-run for complicated commandlines. Thus this commit adds an additional mode of escaping that prevents variable explansion and other elements of ExecStart= syntax. I looked over all the places where unit_escape_setting() is called, and I think that only two need to be changed to use the new flag. Fixes #23631.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.
