Systemd Reboot – Difference Between `systemctl start reboot.target` and `systemctl reboot`

rebootsystemd

There are two documented differences between start reboot.target and reboot. But start reboot.target is what is triggered by ctrl-alt-del.target.

Does it matter that ctrl-alt-del.target will omit --job-mode=replace-irreversibly? In what situations will this cause different behaviour? Why is it included by systemctl reboot?

man systemctl

reboot [arg]

Shut down and reboot the system. This is mostly equivalent to start reboot.target --job-mode=replace-irreversibly, but also prints a
wall message to all users.

man systemd.special

ctrl-alt-del.target:
systemd starts this target whenever Control+Alt+Del is pressed on the console. Usually, this should be aliased (symlinked) to
reboot.target.

Best Answer

When queuing a new job, this option controls how to deal with already queued jobs. It takes one of "fail", "replace", "replace-irreversibly", "isolate", "ignore-dependencies", "ignore-requirements" or "flush". Defaults to "replace", except when the isolate command is used which implies the "isolate" job mode.

If "fail" is specified and a requested operation conflicts with a pending job (more specifically: causes an already pending start job to be reversed into a stop job or vice versa), cause the operation to fail.

If "replace" (the default) is specified, any conflicting pending job will be replaced, as necessary.

If "replace-irreversibly" is specified, operate like "replace", but also mark the new jobs as irreversible. This prevents future conflicting transactions from replacing these jobs (or even being enqueued while the irreversible jobs are still pending). Irreversible jobs can still be cancelled using the cancel command.

This suggests a practical effect. Suppose you "hook units into the sleep state logic", using sleep.target to pull them in. Your hook units do not have DefaultDependencies=no, so they depend on sysinit.target... and Conflict with shutdown.target.

If you run systemctl start reboot.target and then immediately systemctl start suspend.target, it seems that your hook unit will stop shutdown.target. Now systemd-reboot.service has Requires=shutdown.target, so it should be stopped/cancelled as well. (umount.target should not be cancelled).

I have verified a difference in behaviour along these lines and reported it as a defect in the systemd issue tracker.

Related Question