#1011 PR merged
: Simplify reboot halt poweroff and shutdown in case of systemd¶
Labels: enhancement
, fixed / solved / done
, minor bug
jsmeix opened issue at 2016-09-26 14:03:¶
The new script
build/GNU/Linux/63_simplify_systemd_reboot_halt_poweroff_shutdown.sh
replaces in case of systemd in the rear recovery system
/bin/reboot /bin/halt /bin/poweroff and /bin/shutdown
by scripts that basically do
"umount -a" and "systemctl --force [reboot halt poweroff]"
to make reboot halt poweroff and shutdown work simpler
and more fail-safe, see
https://github.com/rear/rear/issues/953
jsmeix commented at 2016-09-26 14:06:¶
I tested it on SLES12-SP2-RC2 and with
63_simplify_systemd_reboot_halt_poweroff_shutdown.sh
I get in the recovery system those scripts:
RESCUE g136:~ # cat /bin/reboot #!/bin/bash echo umounting all filesystems umount -vfar &>/dev/null echo reboot in 3 seconds... sleep 3 systemctl --force reboot RESCUE g136:~ # cat /bin/halt #!/bin/bash echo umounting all filesystems umount -vfar &>/dev/null echo halt in 3 seconds... sleep 3 systemctl --force halt RESCUE g136:~ # cat /bin/poweroff #!/bin/bash echo umounting all filesystems umount -vfar &>/dev/null echo poweroff in 3 seconds... sleep 3 systemctl --force poweroff
and
RESCUE g136:~ # cat /bin/shutdown #!/bin/bash command=poweroff for arg in "$@" ; do case "$arg" in (-r|--reboot) command=reboot ;; (-H|--halt) command=halt ;; esac done $command
which seem to work well for me according to my very first tests.
jsmeix commented at 2016-09-26 14:08:¶
Hmm - I think running umount verbose but then
send all to /dev/null is not yet the ultimate solution...
jsmeix commented at 2016-09-26 14:18:¶
Now I umount actually verbosely.
jsmeix commented at 2016-09-26 14:26:¶
The more I use it, the more I like it.
At least for me it seems to "just work".
But I didn't test on a non-systemd machine.
jsmeix commented at 2016-09-27 07:01:¶
@gdha
please do not yet merge it - I like to add some enhancements
to make 63_simplify_systemd_reboot_halt_poweroff_shutdown.sh
work more fail safe.
Furthermore I ask for feedback if you like my verbose umounting
or if I should umount silently?
Personally I prefer verbosity (in contrast to the traditional Unix
behaviour "no news is good news") because I like to see feedback
from the computer that it is actually doing something and what that is
(even if that feedback is low-level technical gibberish that I do not
really understand like kernel boot messages and things like that).
jsmeix commented at 2016-09-27 10:13:¶
Something is wrong with the test if systemd is not used
test -d $ROOTFS_DIR/usr/lib/systemd/system || return 0
that I copied from
build/GNU/Linux/61_verify_and_adjust_udev_systemd.sh
but therin is no comment that explains what that test
is about so that I probably misunderstood its meaning, cf.
https://github.com/rear/rear/wiki/Coding-Style
I tested on a non-systemd machine (SLES11-SP4) in my case
and I got a $ROOTFS_DIR/usr/lib/systemd/system directory.
I.e. it seems in the rear recovery system there is a
/usr/lib/systemd/system directory regardless
whether or not systemd is used?
...investigating...
jsmeix commented at 2016-09-27 10:28:¶
It seems the test if systemd is used in
prep/GNU/Linux/28_include_systemd.sh
is the right one:
if ps ax | grep -v grep | grep -q systemd ; then
Furthermore it seems
usr/share/rear/build/GNU/Linux/10_copy_as_is.sh
copies the content of skel/default/usr/lib/systemd/system
into the rear recovery system regardless
whether or not systemd is actually used
which raises the question what adds that to the COPY_AS_IS
array regardless whether or not systemd is actually used...
jsmeix commented at 2016-09-27 12:33:¶
It is not 10_copy_as_is.sh that copies the content
of skel/default/usr/lib/systemd/system
into the rear recovery system, it is
rescue/default/01_merge_skeletons.sh
that copies the content of skel/default/
into the rear recovery system.
This way the rear recovery system becomes 236K bigger
than actually needed when no systemd is used
$ du -hsc $( find usr/share/rear/skel/default/ | grep systemd ) 16K usr/share/rear/skel/default/etc/systemd 12K usr/share/rear/skel/default/run/systemd 196K usr/share/rear/skel/default/usr/lib/systemd 12K usr/share/rear/skel/default/var/run/systemd 236K total
but that is a different issue.
jsmeix commented at 2016-09-27 14:12:¶
I fixed the test if systemd is used.
Now I use
# Skip if systemd is not used. # Because the scripts below need the systemctl executable and because # via prep/GNU/Linux/28_include_systemd.sh and build/GNU/Linux/10_copy_as_is.sh # systemctl gets only copied into the recovery system if systemd is used, # we can test here (i.e. after build/GNU/Linux/10_copy_as_is.sh had already run) # if /bin/systemctl exists in the recovery system: test -x $ROOTFS_DIR/bin/systemctl || return 0
Now it works for me on SLES12-SP2 with systemd
and on SLES11-SP4 without systemd.
@gdha
if you do not object I think I will merge it tomorrow.
gdha commented at 2016-09-28 08:07:¶
@jsmeix looks perfect to! Thank you for the quick fix.
jsmeix commented at 2017-03-08 11:03:¶
@schlomo
regarding what happens if 'umount -a' fails:
I added the explicit 'umount -a' plus 'sync' and 'sleep 3'
before I call things like 'systemctl --force reboot'
which is an advantage compared to what was
done before according to how I understood it in my
https://github.com/rear/rear/issues/953#issuecomment-249540216
I.e. before there was only plain 'systemctl --force reboot'
without any explicit 'umount' and any delay to give the harddisk
a chance to write its caches onto the actual disk.
But again:
This is all according to my non-systemd-expert
perception of how things seem to work in systemd.
[Export of Github issue for rear/rear.]