Red Hat Bugzilla – Bug 110160
vsftpd Service Start Causes Services Applet to Hang in X
Last modified: 2008-08-02 19:40:33 EDT
Description of problem: When using the services applet in KDE under Server Settings to start vsftpd, the service applet will hang and does not appear to start the sevice. However, logging in to the FTP server from another workstation indicates that the service is up and running. The vsftpd service will start from the command line properly. Even exiting and restarting KDE, the service applet will show vsftpd as not running when it actually is. Version-Release number of selected component (if applicable): How reproducible: Open X and try to start the service Steps to Reproduce: 1. Open either KDE or Gnome 2. Open System Settings and then Server Settings and Services 3. Locate vsftpd service 4. Check the option to start service on boot 5. Click the Start button to start service Actual results: Services applet hangs Expected results: Expect service to start as others did and have the ability to close the services applet Additional info: This happens every time in either KDE or Gnome and the services applet cannot be closed either.
*** Bug 113116 has been marked as a duplicate of this bug. ***
Looks like the popen call is freezing. IE the pipe.read never returns. I am going to pass this on to python. Test program causes it to happen on Fedora core test 2 def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os text="" pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') try: text = pipe.read() except IOError,v: text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text print getstatusoutput("/sbin/service vsftpd start < /dev/null") print getstatusoutput("/sbin/service vsftpd stop < /dev/null") print getstatusoutput("/sbin/service vsftpd start < /dev/null")
Weird. Looks like if I do: service vsftpd stop (from the command line) then run the above script with just the first getstatusoutput(), it blocks (running it from strace shows that the read is interrupted by a SIGCHLD from the process that finished running, and then is resumed, but never completes. If the service is already started, it doesn't block. This is *weird*.
Fedora Core 1 is maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thanks! NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy project. After Fedora Core 6 Test 2 is released (currently scheduled for July 26th), there will be no more security updates for FC1. Please use these next two weeks to upgrade any remaining FC1 systems to a current release.
Closing per lack of response. Also note that FC1 and FC2 are no longer supported even by Fedora Legacy. If this still occurs on FC3 or FC4, please assign to that version and Fedora Legacy. If it still occurs on FC5 or FC6, please reopen and assign to the correct version.