a71be850b5
We would print "Current command vanished from the unit file, execution of the command list won't be resumed." as a warning, but most of the time there is nothing to resume, because a unit has just one command. So let's detect the case where the command that was active is the last command in the sequence and skip the warning. I was considering how to store the information that the command is last. An important consideration is not to use a format that would confuse older versions of systemd. (It wouldn't be a big problem if older systemd just refused the new serialization, since we require systemd to be newer, but we should avoid the case where the deserialization is "successful", but actually incorrect.) Similarly, the deserialization from the old systemd must not confuse new systemd. For this command, we have a list of arguments at the end, so just adding a new field either in the middle or at the end is problematic because it's hard to ensure that we don't mix up the positional and variable arguments. We actually need to store just one bit of information, so '+' is prefixed on the index of the last command and used by new systemd to skip the warning. When deserializing from older systemd, '+' is not present, so we detect all commands as "not last", and still emit the warning, so we err on the side of caution. If the user were to deserialize from newer to older systemd, nothing untoward would happen, because the '+' is ignored. (Users shouldn't do this, but we know that this occasionally happens with initrds or exitrds and package downgrades.) (cherry picked from commit a99bd455b59b7922a1b1af480b209263a4d3c659) (cherry picked from commit 9bb72a4e9694ec301d89861e349eb31fbf1aba16)
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.