Bug 120579 - system-config-services hangs when starting vsftpd
system-config-services hangs when starting vsftpd
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: system-config-services (Show other bugs)
rawhide
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Nils Philippsen
:
: 145676 147894 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-11 02:59 EDT by Hervé Pagès
Modified: 2008-08-02 19:40 EDT (History)
6 users (show)

See Also:
Fixed In Version: fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-25 08:02:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hervé Pagès 2004-04-11 02:59:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
When I select "vsftpd" and press the "Start" button in
system-config-services, then the system-config-services
window will not respond anymore.
Anyway, vsftpd will be started:
  # /etc/init.d/vsftpd status
  vsftpd (pid 3234) is running...
Stoping vsftpd with system-config-services doesn't cause
any problem.

NB: This problem was already present in Fedora Core 1 (i686).


Version-Release number of selected component (if applicable):
system-config-services-0.8.8-7

How reproducible:
Always

Steps to Reproduce:
1. Start->System Setting->Server Settings->Services
2. Select "vsftpd" in left frame
3. Click on "Start" button
    

Actual Results:  system-config-services hangs

Expected Results:  should not hang

Additional info:
Comment 1 Brent Fox 2004-06-16 16:07:57 EDT
I'm guessing that there is there is due to the interaction of
system-config-services and the vsftpd initscript.  

system-config-services opens a pipe to the initscript with the
following code:

pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
try:
    text = pipe.read()

The vsftpd is using an "&" to put the vsftpd daemon process in the
background, which is causing the read() from Python to hang forever.

Comment 3 Bill Nottingham 2004-06-28 17:07:34 EDT
Just run it and check the return code?
Comment 4 Nils Philippsen 2004-08-06 04:25:57 EDT
As a workaround for other such initscripts (we can't be sure that all
initscripts will behave in a sane manner, e.g. not use & to start
daemon processes), we could do something like this: Echo a "marker"
(random token) after the script has run and close the pipe when we
receive that marker. E.g.:

import random
import string
[...]
all_chars = string.ascii_letters + string.ascii_lowercase + string.digits

def random_token (size = 20):
    token = ''
    for i in range (0, size):
        token += random.choice (all_chars)
    return token
[...]
token = random_token ()
pipe = os.popen ('{ %s; } 2>&1; echo %s' % (cmd, token), 'r')
try:
    text = ''
    while True:
        line = pipe.readline ()
        if line.rstrip () == token:
            break
        text += line
[...]

What do you think?
Comment 5 Bill Nottingham 2004-08-06 10:35:58 EDT
I still think just catching the scripts return code is simpler.

It shouldn't be using popen(); it should just fork/exec/wait.
Comment 6 Nils Philippsen 2004-08-13 12:05:18 EDT
The problem is that you can't quite rely on that even
chkconfig-enabled scripts support status so catching the output and
grepping for "stopped" and "started" in addition to the exit value is
safer than just checkint the exit value.

Example: /etc/init.d/aep1000 from hwcrypto doesn't support status,
when called with "status" exits 0, but still spits out a Usage message
(bug #81599). The current scheme catches this error, only checking the
exit value would not.
Comment 7 Brent Fox 2004-08-13 12:24:32 EDT
Nils, you need to consider translations when grepping for output.  I
have a test system set up to use Simplified Chinese for the locale. 
'service sshd status' returns me 'sshd (pid1590) and then a bunch of
Chinese chars'.  I don't know if grepping for English strings is going
to help.
Comment 8 Nils Philippsen 2004-08-13 12:59:01 EDT
"LC_ALL=C /sbin/service " should take care of that shouldn't it?
Comment 9 Brent Fox 2004-08-13 13:14:30 EDT
Yes, that should work.
Comment 10 Nils Philippsen 2004-10-11 11:22:43 EDT
The "low level problem" should be fixed in
system-config-services-0.8.12-1, i.e. the UI doesn't hang anymore and
lets you select other services than those that do hang at
"/etc/init.d/... status", But as soon as the hanging one returns, it
selects its entry. I'm thinking about how to make this interruptible
so that when selecting another entry, the running status update gets
cancelled.
Comment 11 Andy Shevchenko 2005-01-20 11:32:33 EST
*** Bug 145676 has been marked as a duplicate of this bug. ***
Comment 12 Nils Philippsen 2005-02-16 08:14:13 EST
*** Bug 147894 has been marked as a duplicate of this bug. ***
Comment 13 John William 2005-06-17 18:28:29 EDT
system-config-services is still hanging on trying to start or restart vsftpd 
with version 0.8.25-1 in FC4.
Comment 14 Nils Philippsen 2006-05-10 07:13:13 EDT
I cannot see this behaviour with system-config-services-0.9.0 which is just
building for FC4 Testing. Please verify whether this problem persists once the
new version hits the mirrors.
Comment 15 Nils Philippsen 2006-06-07 08:55:22 EDT
Ping?
Comment 16 ryoung75 2006-06-16 09:29:42 EDT
system-config-services continues hanging on trying to start or restart vsftpd 
with a recent install of FC5. After initial install it worked fine. It may have 
been coincidental but the problem seemed to come about after disabling SeLinux 
and re-enabling it later on.
Comment 17 Peter van Egdom 2006-10-31 16:28:07 EST
I can't reproduce this problem with "system-config-services-0.9.1-1.fc6" on
Fedora Core release 6 (Zod). I tried stopping, starting and restarting vsftpd
with SELinux in both 'enforcing' and 'permissive' mode. In both situations
system-config-services did not hang (as it did with previous versions). Do you
still see this problem in Fedora Core release 6?
Comment 18 Nils Philippsen 2007-01-25 08:02:43 EST
closing due to lack of response

Note You need to log in before you can comment on or make changes to this bug.