[systemd-devel] Antw: Re: Antw: failing unmounts during reboot

2019-08-04 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 01.08.2019 um 20:38 in
Nachricht :
> 29.07.2019 9:38, Ulrich Windl пишет:
> Ulrich Windl schrieb am 29.07.2019 um 08:23 in Nachricht <5D3E90D1.4EC :
161 
> :
>> 60728>:
>> Frank Steiner  schrieb am 25.07.2019 um
14:14 
> in
>>> Nachricht <913a3c04-a666-b44b-c6ec-fe3d8a7fe...@bio.ifi.lmu.de>:
 Ulrich Windl wrote:

> *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

 I cannot confirm that, at least not for SLES/D 15. All mount units
 for NFS filesystems created from fstab get "Before=remote-fs.target",
 so they are shutdown before the network goes down. Check in
 /run/systemd/generator to see if this entry is missing in your units.
>>>
>>> In SLES12 SP4 (originally reported for SP3) I have:
>>> # Automatically generated by systemd-fstab-generator
>>>
>>> [Unit]
>>> SourcePath=/etc/fstab
>>> Documentation=man:fstab(5) man:systemd-fstab-generator(8)
>>> Before=remote-fs.target
>>>
>>> [Mount]
>>> What=server:/exports/home
>>> Where=/home
>>> Type=nfs
>> 
>> Sorry I hit "send" too quickly:
>> That would mean the problem of not being unable to umnount /home is not
that 
> the network is down, but that some process still has open  files on /home.
>> 
>> However from the original problem report:
>> 
>> [  OK  ] Stopped target Host and Network Name Lookups. 
>>   Stopping Name Service Cache Daemon... 
>> [  OK  ] Stopped target Network. 
>>   Stopping wicked managed network interfaces... 
>> [  OK  ] Stopped Name Service Cache Daemon. 
>> [  OK  ] Stopped wicked managed network interfaces. 
>>   Stopping wicked network nanny service... 
>> [  OK  ] Stopped Check if the profile matches the system. 
>> [  OK  ] Stopped wicked network nanny service. 
>>   Stopping wicked network management service daemon... 
>> [  OK  ] Stopped wicked network management service daemon. 
>>   Stopping wicked DHCPv4 supplicant service... 
>>   Stopping wicked AutoIPv4 supplicant service... 
>>   Stopping wicked DHCPv6 supplicant service... 
>> [  OK  ] Stopped wicked DHCPv4 supplicant service. 
>> [  OK  ] Stopped wicked DHCPv6 supplicant service. 
>> [  OK  ] Stopped wicked AutoIPv4 supplicant service. 
>>   Stopping D-Bus System Message Bus... 
>> [  OK  ] Stopped SuSEfirewall2 phase 1. 
>> [  OK  ] Stopped D-Bus System Message Bus. 
>> [  OK  ] Stopped target Basic System. 
>> [  OK  ] Stopped target Sockets. 
> 
> Stopping (or at least attempt to stop) /home should have happened before
> these lines.
> 
>> ... I would call that a "network shutdown"...
>> [  OK  ] Stopped target Host and Network Name Lookups. 
>>   Stopping Name Service Cache Daemon... 
>> [  OK  ] Stopped target Network. 
>>   Stopping wicked managed network interfaces... 
>> [  OK  ] Stopped Name Service Cache Daemon. 
>> [  OK  ] Stopped wicked managed network interfaces. 
>>   Stopping wicked network nanny service... 
>> [  OK  ] Stopped Check if the profile matches the system. 
>> [  OK  ] Stopped wicked network nanny service. 
>>   Stopping wicked network management service daemon... 
>> [  OK  ] Stopped wicked network management service daemon. 
>>   Stopping wicked DHCPv4 supplicant service... 
>>   Stopping wicked AutoIPv4 supplicant service... 
>>   Stopping wicked DHCPv6 supplicant service... 
>> [  OK  ] Stopped wicked DHCPv4 supplicant service. 
>> [  OK  ] Stopped wicked DHCPv6 supplicant service. 
>> [  OK  ] Stopped wicked AutoIPv4 supplicant service. 
>>   Stopping D-Bus System Message Bus... 
>> [  OK  ] Stopped SuSEfirewall2 phase 1. 
>> [  OK  ] Stopped D-Bus System Message Bus. 
>> [  OK  ] Stopped target Basic System. 
>> [  OK  ] Stopped target Sockets. 
> 
> Do you really have identical lines second time in your log?

No, I guess it was a double-paste error on my side.

> 
> You need to provide full "systemctl show home.mount" and complete log
> from boot to shutdown.

Well, it just looked too complex to me (complete logs maybe next time I boot:
Where=/home
What=server:/exports/home
Options=rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=t
Type=nfs4
TimeoutUSec=1min 30s
ControlPID=0
DirectoryMode=0755
SloppyOptions=no
Result=success
Slice=system.slice
ControlGroup=/system.slice/home.mount
MemoryCurrent=18446744073709551615
CPUUsageNSec=18446744073709551615
TasksCurrent=0
Delegate=no
CPUAccounting=no
CPUShares=18446744073709551615
StartupCPUShares=18446

Re: [systemd-devel] Antw: Re: Antw: failing unmounts during reboot

2019-07-25 Thread Lennart Poettering
On Do, 25.07.19 12:52, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > "try to kill all processes using a filesystem before unmounting it"
> > isn't that easy when it comes to namespaces, "lsof" even don't tell you
> > the root cause preventing unmount but the ernel still refuses to do so
>
> Does systemd even try to use lsof?

No, of course not. We tend to avoid hacks like that.

We generally expect packages to come with proper ordering in place,
and when they still insist on SysV init scripts to work properly and
clean up after themselves though.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Antw: failing unmounts during reboot

2019-07-25 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 25.07.2019 um 12:16 in
Nachricht <1bd5766b-018c-10f9-b2b2-46fc78ddd...@thelounge.net>:

> Am 25.07.19 um 12:08 schrieb Ulrich Windl:
>> Before systemd (almost) all processes were killed before unmounting
> 
> that's often a transfigured point of view
> 
> many issues where there also before systemd but never got noticed and

Believe me I would have noticed of NFS /home failed to unmount during reboot!

> after change to systemd they got visible, just because a sysvinit don't
> tell you about a problem because of missing error handling don't mean
> there is none

They became visible, because trhe did not exist before!

> 
> the same with emergeny shell which covers nearly all cases where you
> needed to start a livesystem before and now you have a working
> environment where you can fix the root cause way quicker

I completely disagree.

> 
> "try to kill all processes using a filesystem before unmounting it"
> isn't that easy when it comes to namespaces, "lsof" even don't tell you
> the root cause preventing unmount but the ernel still refuses to do so

Does systemd even try to use lsof?

> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 




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