== 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_:

.pn prewrap on

>  dd if=/dev/zero of=/dev/sda bs=1024k count=32; sync
>  reboot

(The _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 _kill_ or
other necessary bits have been damaged by that _dd_. Finally,
I think that systemd can handle calling _reboot()_ internally,
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_. _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).