Bug 110160

Summary:	vsftpd Service Start Causes Services Applet to Hang in X
Product:	[Fedora] Fedora	Reporter:	Gerry O'Brien <gobrien8199>
Component:	python	Assignee:	Mihai Ibanescu <mihai.ibanescu>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1	CC:	ctoth, mattdm
Target Milestone:	---
Target Release:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-10-25 20:54:52 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 Gerry O'Brien 2003-11-15 15:59:46 UTC

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.

Comment 1 Bill Nottingham 2004-02-05 01:20:25 UTC

*** Bug 113116 has been marked as a duplicate of this bug. ***

Comment 2 Daniel Walsh 2004-03-25 16:02:03 UTC

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")

Comment 3 Mihai Ibanescu 2004-04-16 21:02:21 UTC

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*.

Comment 4 Matthew Miller 2006-07-11 17:41:46 UTC

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.

Comment 5 John Thacker 2006-10-25 20:54:52 UTC

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.