A tiny systemd convenience: it can reboot the system from RAM alone
One of the things I do a fair bit of is building and testing
from-scratch system installs. Not being crazy, I do this in virtual
machines (it's much faster that way). When you do this sort of work,
you live in a constant cycle of installing a machine from scratch,
testing it, and then damaging the install enough so that when you
reboot, your VM will repeat the 'install from scratch' part. Most
of the time, the most convenient way to damage the install is with
dd if=/dev/zero of=/dev/sda bs=1024k count=32; sync reboot
sync can be important.)
Dd'ing over the start of the (virtual) disk makes sure that there isn't a partition table and a bootloader any more, and it also generally prevents the install CD environment from sniffing around and finding too many traces of your old installed OS.
On normal System V init or Upstart based systems, this sequence has
a minor little irritation: the
reboot will usually fail. This is
because the reboot process needs to read files off the filesystem,
which you've overwritten and corrupted with the
dd. Then you (I)
get to go off to the VM menus and say 'power cycle the machine',
which is just a tiny little interruption.
With systemd, at least in Ubuntu 16.04, this doesn't happen. Sure, a number of things run during the reboot process will spit out various errors, but systemd continues driving everything onwards anyways and will successfully reboot my virtual machine with no further activity on my part. The result is every so slightly more convenient for my peculiar usage case.
I believe that systemd can do this for several reasons. First,
systemd parses and loads all unit files into memory when it starts
up (or you tell it '
systemctl daemon-reload'), which means that
it doesn't have to read anything from disk in order to know what
needs to be done to shut the system down. Second, systemd mostly
terminates processes itself; it doesn't need to repeatedly get
scripts to run
kill and the like, which could fail if
other necessary bits have been damaged by that
I think that systemd can handle calling
instead of having to run an executable (which might not be there)
in order to do this.
(Systemd clearly has internal support in PID 1 for rebooting the system under some circumstances. I'm not quite clear if this is the path that a normal reboot eventually takes; it's a bit tangled up in units and handling this and that and so on.)
PS: Possibly there is a better way to damage a system this way than
dd has the (current) virtue of being easy to remember and
clearly sufficient. And small variants of this
dd command work on
any Unix, not just Linux (or a particular Linux).