Antw: failing unmounts during reboot

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Frank Steiner <fsteiner-mail1@xxxxxxxxxxxxxx> schrieb am 25.07.2019 um 11:40 in
Nachricht <3d410499-649b-f012-afd8-fcfbfef7aeaf@xxxxxxxxxxxxxx>:
> Hi,
> 
> I'm currently discussing a problem with the SuSE support about failing
> unmounts during reboot. Tyring to debug this I realized that systemd
> is not killing processes left over by some init.d script. E.g. use
> the following script in /etc/init.d/
> 
> #!/bin/sh
> #
> ### BEGIN INIT INFO
> # Provides: bla
> # Required-Start: $network $remote_fs sshd
> # Required-Stop: $network $remote_fs sshd
> # Default-Start:  2 3 5
> # Description:    test
> ### END INIT INFO
> case "$1" in
>       start) cd /test; /usr/bin/sleep 99d & ;;
>        stop) true;;
> esac
> 
> 
> On shutdown, unmounting /test will fail because the sleep process is
> not killed. Shouldn't there be a mechanism in system to kill processes
> spawned by LSB script when shutting these down?

*1: I have a support call open with SUSE:
Before systemd (almost) all processes were killed before unmounting.
With systemd I'm seeing excessive reboot delays due to unmount timing out. For example if you have a process started from NFS that has a log file on NFS open, too.
It seems the order is roughly like this:
1) Shutdown the network
2) Try unmounting filesystems, including NFS
3) Kill remaining processes

> 
> And moreover, wouldn't it make sense to have a mechanism to at least
> try to kill all processes using a filesystem before unmounting it?

+2!

> We often see failing unmounts of several local or iscsi fs during
> reboot, and in the support case we are currently working on with SuSE
> failing iscsi fs even cause xfs I/O errors. So it might be a good idea
> to have sth. like a lsof + kill before unmounting a filesystem, maybe
> configurable with a flag to enable or disable it. Even if lsof or kill
> failed, it wouldn't be worse than now.
> 
> As far as I see there is no way to write a drop-in for a mount unit
> that allows to execute commands before the unmount happens, is that
> right? Sth. like "ExecPreUmount=" would help here, especially if there
> was sth. like a umount@.service that would be called for every umount
> with e.g. the mounpoint accessable with a variable.

I'm not allowed to talk about systemd frustration here ;-)

> 
> cu,
> Frank
> 
> -- 
> Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/ 
> Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/ 
> LMU, Amalienstr. 17           Phone: +49 89 2180-4049
> 80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
> * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
> _______________________________________________
> systemd-devel mailing list
> systemd-devel@xxxxxxxxxxxxxxxxxxxxx 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 




_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel