From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 Description of problem: Running "service autofs start" multiple times starts the automount daemon multiple times instead of exiting with a "[FAILED]" error. Version-Release number of selected component (if applicable): 3.1.7-21 How reproducible: Always Steps to Reproduce: 1. service autofs start [ OK ] 2. service autofs start [ OK ] 3. service autofs start [ OK ] 4. service autofs status ; pidof /usr/sbin/automount See list of "Active Mount Points" and find three automount processes. Actual Results: Multiple /usr/sbin/automount processes. Expected Results: Running "service autofs start" more than once should have given a "[FAILED]" error. Additional info: Might be related to bug #55715.
pidof /usr/sbin/automount doesn't return any pids... do you have to have mounts defined for automount to duplicate?
On Skipjack-beta2 with only /misc/cd enabled in /etc/auto.misc: # service autofs start Starting automount: [ OK ] # service autofs start Starting automount: [ OK ] # service autofs start Starting automount: [ OK ] # service autofs start Starting automount: [ OK ] # service autofs status Configured Mount Points: ------------------------ /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc Active Mount Points: -------------------- /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc # ps auxw | grep auto root 637 0.0 0.2 1472 584 ? S 11:19 0:00 /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc root 1886 0.0 0.2 1472 584 pts/2 S 13:30 0:00 /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc root 1949 0.0 0.2 1472 584 pts/2 S 13:30 0:00 /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc root 2012 0.0 0.2 1472 584 pts/2 S 13:30 0:00 /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc root 2075 0.0 0.2 1472 584 pts/2 S 13:30 0:00 /usr/sbin/automount --timeout 60 /misc file /etc/auto.misc # pidof /usr/sbin/automount 2075 2012 1949 1886 637
So, is this an issue on Red Hat Linux 7.2 or on the SkipJack beta2 ?
It is reproducible on both Enigma and Skipjack. Two different machines.
Reproducible on Valhalla. # service autofs start Starting automount: [ OK ] # service autofs start Starting automount: [ OK ] # service autofs start Starting automount: [ OK ] # service autofs start Starting automount: [ OK ] # pidof automount 12627 12600 12575 12512 12485 12458 12393 12366 12341 12278 12251 12224 # cat /proc/mounts | grep ^auto automount(pid12224) /misc autofs rw 0 0 automount(pid12251) /home/ms/public_html/ct/mnt autofs rw 0 0 automount(pid12278) /home/ms/public_html/mount autofs rw 0 0 automount(pid12366) /home/ms/public_html/ct/mnt autofs rw 0 0 automount(pid12393) /home/ms/public_html/mount autofs rw 0 0 automount(pid12341) /misc autofs rw 0 0 automount(pid12458) /misc autofs rw 0 0 automount(pid12485) /home/ms/public_html/ct/mnt autofs rw 0 0 automount(pid12512) /home/ms/public_html/mount autofs rw 0 0 automount(pid12600) /home/ms/public_html/ct/mnt autofs rw 0 0 automount(pid12627) /home/ms/public_html/mount autofs rw 0 0 automount(pid12575) /misc autofs rw 0 0
Original report was for Red Hat Linux 7.2 (Enigma). Reproducible on Psyche 8.0.93.
Typo. Meant Phoebe (8.0.93).
Reproducible on Advanced Server 2.1. A partial workaround appears to be the following sequence: service autofs stop killall -9 automount service autofs start And then everything appears to work again, despite /proc/mounts and /etc/mtab being corrupted with multiple entries. However, before applying the workaround, if anything tries to access an automount, I get a load of processes in uninterruptible sleep (D) which can render the machine fairly useless. So please consider raising the severity. (This should be easy to fix anyway, right?)
Please see my attachment to bug 65003 which will hopefully fix both bugs.
*** This bug has been marked as a duplicate of 65003 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.