I should be able to find my answers in the man pages or other systemd
documentation but I'm getting fatigued reading them. So if you have the

I see behaviour where if I change something under /etc/grub.d/, run
update-grub and then immediately run /sbin/reboot, upon start up grub
sees the old grub.cfg not the new one. This is a Ubuntu Xenial based
system where /sbin/reboot is a symlink to systemctl. I'm not at the
machine but I think /boot is on the root filesystem instead of having
its own partition. Questions...

1. Presumably reboot should itself or via systemd unit dependencies sync
buffer cache to disk or at least try to. E.g. on OpenBSD the docs are
straightforward, from reboot(8): "The halt and reboot utilities flush
the file system cache to disk, execute the rc.d(8) scripts specified by
the pkg_scripts variable defined in rc.conf(8) in a reverse order, run
the system shutdown script, send all running processes a SIGTERM (and
subsequently a SIGKILL), and, respectively, halt or restart the system."
So what are the assurances her for Linux with systemd, and is there a
way it can go wrong?

2. What is the mechanism? So far I'm thinking it's not in reboot,
a.k.a. systemctl itself.  I see a dependency graph at the end of
bootup(7) that suggests systemd-reboot.service precedes the
reboot.target. Is that what's responsible for the syncing?

3. systemd-reboot.service(7) (or maybe it's systemd-halt.service(7), I'm
looking online at html and the labeling is poor) says, "immediately
before executing the actual system halt/poweroff/reboot/kexec
systemd-shutdown will run all executables in
/usr/lib/systemd/system-shutdown/" So that maybe is where syncing could
happen? If when I'm back at the machine I look in there I might expect
to see script or executables that do this, or if not the machine is
incorrectly configured?

4. Somewhere I thought I read something to the effect that the root file
system was a special case. I can't find it now, but I thought I read
that systemd won't unmount it (but maybe could sync it?) but instead
will leave that to initrd scripts that it will return to when systemd
terminates. Does that even make sense? If so can you think where I might
have read this?

5. /sbin/reboot is a symlink to systemctl. Does that mean running it is
equivalent to running systemctl with a certain argument, e.g. reboot?
I've somehow missed where this is documented. There seem to be various
ways to run systemctl to do a reboot: systemctl reboot or systemctl
start reboot.target with varous args. systemctl(1) says reassuring
things under its reboot command so long as you don't give the force
argument twice, but I can only guess or read the source code to know if
that's what running the reboot symlink does. That section of the man
page also says something alarming about a command being asynchronous,
but I'm hoping that means the wall message command and not the reboot
command itself or some part of it like syncing to disk.

- Mike
Discuss mailing list

Reply via email to