Re: process "router" doesn't want to be killed
Dnia 2011-03-25, pią o godzinie 14:52 +0100, Marcin Mirosław pisze: > > Maybe I should add upstart service description files to the default > > distribution to "hint" the preferred way of starting jabberd2 > > components? > This is good idea, it could be usefull. Committed in r933. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/ -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: process "router" doesn't want to be killed
W dniu 25.03.2011 14:18, Tomasz Sterna pisze: > Maybe I should add upstart service description files to the default > distribution to "hint" the preferred way of starting jabberd2 > components? Does jabberd.cfg.dist contain correct order of services? -- xmpp (jabber): marcin [at] mejor.pl www: http://blog.mejor.pl/ -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: process "router" doesn't want to be killed
Hi! On Friday 25 March 2011 16:18:07 Tomasz Sterna wrote: > Dnia 2011-03-25, pią o godzinie 13:50 +0100, Marcin Mirosław pisze: > Thus I personally do not maintain and fix the wrapper script, which is a > relic of the past for me. I suspect that :D Anyway, 'vanilla' jabberd2 has no reliable way to start/stop components for debugging/developing purposes. First time, I started each module on separate screened terminal to get separate debug log and so on. it became a nightmare after a while :) > > > Maybe I should add upstart service description files to the default > distribution to "hint" the preferred way of starting jabberd2 > components? > That would be great! Thanks! -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: process "router" doesn't want to be killed
W dniu 25.03.2011 14:18, Tomasz Sterna pisze: > Didn't all modern distribution already move to some supervisor based > init solution in place of unreliable RC scripts? Is Gentoo modern distribution?;) > Thus I personally do not maintain and fix the wrapper script, which is a > relic of the past for me. I'm concerned on script used by gentoo, it's completly diffrent than tools/jabberd.rc . > Maybe I should add upstart service description files to the default > distribution to "hint" the preferred way of starting jabberd2 > components? This is good idea, it could be usefull. Thanks! -- xmpp (jabber): marcin [at] mejor.pl www: http://blog.mejor.pl/ -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: process "router" doesn't want to be killed
Dnia 2011-03-25, pią o godzinie 13:50 +0100, Marcin Mirosław pisze: > > I've spent a while writing daemon-based replacement for legacy perl > 'jabberd' script > > It starts all configured modules at once and kills them together and > also it is suitable for init.d > > > > I'm going to publish a patch as soon as I clean up some debug, > private configuration and ugly hacks. > > I wonder if spliting "one-big-script-which-starts-all-services" init > script to individual could be better solution. I could do correct > dependency to get router killed after all other components. In > consecution _all_ jabber services must be killed to restart jabberd2 > (or router), for example, when i do upgrade. Hmm... Didn't all modern distribution already move to some supervisor based init solution in place of unreliable RC scripts? I moved to svscan based solution years ago and never looked back. Now I am happy user of upstart or systemd (depending on system). Thus I personally do not maintain and fix the wrapper script, which is a relic of the past for me. Maybe I should add upstart service description files to the default distribution to "hint" the preferred way of starting jabberd2 components? -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/ -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: process "router" doesn't want to be killed
W dniu 25.03.2011 10:28, Eugene Agafonov pisze: > Hi! > Just for information: > > Router exits if it gets SIGINT/SIGTERM and all other components are > disconnected. > So 'killall -2 router sm c2s s2s' closes the whole server correctly but it is > not suitable > if multiple servers are started and you need to kill just one of them. [...] > As soon as all other components are disconnected, the loop exits and router > is closed. It look like 'works as designed' but users are still unhappy ;-) I'm more happy if i know it isn't bug :) > I was trying to do some workarounds but it looks like an ugly hack so I > dropped it. > > I've spent a while writing daemon-based replacement for legacy perl 'jabberd' > script > It starts all configured modules at once and kills them together and also it > is suitable for init.d > > I'm going to publish a patch as soon as I clean up some debug, private > configuration and ugly hacks. I wonder if spliting "one-big-script-which-starts-all-services" init script to individual could be better solution. I could do correct dependency to get router killed after all other components. In consecution _all_ jabber services must be killed to restart jabberd2 (or router), for example, when i do upgrade. Hmm... Regards. -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: process "router" doesn't want to be killed
Hi!
Just for information:
Router exits if it gets SIGINT/SIGTERM and all other components are
disconnected.
So 'killall -2 router sm c2s s2s' closes the whole server correctly but it is
not suitable
if multiple servers are started and you need to kill just one of them.
Debug logs states router stucks around loop at router/main.c:490
/*
* !!! issue remote shutdowns to each service, so they can clean up.
* we'll need to mio_run() until they all disconnect, so that
* the the last packets (eg sm presence unavailables) can get to
* their destinations
*/
/* close connections to components */
xhv.comp_val = ∁
if(xhash_iter_first(r->components))
do {
xhash_iter_get(r->components, NULL, NULL, xhv.val);
log_debug(ZONE, "close component %p", comp);
if (comp) sx_close(comp->s);
mio_run(r->mio, 500);
while(jqueue_size(r->closefd) > 0)
mio_close(r->mio, (mio_fd_t) jqueue_pull(r->closefd));
} while(xhash_count(r->components) > 0);
SIGINT stops main loop, but routers enters in the loop mentioned above.
Further SIGINT's just stops 'mio_run(r->mio, 500);' but it enters again if
any component is still connected.
As soon as all other components are disconnected, the loop exits and router is
closed. It look like 'works as designed' but users are still unhappy ;-)
I was trying to do some workarounds but it looks like an ugly hack so I dropped
it.
I've spent a while writing daemon-based replacement for legacy perl 'jabberd'
script
It starts all configured modules at once and kills them together and also it is
suitable for init.d
I'm going to publish a patch as soon as I clean up some debug, private
configuration and ugly hacks.
Stay tuned!
On Friday 25 March 2011 00:29:14 Marcin Mirosław wrote:
> Hi!
> Does anybody have any thoughts about this problem?
> Regards
>
>
--
To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: process "router" doesn't want to be killed
=?ISO-8859-2?Q?Marcin_Miros=B3aw?= writes: - Does anybody have any thoughts about this problem? I've seen the same issue, but not set about trying to track it down.. -- Eric Schnoebelene...@cirr.comhttp://www.cirr.com "What a distressing contrast there is between the radiant intelligence of the child and the feeble mentality of the average adult." -- Sigmund Freud -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: process "router" doesn't want to be killed
Hi! Does anybody have any thoughts about this problem? Regards -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
process "router" doesn't want to be killed
Hello!
I'm testing version 2.2.13, i've noticed that process router doesn't
shutdown after SIGTERM but cleses e.g. tcp socket. Init scripts throws
error about it then continue killing other jabberd process. After all i
can't find process "router". It seems router shutdowns when other
process are killed. Is it issue or feature?:) If i can do something more
(gdb etc.) please let me know.
Thanks!
About OS: xen paravirt, kernel: 2.6.36-hardened-r9 , gcc version 4.5.2
(Gentoo Hardened 4.5.2 p1.0, pie-0.4.5), glibc-2.11.3.
strace log:
Process 29510 attached - interrupt to quit
time(NULL) = 1300126406
epoll_wait(4, {}, 32, 5000) = 0
time(NULL) = 1300126411
epoll_wait(4, 179f4b18, 32, 5000) = -1 EINTR (Interrupted system call)
--- SIGTERM (Terminated) @ 0 (0) ---
sigreturn() = ? (mask now [])
time(NULL) = 1300126415
time(NULL) = 1300126415
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
write(3, "Mon Mar 14 19:13:35 2011 [notice"..., 48) = 48
epoll_ctl(4, EPOLL_CTL_DEL, 5, {0, {u32=396293544, u64=396293544}}) = 0
close(5)= 0
time(NULL) = 1300126415
send(6, "", 16, 0) = 16
epoll_wait(4, {{EPOLLIN, {u32=396295648, u64=396295648}}}, 32, 500) = 1
time(NULL) = 1300126415
ioctl(6, FIONREAD, [16])= 0
recv(6, "", 1024, 0)= 16
epoll_ctl(4, EPOLL_CTL_MOD, 6, {0, {u32=396295648, u64=396295648}}) = 0
epoll_ctl(4, EPOLL_CTL_DEL, 6, {0, {u32=396295648, u64=396295648}}) = 0
time(NULL) = 1300126415
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
write(3, "Mon Mar 14 19:13:35 2011 [notice"..., 69) = 69
time(NULL) = 1300126415
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2679, ...}) = 0
write(3, "Mon Mar 14 19:13:35 2011 [notice"..., 53) = 53
time(NULL) = 1300126415
send(8, "http://jabberd.";..., 103, 0) = 103
epoll_ctl(4, EPOLL_CTL_MOD, 9, {EPOLLIN, {u32=396337352,
u64=396337352}}) = 0
epoll_ctl(4, EPOLL_CTL_MOD, 9, {EPOLLIN, {u32=396337352,
u64=396337352}}) = 0
close(6)= 0
epoll_wait(4,
--
To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
