Baselayout-1.12.0_pre5 (and probably other 1.12.* versions as well) contains a wrapper around start- stop-daemon, which makes the jabberd init script failing to start. The reason is that the init script tries to start a bash/perl script (/usr/bin/jabberd) and not a proper daemon. A workaround is to pass the -- oknodo argument to start-stop-daemon (I haven't actually tested this). I don't know, however, what a proper fix would be. The bug is similar to the one described in bug 98745.
The jabberd perl script doesn't work on my system - it's supposed to monitor daemons and start/stop them as required. Basically it launches the daemons and them bombs out before becoming one. You can see this behaviour just be running jabberd from the commandline. It's supposed to launch and sit there, but instead it fails with a broken pipe and drops out. I would say that the issue is with jabberd rather than baselayout as we are correctly "failing" as jabberd did not become a daemon.
(In reply to comment #1) > You can see this behaviour just be running jabberd from the commandline. It's > supposed to launch and sit there, but instead it fails with a broken pipe and > drops out. You're correct that jabberd fails to start out of the box. I've filed a bug on this in bug 93441. Jabberd should be able to start if you do: # mkdir /var/lib/jabberd{,/{db,log,pid}} # for i in router resolver sm c2s s2s; do > for j in log pid; do > touch /var/lib/jabberd/${j}/${i}.${j} > fowners jabber:jabber /var/lib/jabberd/${j}/${i}.${j} > done > done > I would say that the issue is with jabberd rather than baselayout as we are > correctly "failing" as jabberd did not become a daemon. I've been running jabberd-2.0.x for some time, and the init script broke when I upgraded to baselayout-1.12.0_pre5 - furthermore, downgrading to baselayout-1.11.13 fixed the problem. I do, however, agree that the issue is with jabberd and not baselayout, since according to the comments in the top of /sbin/rc-daemon.sh (of baselayout-1.12.0_pre5) start-stop-daemon should not be used to start shell scripts (which /usr/bin/jabberd is). As far as I can tell, the issue is that the is_daemon_running() function in /sbin/rc-daemon.sh (still baselayout-1.12.0_pre5) tries to determine if the /usr/bin/jabberd process is running. Since /usr/bin/ jabberd is a shell/perl script, no process by that name exists - it is instead perl -w -x /usr/bin/jabberd - and hence the check fails.
I have contacted the j2 developers, I'm going to solve this together with them.
can you please try /usr/portage/net-im/jabberd/files/jabber.init.gentoo as a replacement for /etc/init.d/jabber? See http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/net-im/jabberd/files/jabber.init.gentoo?rev=1.1 for a web-viewable copy.
(In reply to comment #4) > can you please try /usr/portage/net-im/jabberd/files/jabber.init.gentoo > as a replacement for /etc/init.d/jabber? The jabber.init.gentoo script sort of works (tested with baselayout 1.11.13 and 1.12.0_pre6). It is in fact able to start all the components, it is, however, unable to stop the sm and c2s components: # /etc/init.d/jabber start * Starting Jabber Server ... * -> Starting router ... [ ok ] * -> Starting resolver ... [ ok ] * -> Starting sm ... [ ok ] * -> Starting c2s ... [ ok ] * -> Starting s2s ... [ ok ] # /etc/init.d/jabber stop * Stopping Jabber Server ... * -> Stopping router ... [ ok ] * -> Stopping resolver ... [ ok ] * -> Stopping sm ... [ ok ] * -> Stopping c2s ... [ ok ] * -> Stopping s2s ... [ ok ] Note that no errors are detected when stopping the components. A process list does, however, reveal that the sm and c2s components are running: # ps aux | grep jabber jabber 23915 0.0 0.3 4816 1508 ? Ss 00:52 0:00 /usr/bin/sm jabber 23917 0.0 0.2 4772 1416 ? Ss 00:52 0:00 /usr/bin/c2s root 23958 0.0 0.1 4752 644 pts/0 R+ 00:53 0:00 grep jabber If I try to start the script again (without killing sm and c2s) it will fail: # /etc/init.d/jabber start * Starting Jabber Server ... * -> Starting router ... [ ok ] * -> Starting resolver ... [ ok ] * -> Starting sm ... [ !! ] * -> Starting c2s ... [ !! ] * -> Starting s2s ... [ ok ] * * The following components failed to start: * -> sm c2s * * Trying to stop started components * -> Stopping router ... [ ok ] * -> Stopping resolver ... [ ok ] * -> Stopping s2s ... [ !! ] When killing the components manually, I'm able to kill router, resolver, and s2s with a TERM signal - whereas sm and c2s requires a KILL signal. I think this might be the reason why stopping the script fails.
I just discovered that the normal init script also fails to stop the sm and c2s components (using baselayout 1.11.13): # /etc/init.d/jabber start * Starting Jabber Server ... [ ok ] # /etc/init.d/jabber stop * Stopping Jabber Server ... [ ok ] # ps aux | grep jabber jabber 26265 0.0 0.3 4816 1508 ? S 01:18 0:00 /usr/bin/sm -c /etc/jabberd/sm.xml jabber 26267 0.0 0.2 4768 1420 ? S 01:18 0:00 /usr/bin/c2s -c /etc/jabberd/c2s.xml root 26316 0.0 0.1 4756 644 pts/0 R+ 01:20 0:00 grep jabber The difference is, that this script is able to start if the sm c2s components are running - you will, hoever, get an extra set of sm and c2s processes each time you restart the script.
I like that script a lot - however, like the above reporter I cannot get c2s to start :/ I suspect now that the real problem is in the way jabberd has been built as the c2s program just quits without any error and without any log. Although this may because I haven't touched any jabber config files.
well, the gentoo init script works for me, BUT I can confirm some processes (resolver in my case) don't exit immediately, as start-stop-daemon seems to believe, but take some more seconds to close. so, what I would want is a reliable way of _knowing_ a j2 process has really stopped. well, here's a fix that actually works for me [tm]: http://dev.gentoo.org/~wschlich/src/jabber.init.gentoo I added -x [...] and -R [...] to the start-stop-daemon for stopping the components -- that should be reliable. what's currently ugly is that the component processes don't background themselves at startup, so start-stop-daemon has to take care of that, making it impossible to know whether a component startup actually succeeded (see the manpage of start-stop-daemon regarding --background). whaddaya think guys?
Created attachment 66736 [details] jabber init script baselayout-1.12.0_pre6 takes care of those start-stop-daemon issues you mentioned. Checkout /lib/rscripts/sh/rc-daemon.sh - it's a wrapper for start-stop-daemon to try and make it behave nicely. Basically when you call start-stop-daemon as you are doing, it never actually calls it for --stop and just uses the bash code instead, which has proven much more reliable :) I've taken your original script and made it a touch cleaner. It *should* work with any baselayout version, but as I said, I cannot get c2s to start at all, even by hand
(In reply to comment #7) > I like that script a lot - however, like the above reporter I cannot get c2s to > start :/ Are you sure an c2s process isn't already running? If I have an c2s process that didn't exit, I'm unable to start a new c2s process - the new process will just exit silently, just as you describe. To kill the c2s and sm processes I do: # killall -9 c2s sm > I suspect now that the real problem is in the way jabberd has been built as the > c2s program just quits without any error and without any log. Although this may > because I haven't touched any jabber config files. I only did very minimal changes to the configuration files. I've changed the JID and the password/secret for the server - and I changed the database module from mysql to db. If I use the default mysql module both c2s and sm will fail to start, they do, however, give an error message in the syslog. So you might want to change at least c2s/authreg/module in c2s.xml and sm/storage/driver in sm.xml to db.
I've just tested your scripts, and they both work with baselayout-1.12.0_pre6-r2. With baselayout-1.11.13-r1 Wolfram's script fails to stop any component and Roy's script fails to stop sm and c2s. As far as I can tell, 1.12.0_pre6-r2 works because start-stop-daemon --stop is handled by rc-daemon.sh - as Roy mentioned. By adding some debug to rc-daemon.sh, I found out, that it won't kill sm and c2s until it starts sending KILL signals. So this confirms comment #5. The drawback with this approach is that the script will fail to stop sm and c2s if you disable RC_RETRY_KILL in /etc/conf.d/rc. I don't know if this can be accepted as a known bug? I think a proper fix would be to find out why sm and c2s aren't exiting on a TERM signal, and if possible make them able to do so. However, I still think the new init script should be used. We just need to figure out the issue, that this script doesn't work with baselayout-1.11* - perhaps baselayout-1.12* in RDEPEND could be a solution (jabberd-2* is ~arch after all)?
(In reply to comment #8) > well, the gentoo init script works for me, BUT I can confirm some processes > (resolver in my case) don't exit immediately, as start-stop-daemon seems > to believe, but take some more seconds to close. Do your sm and c2s processes actually exit? I tested this on my system today. After stopping the gentoo init script, the sm and c2s processes were still running 6 hours later.
Created attachment 66809 [details] jabber init script Minor cosmetic changes to the init script. If the script fails to stop it will display this message: * Please kill the processes manually and reset * this service to a stopped state using * -> /sbin/runscript.sh zap I think /sbin/runscript.sh should be /etc/init.d/jabber - I don't know how to fix this, other than replacing ${0} with /etc/init.d/jabber.
I looked into the issue that sm and c2s didn't exit on a TERM signal. It turned out the processes were hanging trying to open the Berkeley DB in /var/lib/jabberd/db/ (or /var/jabberd/db/ depending on your setup). Since I don't use the sm and c2s I hadn't discovered this before. Deleting the content of /var/lib/ jabberd/db/ solved the issue, so both sm and c2s will exit on a TERM signal. This means that the attached init script now works with both baselayout 1.11* and 1.12* (with both RC_RETRY_KILL="yes" and RC_RETRY_KILL="no").
Created attachment 66917 [details] jabber init script I've made the init script stop the components in the reverse order (like /usr/bin/jabberd does). This prevents the components from complaining in the syslog that they lost their connection to the router just before they are shut down. Furthermore, I've cleaned up the script a bit more.
great! BUT ;) I'd prefer to have the tac dependancy removed. so, why not use something like: --8<-- components_start="router resolver sm c2s s2s" components_stop="s2s c2s sm resolver router" --8<-- it's redundant but eliminates the dependancy on tac.
Created attachment 66924 [details] jabber init script I agree that a dependency on tac isn't that nice after all. :-) I just checked my Gentoo OSX and it doesn't have tac as default. I removed tac from the script, however, I just wrote the components directly in the for-loops - I think this is cleaner than having two variables that are only used once. Feel free to change that if you don't agree.
Whole init.d script will be re-worked. *** This bug has been marked as a duplicate of 143955 ***
