+++ This bug was initially created as a clone of Bug #540781 +++ Description of problem: Watch this: # ps uwwaxf | grep [a]uto root 1845 0.0 0.2 307652 1396 ? Ssl 21:13 0:00 automount # service autofs stop Stopping automount: [ OK ] # service autofs status automount (pid 1845) is running... # ps uwwaxf | grep [a]uto root 1845 0.0 0.2 307652 1396 ? Ssl 21:13 0:00 automount So it reports that it was stopped but does nothing of that sort. Here is the problem: # sh -x /etc/init.d/autofs stop ..... Stopping automount: + count=0 ++ pidof /usr/sbin/automount + '[' -n '' -a 0 -lt 15 ']' + '[' 0 -eq 0 ']' + rm -f /var/lock/subsys/autofs ++ pidof /usr/sbin/automount + '[' -n '' ']' + success 'automount shutdown' .... while 'pidof automount' responds with 1845. So replacing in that script `pidof $DAEMON` with `pidof $prog` solves this "gotcha" especially that the later reports a correct pid even if /usr/sbin/automount shows up in a process table. Version-Release number of selected component (if applicable): autofs-5.0.5-8.fc13 (but actually in other Fedora version this script behaves in the same manner). How reproducible: always when autofs service was started in a boot sequence Additional info: Curiously enough once this service was really stopped then subsequent attempts to stop or restart work like expected, i.e. 'pidof $DAEMON' returns a process id. Only the first time after a boot there is an issue. I do not know why. --- Additional comment from ikent on 2009-11-24 01:35:12 EDT --- (In reply to comment #0) > > while 'pidof automount' responds with 1845. So replacing in that script > `pidof $DAEMON` with `pidof $prog` solves this "gotcha" especially that the > later reports a correct pid even if /usr/sbin/automount shows up in a process > table. Yes, I've been meaning to look at this for ages. > > Version-Release number of selected component (if applicable): > autofs-5.0.5-8.fc13 > (but actually in other Fedora version this script behaves in the same manner). That's right. > > How reproducible: > always when autofs service was started in a boot sequence Not sure about that, I thought it was only evident when the package had been updated but perhaps pidof is even more broken now than previously. Ian --- Additional comment from ikent on 2009-11-24 02:27:26 EDT --- The change you recommended appears to work OK. Could you give the package at: http://kojipkgs.fedoraproject.org/packages/autofs/5.0.5/10.fc13 a try please. --- Additional comment from michal on 2009-11-24 19:37:55 EDT --- autofs-5.0.5-10.fc13 does work here AFAICS. Right after a reboot: # service autofs status automount (pid 1842) is running... # service autofs restart Stopping automount: [ OK ] Starting automount: [ OK ] # service autofs status automount (pid 2173) is running... If "OK" is not jumping on you immediately after "Stopping automount:" then it means that the script is fine. :-) Thanks! --- Additional comment from ikent on 2009-11-24 20:27:34 EDT --- OK, looks good and, at the very least it's an improvement. I'll apply it to our other releases as well. --- Additional comment from updates on 2009-11-24 20:51:15 EDT --- autofs-5.0.4-47 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/autofs-5.0.4-47 --- Additional comment from updates on 2009-11-24 21:11:54 EDT --- autofs-5.0.3-45 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/autofs-5.0.3-45
I had observed this problem myself prior to the bug being logged and I was able to reliably reproduce the problem. The init script change does resolve the issue but I think my "how to test" instructions are not quite right. The problem occurs when upgrading the autofs package while autofs is still running, typically to a later version. But using the same package revision causing an identical binary to be installed must be causing the problem to not occur. I will test this.
(In reply to comment #6) > I had observed this problem myself prior to the bug being > logged and I was able to reliably reproduce the problem. > The init script change does resolve the issue but I think > my "how to test" instructions are not quite right. The > problem occurs when upgrading the autofs package while > autofs is still running, typically to a later version. But > using the same package revision causing an identical binary > to be installed must be causing the problem to not occur. > > I will test this. It seems I didn't test this correctly. I can't reproduce this on RHEL-5 either.
(In reply to comment #7) > > It seems I didn't test this correctly. > I can't reproduce this on RHEL-5 either. IIRC the problem was showing up only in a limited set of circumstances, I do not know really why, and it was not so obvious to reproduce. In particular (again IIRC) if autofs was already once killed and restarted then subsequent restarts worked fine. I chalked that up to some weirdness in a user space support but I was not sure where to look deeper.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0265.html