Bug 813461

Summary: autofs not restarted after suspend
Product: [openSUSE] openSUSE 12.3 Reporter: Jon Nelson <jnelson-suse>
Component: NetworkAssignee: Leonardo Chiquitto <lchiquitto>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P3 - Medium CC: suse
Version: Final   
Target Milestone: ---   
Hardware: All   
OS: openSUSE 12.3   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Jon Nelson 2013-04-04 13:25:06 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0

If I have an nfs share open at suspend-to-ram time, when I un-suspend I can't access the nfs share. Every time it turns out that autofs is dead.

linux-3y3i:~ # rcautofs status
Checking for service automount                                                                                                                                               unused
autofs.service - Automounts filesystems on demand
          Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled)
          Active: inactive (dead) since Wed, 2013-04-03 21:30:25 CDT; 10h ago
        Main PID: 31123 (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/autofs.service

Apr 03 21:30:23 worklaptop systemd[1]: Stopping Automounts filesystems on demand...
Apr 03 21:30:23 worklaptop automount[31123]: umount_autofs_indirect: ask umount returned busy /nfs
Apr 03 21:30:25 worklaptop systemd[1]: Stopped Automounts filesystems on demand.
linux-3y3i:~ # 


I shouldn't have to restart autofs after a suspend-to-ram.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Leonardo Chiquitto 2013-04-22 17:09:49 UTC
Can't reproduce it here yet.
Comment 2 Leonardo Chiquitto 2013-04-22 17:10:03 UTC
1. Are you using NetworkManager?

2. Do you have pm-utils installed? If yes, could you attach
   /var/log/pm-suspend.log here?
Comment 3 Jon Nelson 2013-04-22 20:15:11 UTC
Yes to both questions.
I'm not able to attach the log file as-yet.
However:

1. the systemd service file uses PIDFile, which is unnecessary. It should be telling automount to remain in the foreground (and change Type=forking to Type=simple).

2. When asked to shut down, automount receives a signal to exit. Then this part of the manpage kicks in:

       If any autofs mount point directories are busy when the daemon is  sent
       an  exit  signal  the daemon will not exit. The exception to this is if
       autofs has been built with configure  options  to  either  ignore  busy
       mounts  at  exit  or force umount at exit. If the ignore busy mounts at
       exit option is used the filesystems will be left in a  catatonic  (non-
       functional) state and can be manually umounted when they become unused.
       If the force umount at exit option is  used  the  filesystems  will  be
       umounted  but  the  mount will not be released by the kernel until they
       are no longer in use by the processes that held them  busy.   If  auto-
       mount managed filesystems are found mounted when autofs is started they
       will be recoverd unless they are no longer present in the map in  which
       case they need to umounted manually.

Do we know how automount was compiled?
Comment 4 Jon Nelson 2013-04-23 16:10:13 UTC
I do have this:

autofs.service - Automounts filesystems on demand
          Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled)
          Active: inactive (dead) since Mon, 2013-04-22 21:14:21 CDT; 13h ago
        Main PID: 11695 (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/autofs.service

Apr 22 14:08:45 linux-3y3i.site systemd[1]: Started Automounts filesystems on demand.
Apr 22 21:14:21 worklaptop systemd[1]: Stopping Automounts filesystems on demand...
Apr 22 21:14:21 worklaptop systemd[1]: Stopped Automounts filesystems on demand.

and from pm-utils:

...
/usr/lib/pm-utils/sleep.d/02rtcwake suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/06autofs suspend suspend:
autofs.service - Automounts filesystems on demand
          Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled)
          Active: active (running) since Mon, 2013-04-22 14:08:45 CDT; 7h ago
        Main PID: 11695 (automount)
          CGroup: name=systemd:/system/autofs.service
                  └ 11695 /usr/sbin/automount -p /var/run/automount.pid

Apr 22 14:08:45 linux-3y3i.site systemd[1]: Started Automounts filesystems on demand.
...
/usr/lib/pm-utils/sleep.d/30s2disk-check resume suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/06autofs resume suspend:

/usr/lib/pm-utils/sleep.d/06autofs resume suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/02rtcwake resume suspend:

/usr/lib/pm-utils/sleep.d/02rtcwake resume suspend: success.
...
Comment 5 Jan Ritzerfeld 2013-04-27 13:56:37 UTC
I have this problem since the update to pm-utils-1.4.1-26.5.1.
Since then, NetworkManager is not notified anymore that the laptops suspends or resumes. These are the last entries I got (I updated on 2013-04-22):
2013-04-21T21:51:31.027227+02:00 karl NetworkManager[720]: <info> wake requested (sleeping: yes  enabled: yes)
2013-04-21T21:51:31.027477+02:00 karl NetworkManager[720]: <info> waking up and re-enabling...
Without these notifications, the NetworkManager Dispatcher will not execute /etc/NetworkManager/dispatcher.d/autofs after resume and, thus, autofs is not restarted. This is not a problem for autofs without the pm-utils because then it will not be stopped on resume.

NetworkManager not being notified is Bug 816992. Until this is fixed, downgrading to pm-utils 1.4.1-26.2.1 should help while deinstalling pm-utils should not.
Comment 6 Jan Ritzerfeld 2013-04-27 14:08:37 UTC
Clarification: With "[...]while deinstalling pm-utils should not." I wanted to say that keeping the current pm-utils or deinstalling it instead of downgrading should not help since it causes other problems. For me, something like Bug 805321 and Bug 807111.
Comment 7 Leonardo Chiquitto 2013-04-27 14:27:14 UTC
Jan, thanks a lot for the information! I'm closing this a a duplicate.

*** This bug has been marked as a duplicate of bug 816992 ***