#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.]