failing unmounts during reboot

[Frank Steiner <fsteiner-mail1@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?

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?
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.

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