Using jabberd-2.0.11, after a recent round of updating (not sure exactly what got updated), my Jabber init script fails to start. I can't find a single error -- as far as I can tell from the syslog, the entire jabberd system started, then stopped, entirely normally, when I just wanted it to start. I tried running "jabberd" from the commandline -- worked. Tried copying/pasting the command out of the init script -- worked.
Created attachment 94285 [details, diff] Weird patch So tell me -- why does this patch work?
I just experienced this same bug, and David's patch works for me. Strangely, when I first installed jabberd2 it started fine, but I changed the configuration to LDAP authentication (from MySQL) and then I got the bug. Changing back to MySQL auth unfortunately didn't remove the bug though. Attaching emerge --info.
Created attachment 94400 [details] emerge --info
(In reply to comment #2) > I just experienced this same bug, and David's patch works for me. If you didn't notice from reading the patch: This patch should not work, and it's a truly ugly hack, mostly because so far no one knows why it works. I'm using that patch because I want a working jabberd, but it probably shouldn't go into the tree until someone either fixes the real bug or comes up with a good reason why it works the way it does. I don't see how emerge info will help here, but I should probably do that anyway...
Created attachment 94405 [details] emerge --info
Agree with your comments David, it's not suitable for inclusion in the tree, but like you I need a working jabberd. Besides, it wouldn't be the Gentoo bugzilla without at least one "me too". :D And yes, emerge --info is probably no help for this bug. Bug 102546 discusses a similar problem with an earlier jabberd init script. The problem seems to stem from the subject of the start_stop_daemon call in the init script being a script itself. Perhaps the real solution is to rewrite the init script so that the called script is inline and therefore no longer required...
*** Bug 146320 has been marked as a duplicate of this bug. ***
I create a new patch. This one is foк /usr/bin/jabber
Created attachment 96053 [details, diff] new patch
Ok... That looks like the Right Thing, but does make my patch unnecessary? And do we have any clue why it works?
Yes, it does. I think, that this work, because /bin/sh is not very good for perl invocation (it's my opinion). And your patch start perl with bash, and my patch start perl itself. It's right way to write perl scripts
This bug bit me too, and the patch given in comment #9 resolved the issue.
*** Bug 149393 has been marked as a duplicate of this bug. ***
I had the same situation as comment #12 i'm using sys-apps/baselayout-1.12.5-r1
Had this problem, too. The "new patch" worked fine.
*** Bug 102546 has been marked as a duplicate of this bug. ***
*** Bug 150248 has been marked as a duplicate of this bug. ***
*** Bug 67457 has been marked as a duplicate of this bug. ***
nelchael, this is a baselayout change, sys-apps/baselayout-1.12.5-r2 will not start the servers, the change will not be reverted, so this one need to be fixed.
With patch 9 my jabberd did not work, in contrary, it does now even now start from the command line anymore. Definitly not a solution ;=;
After update i cannot run /etc/init.d/jabberd, too. My patch doesn't work. Strange.
"Weird patch" doesn't work, too. The only solution is start jabberd by hand, i.e. /usr/bin/jabberd
Please re-emerge jabberd-2.0.11-r1 - it has brand new init.d script that uses /etc/jabber/jabberd.cfg to control which modules should be started.
(In reply to comment #23) > Please re-emerge jabberd-2.0.11-r1 - it has brand new init.d script that uses > /etc/jabber/jabberd.cfg to control which modules should be started. Works. Thanks.
When I use virtual hosting and I have two session manager in the jabberd.cfg, the init-script can't start both sm's.
