Bug 89589
Summary: | smbmount not returning after mount | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Paul Rensing <prensing> |
Component: | samba | Assignee: | Jay Fenlason <fenlason> |
Status: | CLOSED CANTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | benm, ben, jfeeney, john, karl, mattdm, rhladik, service, twanger |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-01-02 18:32:10 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Paul Rensing
2003-04-24 17:55:16 UTC
Actually, I was wrong when I first described this problem, but it is still a bug. The problem is that smbmount hangs (but not always). I have watched it happen a few times. smbmount forks into two processes. The second process is detached from the pty and does the mount. It is meant to stay running as long as the SMB filesystem is mounted. This all seems to work. The problem appears to be that the original smbmount process hangs after spawning the "worker" process. I can fix it by "kill -9" the original process, but that is yuchy. BTW, this does not require automount. It does seem to have something to do with not requiring a password. I run the command like: mount -t smbfs //gigadrive2/public /mnt/tmp -o guest,fmask=0777,dmask=0777 Paul Rensing I filed Bug 97743 after running a search and not finding this bug. The problem is nearly identical, and matches the findings here. smbmount never locked up for me when used manually because I was using -o username=foo,password=bar. The automatic or fstab-aided mount attempts here use the "credentials" option pointing to files with usernames & passwords, and these exhibit the lockup very often. I can also confirm that smbmount locks up often when logging in as guest via ftsab entry. I have the same problem with three mounts from a Windows 2000 box: [root@fluor root]# ps aux | grep mount root 2354 0.0 0.6 4688 1532 ? S 11:08 0:00 /sbin/mount.smbfs //server2000/Entwicklung /mnt/entwicklung -o rw noexec nosuid nodev noauto user username m.bertheau gid 500 password XXXXXXXXX uid 1000 fmask 664 iocharset utf8 codepage cp850 root 2359 0.0 0.5 4688 1528 ? S 11:08 0:00 /sbin/mount.smbfs //server2000/Mitarbeiter /mnt/mitarbeiter -o rw noexec nosuid nodev noauto user username m.bertheau gid 500 password XXXXXXXXX uid 1000 fmask 664 iocharset utf8 codepage cp850 root 2361 0.0 0.2 3472 548 pts/0 S 11:08 0:00 mount infobrett/ root 2362 0.0 0.5 4684 1408 pts/0 S 11:08 0:00 /sbin/mount.smbfs //server2000/INFOBRETT /mnt/infobrett -o rw noexec nosuid nodev noauto user username m.bertheau gid 500 password XXXXXXXXX uid 1000 fmask 664 iocharset utf8 codepage cp850 root 2363 0.0 0.5 4684 1348 ? S 11:08 0:00 /sbin/mount.smbfs //server2000/INFOBRETT /mnt/infobrett -o rw noexec nosuid nodev noauto user username m.bertheau gid 500 password XXXXXXXXX uid 1000 fmask 664 iocharset utf8 codepage cp850 root 2476 0.0 0.2 3636 692 pts/1 S 11:09 0:00 grep mount [root@fluor root]# This is after mounting them manually on the commandline with fstab help. The first to succeeded, the third mount hangs. The filesystem is perfectly accessible though. I had previously a gentoo box at work, my colleague a RedHat 7.3 (or 7.2, don't know) box, both did not exhibit this behaviour. Now both run RedHat 9 and both exhibit the problem. I am experiencing the same behavior as above. It started only after install of Red Hat 9. Curiously, it returns fine when I su to do the mount, but hangs when I su - or run it out of root's cron. Me also. Only started with Redhat 9. Usually fstab entries hang, but very rarely a manual mount also hangs up. I straced and the mount parent was hung in wait4() and the forked child was (mount.smbfs) was also pause()ing ? Seems like a deadlock that is easy to trigger with fstab entries to me. This bit me too. I don't think it has anything to do with automount or fstab. Sometimes the choice of "su" versus "su -" seems to affect the frequency, but that is probably just superstitious behavior. I tried it with samba-2.2.7a-8.9.0 and with samba-3.0.0-5rc1 from rawhide. There was no difference. As a workaround I have been doing #!/bin/sh smbmount <whatever> & sleep 5 kill $! Has anyone found something better. Having the same problem after 'upgrading' to RH9. My samba scripts quit running - running by had I got: [root@malaysia mnt]# smbmount //singapore/backups $SINGMNT/backups/ $SMB INFO: Debug class all level = 2 (pid 9510 from pid 9510) added interface ip=192.168.1.200 bcast=192.168.1.255 nmask=255.255.255.0 at which point it hangs - but not always! Has anyone tried going back to samba-2.2.5-10? I also found this bug referenced at: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3f04587e%240%2443849%2439cecf19%40news.twtelecom.net&rnum=4&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D3f04587e%25240%252443849%252439cecf19%2540news.twtelecom.net%26rnum%3D4 Here is a slightly improved hack. Move /usr/bin/smbmount to /usr/bin/smbmount.orig. Then create the following script as /usr/bin/smbmount: ------------------------- #!/bin/sh /usr/bin/smbmount.orig $* & proc=$! for i in `seq 1 5`; do sleep 1 if mount | grep -q $1; then kill -9 $proc exit fi done kill -9 $proc ------------------------- This as a little lower lag time then simply waiting 5 seconds. As for the bug, I wonder if it has more to do with the new version of gcc and glibc (with threads) then with the actually samba code. I know I tried using the smbmount executable from RH8 (without recompiling), but it did not work. I am also seeing this bug on RH 9, but not RH 8. I was originally using smbmount 2.2.7a-security-rollup-fix but also tried smbmount 2.2.8a (from a samba RPM) and the same thing occurs. I tend to agree that this problem is probably more due to a new glibc & gcc rather than samba (or smbfs), as the randomness suggests a race-condition. I experience the problem using the "smbmount" command. I have added debugging statements and after the child process terminates, the parent executes a "pause" command, waiting for a SIGUSR1 signal from "smbfs". That signal never appears to arrive. BUG WORKAROUND! This appears to be a race condition problem. I do not know but I suspect killing the process may have other undesirable consequences (particular if the mount legitimately fails for example becuase the server is unavailable). I have a bug workaround for the source code that appears to eliminate a race condition. In the source code for smbmount, I added a "sleep(1);" just after the call to "sys_fork" in func "init_mount" (this is around line 478). This has (so far) eliminated the problem. I am using version 2.2.7a Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc. They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/) for security updates only. If this is a security issue, please reassign to the 'Fedora Legacy' product in bugzilla. Please note that Legacy security update support for these products will stop on December 31st, 2006. If this is not a security issue, please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. If you are currently still running Red Hat Linux 7.3 or 9, please note that Fedora Legacy security update support for these products will stop on December 31st, 2006. You are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a security issue, please change the product as necessary. We thank you for your help, and apologize again that we haven't handled these issues to this point. Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc. f you are currently still running Red Hat Linux 7.3 or 9, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Closing as CANTFIX. |