BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] systemd reboot
- Subject: [Discuss] systemd reboot
- From: smallm at sdf.org (Mike Small)
- Date: Sat, 03 Mar 2018 02:09:21 +0000
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 time... 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
- Follow-Ups:
- [Discuss] systemd reboot
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] systemd reboot
- From: slitt at troubleshooters.com (Steve Litt)
- [Discuss] systemd reboot
- Next by Date: [Discuss] systemd reboot
- Next by thread: [Discuss] systemd reboot
- Index(es):