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.

Just run it and check the return code?

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?

I still think just catching the scripts return code is simpler.

It shouldn't be using popen(); it should just fork/exec/wait.

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.

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.

"LC_ALL=C /sbin/service " should take care of that shouldn't it?

Yes, that should work.

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.

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

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

system-config-services is still hanging on trying to start or restart vsftpd 
with version 0.8.25-1 in FC4.

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.

Ping?

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.

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?

closing due to lack of response