Commit d85515edcf changed logic how reboot is
executed. That commit changed behavior to use emergency action reboot code path
to perform the reboot.
This inadvertently broke rebooting with argument:
$ systemctl reboot custom-reason
Restore original behavior so that if reboot service unit similar to
systemd-reboot.service is executed it is possible to override reboot reason
with "systemctl reboot ARG".
When "systemctl reboot ARG" is executed ARG is placed in file
/run/systemd/reboot-param and reboot is issued using logind's Reboot
dbus-service.
If RebootArgument is specified in systemd-reboot.service it takes precedence
over what systemctl sets.
Fixes: #11828
Invoking %systemd_tmpfiles (in %post) without any arguments, while
possible, will cause systemd-tmpfiles to process the entire system
configuration, rather than just the newly installed configuration
files. In https://github.com/systemd/systemd/pull/12048, it was
established that processing everything constitutes unusual practice,
and should be flagged as a mistake at build time.
Furthermore, invoking %systemd_post without any arguments will cause
the underlying `systemctl preset` to outright return an error ("Too
few arguments") when run. This can be flagged during build time in
the same manner.
As I have found no ways to successfully nest %if clauses inside a
macro[1], I am helping myself by reusing the recursive variable
expansion technique pioneered in [2].
Now, when %systemd_post or %systemd_tmpfiles is incorrectly used,
rpm gives accurate line number reporting, too:
error: This macro requires some arguments
error: line 11: %{systemd_post}
error: This macro requires two arguments
error: line 13: %{tmpfiles_create_package meh more more}
[1] what has been tried: %{expand:%%if "%#" == 0 \\\
%%{error:you have given me %# args} \\\
%%endif}
[2] http://git.savannah.gnu.org/cgit/automake.git/commit/?id=e0bd4af16da88e4c2c61bde42675660eff7dff51
As general principle, we generally check command line args first, the
enviroment second, and external configuration and system state only later.
In case of the invocation ID, checking the keyring before the environment
was implemented as a poor-man's security measure. But this is not really
useful, since we're moving within the same security boundary. So let's just
do the expected thing, and check environment first.
Prompted by https://github.com/systemd/systemd/pull/11991#issuecomment-474647652.