jabberd does not close its stdin/stdout/stderr

[Bernie Innocenti]

This bug was initially reported in Fedora:
 https://bugzilla.redhat.com/show_bug.cgi?id=492378

We've recently come across a problem with jabberd. When we start its
init.d/jabberd from a script which reads its stdout, the last read never
finishes (until the jabberd is killed). All the jabberd daemons should probably
close its stdouts/stderrs.

Version-Release number of selected component (if applicable):

# rpm -q jabberd
jabberd-2.2.4-1.fc10.i386

How reproducible:

Deterministic.

Steps to Reproduce:
1. service jabberd stop; perl -e 'open F,"service jabberd start|"; my @out=<F>;
close F; print @out;'

Actual results:

The perl process never finishes, until you run service jabberd stop in another
terminal. The service process is in a zombie meanwhile because the parent
cannot reap it with waitpid because it's still blocked on that pipe read.

Expected results:

The perl process should finish just fine, with jabberd daemons running, just
like (let's say) httpd.

[Tomasz Sterna (smoku)]

jabberd uses stdout for debugging output.

[Jan P. (jpazdziora)]

Well, when running as a daemon, syslog or some log file should
probably be used, instead of stdout.

[Tomasz Sterna (smoku)]

It's true.
But jabberd2 does not support daemonizing natively.

So if you are using some kind of daemonisation wrapper, you should redirect stdin,stdout,stderr to ie. /dev/null.

If you want the native daemonisation option, you should fill a feature request.

[Tomasz Sterna (smoku)]

Not a jabberd issue.

[Bernie Innocenti (codewiz)]

Yes, it's an initscript issue, but the init script is part of the jabberd distribution.
This yet untested patch should fix the issue:

--- jabberd-2.2.5/tools/jabberd.rc.orig 2009-03-31 10:11:04.460273152 +0200
+++ jabberd-2.2.5/tools/jabberd.rc 2009-03-31 10:12:05.196309538 +0200
@@ -122,7 +122,7 @@ Start ( ) {
   rm -f /var/lock/subsys/${prog}
   rm -f ${pidPath}/${prog}.pid
   args="-c ${confPath}/${prog}.xml"
- ${progsPath}/${prog} ${args} & 2> /dev/null
+ ${progsPath}/${prog} ${args} & >/dev/null 2>&1
   retval=$?
   if [ ${retval} == 0 ]; then
    StatusOK

[Jan P. (jpazdziora)]

Wouldn't it have to be more like

- ${progsPath}/${prog} ${args} & 2> /dev/null
+ ${progsPath}/${prog} ${args} >/dev/null 2>&1 &

?

[Bernie Innocenti (codewiz)]

On 03/31/09 10:52, Jan P. wrote:
> Wouldn't it have to be more like
>
> - ${progsPath}/${prog} ${args} & 2> /dev/null
> + ${progsPath}/${prog} ${args} >/dev/null 2>&1 &
>
> ?

Ouch, yes.

--
   // Bernie Innocenti - http://www.codewiz.org/
 \X/ Sugar Labs - http://www.sugarlabs.org/

[Tomasz Sterna (smoku)]

Oh right.
I never use the init-perl-wrapper-thingy, so I completely forgot that it is included in the distribution. :-)

(The placement of the redirections does not really matter. Shell interprets them first.)

[Tomasz Sterna (smoku)]

Fixed in r758.

[Jan P. (jpazdziora)]

The fix in r758 is not correct -- the position of & does matter.

Please see the test plan in the original report.

[Tomasz Sterna (smoku)]

Simple test assured me that you're right. :-)

$ ./test.bash
#!/bin/bash
<$0 cat

$ ./test.bash >/dev/null

$ ./test.bash >/dev/null &
[1] 4854

$ ./test.bash & >/dev/null
[2] 4864
$ #!/bin/bash
<$0 cat

[Tomasz Sterna (smoku)]

Fixed in r761.

[Tomasz Sterna (smoku)]

jabberd 2,2.8 released