Bug 228786 - automount interferes with suspend
Summary: automount interferes with suspend
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 11.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Edward Tomasz Napierala
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-06 16:30 UTC by Jason W. Bacon
Modified: 2019-09-02 01:31 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason W. Bacon freebsd_committer freebsd_triage 2018-06-06 16:30:12 UTC
I've had issues with my laptops occasionally freezing during suspend (S3 state) and traced the problem to automount with NFS.

Since adding "automount -u" to /etc/rc.suspend (above /usr/bin/logger), I've had no more suspend/resume failures.

I think the default rc.suspend should check for running automount and do an automount -u if necessary.

This problem occurred on 10.x and 11.x.
Comment 1 Edward Tomasz Napierala freebsd_committer freebsd_triage 2018-07-30 12:00:47 UTC
I've never run into that problem.  Could you tell me some more about what happens exactly?
Comment 2 Jason W. Bacon freebsd_committer freebsd_triage 2018-07-30 13:44:27 UTC
I have an NFS server at home and the following auto_master:

# $FreeBSD: releng/11.1/etc/auto_master 310007 2016-12-13 04:44:06Z dteske $
#
# Automounter master map, see auto_master(5) for details.
#
/net            -hosts          -nobrowse,nosuid,intr
# When using the -media special map, make sure to edit devd.conf(5)
# to move the call to "automount -c" out of the comments section.
#/media         -media          -nosuid,noatime
#/-             -noauto

If an NFS server is mounted when S3 is initiated (e.g. by closing my laptop), it will freeze before reaching S3 state.

After I added automount -u to rc.suspend, it never froze again.

# If a device driver has problems suspending, try unloading it before
# suspend and reloading it on resume.  Example:
# kldunload usb

automount -u

/usr/bin/logger -t $subsystem suspend at `/bin/date +'%Y%m%d %H:%M:%S'`
/bin/sync && /bin/sync && /bin/sync
/bin/sleep 3
Comment 3 Rodney W. Grimes freebsd_committer freebsd_triage 2018-07-30 14:43:21 UTC
Put a CC: bugs back on this so it can be assigned into the right group and not end up rabbit holed byt the broken take process.
Comment 4 Edward Tomasz Napierala freebsd_committer freebsd_triage 2018-07-30 15:08:32 UTC
Hm.  I'd say it's a problem with NFS then, not automount - and the workaround should be more like "umount -At nfs".

Still, would be nice to figure out the root cause for this.  What's your network adapter?
Comment 5 Jason W. Bacon freebsd_committer freebsd_triage 2018-08-08 15:17:48 UTC
The problem has occurred on multiple laptops.  The two I use most are using rtwn and iwn (wifi) most of the time.  They have re and im Ethernet, but I don't often plug in.

I'll run with

umount -A -t nfs

in my rc.suspend for a while and report and report back on any issues.

I assume it's safe to manually unmount behind automount's back this way.  I used automount -u initially to ensure that automount was aware of any status changes to filesystems it controls.
Comment 6 Edward Tomasz Napierala freebsd_committer freebsd_triage 2018-08-08 15:36:49 UTC
Yes, it's safe - "automount -u" is really just a kind of an user-friendly shortcut so that you don't need to manually figure out which filesystems to unmount.
Comment 7 Jason W. Bacon freebsd_committer freebsd_triage 2018-10-22 01:19:21 UTC
Oddly, about a week after I switched to "umount -A -t nfs", I experienced a couple more freezes.  I switched back to "automount -u" and it hasn't froze again since.  Doesn't really make sense to me and could be a coincidence with only two data points, but thought I should share what info I have.
Comment 8 Jason W. Bacon freebsd_committer freebsd_triage 2019-09-02 01:31:36 UTC
No longer seeing this issue with current releases.