Bug 1074074 - suspend hibernate resume doesn't work, /etc/NetworkManager/dispatcher.d/nfs
suspend hibernate resume doesn't work, /etc/NetworkManager/dispatcher.d/nfs
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: GNOME
Current
All Other
: P2 - High : Normal (vote)
: ---
Assigned To: Jonathan Kang
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-25 20:32 UTC by Ralf Friedl
Modified: 2022-07-04 01:55 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
improved nfs script (2.28 KB, application/x-shellscript)
2018-11-08 08:38 UTC, Jonathan Kang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Friedl 2017-12-25 20:32:27 UTC
I have current Tumbleweed with systemd-234-9.1.x86_64 and NetworkManager-1.8.4-4.1.x86_64.

When I do Suspend (to RAM) or Hibernate (to Disk), the system is no longer usable after resume, /proc, /sys, /dev, /run, and probably other filesystems are not usable. I traced this to /etc/NetworkManager/dispatcher.d/nfs where the root partition is unmounted.

Here a part of the strace output:
> 3132  execve("/etc/NetworkManager/dispatcher.d/nfs", ["/etc/NetworkManager/dispatcher.d/nfs", "wlan0", "down"], 0x55a1a867ec00 /* 7 vars */) = 0
> 3156  execve("/usr/bin/umount", ["umount", "-l", "-f", "/"], 0x55808b81f390 /* 10 vars */) = 0
> 3156  lstat("/proc/3156/mountinfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> 3156  umount2("/", MNT_DETACH)  = 0
> 1     openat(AT_FDCWD, "/proc/self/mountinfo", O_RDONLY|O_CLOEXEC)   = -1 ENOENT (No such file or directory)

As you can see, immediately after umount root, /proc is no longer accessible.

The problem is /etc/NetworkManager/dispatcher.d/nfs:57
> NET_MOUNTS=$(sed -e '/^.*#/d' -e '/^.*:/!d' -e 's/\t/ /g' /etc/fstab | tr -s " ")$'\n'b
On my system, the output of this command is
> /dev/disk/by-id/md-uuid-XXXXXXXX:XXXXXXXX:XXXXXXXX:XXXXXXXX / ext4 defaults,acl,user_xattr 1 1
I verified that an "exit 0" at the start of the file solves my problem.

I'm not sure whether it is actually necessary to unmount NFS filesystems, but the test should make sure that the filesystem is actually NFS, and probably that the filesystem is not root. Or is there a way to recover from "umount -l -f /"? Trying to mount /proc, /sys or any other filesystem manually failed.
Comment 1 Ralf Friedl 2018-01-11 05:46:17 UTC
With NetworkManager-1.8.4-5.1.x86_64 the problem is still the same.

For a simple fix, just change the pattern from "^.*:" to "^[^/]*:".
A hostname for a NFS share should not contain a '/', while device files in /dev do.
Comment 2 Ralf Friedl 2018-02-11 11:11:48 UTC
After some updates, now to NetworkManager-1.10.2-1.1.x86_64, the problem is still the same.
Comment 3 Jonathan Kang 2018-11-08 08:38:29 UTC
Created attachment 788984 [details]
improved nfs script

Hi Ralf

Could you please use the attched nfs script to replace the one in your system
and see if it fixes your issue?

Thanks
Comment 4 Ralf Friedl 2018-11-19 18:48:44 UTC
(In reply to Jonathan Kang from comment #3)
> Could you please use the attached nfs script to replace the one in your system
> and see if it fixes your issue?

Yes, it does, thank you.

On an unrelated note, is there a reason to use

> $(echo $line | cut -f2 -d" ")

instead of

> while IFS= read -r MOUNT_DEVICE MOUNT_POINT FS_TYPE REST; do
Comment 5 Jonathan Kang 2018-11-20 06:53:05 UTC
(In reply to Ralf Friedl from comment #4)
> On an unrelated note, is there a reason to use
> 
> > $(echo $line | cut -f2 -d" ")
> 
> instead of
> 
> > while IFS= read -r MOUNT_DEVICE MOUNT_POINT FS_TYPE REST; do

The script was originally written long time ago, and the author only need
MOUNT_DEVICE at that moment. That's the reason I can think of.
Comment 6 Swamp Workflow Management 2018-11-20 09:30:05 UTC
This is an autogenerated message for OBS integration:
This bug (1074074) was mentioned in
https://build.opensuse.org/request/show/650343 Factory / NetworkManager
Comment 7 Jonathan Kang 2018-11-26 02:45:34 UTC
RESOLVED FIXED.
Comment 10 Swamp Workflow Management 2019-10-11 19:38:57 UTC
SUSE-RU-2019:2639-1: An update that has two recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1074074,1146935
CVE References: 
Sources used:
SUSE Linux Enterprise Workstation Extension 15-SP1 (src):    NetworkManager-1.10.6-5.12.1
SUSE Linux Enterprise Workstation Extension 15 (src):    NetworkManager-1.10.6-5.12.1
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src):    NetworkManager-1.10.6-5.12.1
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src):    NetworkManager-1.10.6-5.12.1
SUSE Linux Enterprise Module for Desktop Applications 15-SP1 (src):    NetworkManager-1.10.6-5.12.1
SUSE Linux Enterprise Module for Desktop Applications 15 (src):    NetworkManager-1.10.6-5.12.1
SUSE Linux Enterprise Module for Basesystem 15-SP1 (src):    NetworkManager-1.10.6-5.12.1
SUSE Linux Enterprise Module for Basesystem 15 (src):    NetworkManager-1.10.6-5.12.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 11 Swamp Workflow Management 2019-10-16 22:11:59 UTC
openSUSE-RU-2019:2322-1: An update that has two recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1074074,1146935
CVE References: 
Sources used:
openSUSE Leap 15.0 (src):    NetworkManager-1.10.6-lp150.4.12.1