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.


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.


From reading the source of the reboot.target file, we see that ctrl-alt-del.target is referenced with Alias=, meaning it's another name for the same command and will work the same way.

Looking at the source code of systemctl.c, we also see that systemctl reboot will pass the replace-irreversibly option.

So it appears that all three variations of reboot commands you found work the same: systemctl reboot, reboot.target and ctrl-alt-del.target.

If you have a proposal for improving the documentation, you can modify the source XML files for the systemd documentation and submit a pull request.

  • Why would we want to look at the source of systemctl? Of course it matches the documentation quoted. Both tell us that systemctl start reboot.target will not automatically pass --job-mode=replace-irreversibly, and therefore will not work exactly the same as systemctl reboot.
    – sourcejedi
    Jul 26 '17 at 19:45
  • start reboot.target causes reboot.service to run, which in turn calls ExecStart=/bin/systemctl --force reboot, which as described above does pass the --job-mode=replace-irreversibly option, so they all work the same. You can search for the reboot.target and reboot.service files on yoru system and read them to confirm. Jul 26 '17 at 20:02
  • Nope! Read the documentation for --force. systemctl --force reboot doesn't manipulate units, so there isn't a job mode to be concerned with. It just runs systemd-shutdown. Look at the systemctl code. (although it goes through a systemd dbus method instead of launching directly, I haven't looked what the benefit is of that). My question stands. (Also, there is no reboot.service :-P).
    – sourcejedi
    Jul 26 '17 at 20:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.