| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
678
|
Fri Aug 27 00:49:27 2004 |
 | Heiko Scheit | h.scheit@mpi-hd.mpg.de | Bug report | Linux | 2.5.0 | Re: elogd does not exit on SIGTERM |
> Noee. Here it works immediately.
>
> Can you try with a fresh server from the distribution, with the example
> elogd.cfg, to see if there is any difference?
>
> The killing is handled in the funciton ctrlc_handler(), which sets _abort =
> TRUE. This is checked in line 16195, just after the select(), and the main
> loop is exited. The select finishes after one second, although I believe
> that the kill signal also terminates the select prematurely. The kill
> command and a Ctrl-C keystroke should work the same way, they both generate
> a SIGTERM or SIGINT signal.
elogd does not exit if there is an 'unprocessed' HUP. So when you do
kill -HUP <pid>
kill <pid>
elogd will only exit after it was accessed. |
|
695
|
Wed Sep 8 17:38:54 2004 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.5.0 | Re: elogd does not exit on SIGTERM |
> elogd does not exit if there is an 'unprocessed' HUP. So when you do
>
> kill -HUP <pid>
> kill <pid>
>
> elogd will only exit after it was accessed.
Can you please tell me how to reproduce this problem?
Even if I do a
kill -HUP <pid>; kill <pid>
it works immediately when I start elogd manually in interactive mode (not as daemon). |
|
697
|
Wed Sep 8 23:03:36 2004 |
| Heiko Scheit | h.scheit@mpi-hd.mpg.de | Bug report | Linux | 2.5.0 | Re: elogd does not exit on SIGTERM |
> > elogd does not exit if there is an 'unprocessed' HUP. So when you do
> >
> > kill -HUP <pid>
> > kill <pid>
> >
> > elogd will only exit after it was accessed.
>
> Can you please tell me how to reproduce this problem?
>
> Even if I do a
>
> kill -HUP <pid>; kill <pid>
>
> it works immediately when I start elogd manually in interactive mode (not as daemon).
Even though I can't test this right now, I assume you have to wait a little
so that elogd jumps out of the 'select()' statement between the kill
commands. Try:
kill -HUP <pid>; sleep 2; kill <pid>
(I think the 'select()' timeout was 1 second.?) |
|
699
|
Thu Sep 9 21:40:47 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.5.0 | Re: elogd does not exit on SIGTERM |
> kill -HUP <pid>; sleep 2; kill <pid>
Thanks, I could reproduce the problem. It had to do that a SIGHUP aborts the select()
command, which some listen socket marked, so that elogd goes into an accept() call, waiting
there indefinitely (or until a new browser request arrives). I fixed that. New version
under CVS. |
|
66050
|
Mon Nov 17 10:27:23 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.7.5 | Re: elogd dies after receiving second SIGHUP |
> elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> This was observed on Solaris 10 (SPARC).
> The documentation states that elogd should re-read configuration after receiving SIGHUP.
I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe
you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to
start the daemon interactively and see what exactly happens if you send several SIGHUPs. |
|
66367
|
Wed Jun 3 19:53:13 2009 |
| Paul T. Keener | keener@hep.upenn.edu | Bug report | Other | 2.7.5 | Re: elogd dies after receiving second SIGHUP |
> > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > This was observed on Solaris 10 (SPARC).
> > The documentation states that elogd should re-read configuration after receiving SIGHUP.
>
> I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe
> you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to
> start the daemon interactively and see what exactly happens if you send several SIGHUPs.
The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
is called. Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.
The solution is to use the POSIX sigaction() call instead of signal(). |
|
66368
|
Thu Jun 4 09:49:13 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.7.5 | Re: elogd dies after receiving second SIGHUP |
> > > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > > This was observed on Solaris 10 (SPARC).
> > > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> >
> > I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe
> > you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to
> > start the daemon interactively and see what exactly happens if you send several SIGHUPs.
>
> The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
> is called. Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.
>
> The solution is to use the POSIX sigaction() call instead of signal().
Can you try to modify the signal() calls into sigaction(). If this really works under Solaris, I will incorporate this
then into the distribution. |
|
66377
|
Thu Jun 4 18:49:29 2009 |
| Paul T. Keener | keener@hep.upenn.edu | Bug report | Other | 2.7.5 | Re: elogd dies after receiving second SIGHUP |
> > > > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > > > This was observed on Solaris 10 (SPARC).
> > > > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> > >
> > > I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe
> > > you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to
> > > start the daemon interactively and see what exactly happens if you send several SIGHUPs.
> >
> > The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
> > is called. Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.
> >
> > The solution is to use the POSIX sigaction() call instead of signal().
>
> Can you try to modify the signal() calls into sigaction(). If this really works under Solaris, I will incorporate this
> then into the distribution.
Here is the patch. It works under both Solaris and Linux. |
| Attachment 1: elogd-signal.patch
|
*** src/elogd.c-orig 2009-04-14 04:16:02.000000000 -0400
--- src/elogd.c 2009-06-04 11:33:31.337804000 -0400
***************
*** 27553,27558 ****
--- 27553,27565 ----
SSL_CTX *ssl_ctx;
#endif
+ /*
+ * sigaction structs
+ */
+ struct sigaction ctrlc_handle;
+ struct sigaction ignore_handle;
+ struct sigaction hup_handle;
+
i_conn = content_length = 0;
net_buffer_size = 100000;
net_buffer = xmalloc(net_buffer_size);
***************
*** 27708,27718 ****
close(fd);
}
! /* install signal handler */
! signal(SIGTERM, ctrlc_handler);
! signal(SIGINT, ctrlc_handler);
! signal(SIGPIPE, SIG_IGN);
! signal(SIGHUP, hup_handler);
/* give up root privilege */
if (geteuid() == 0) {
if (!getcfg("global", "Grp", str, sizeof(str)) || setegroup(str) < 0) {
--- 27715,27739 ----
close(fd);
}
! /*
! * install signal handlers
! */
! ctrlc_handle.sa_handler = ctrlc_handler;
! sigemptyset( &ctrlc_handle.sa_mask );
! ctrlc_handle.sa_flags = 0;
!
! sigaction(SIGTERM, &ctrlc_handle, NULL);
! sigaction(SIGINT, &ctrlc_handle, NULL);
!
! ignore_handle.sa_handler = SIG_IGN;
! sigaction(SIGPIPE, &ignore_handle, NULL);
!
! hup_handle.sa_handler = hup_handler;
! sigemptyset( &hup_handle.sa_mask );
! hup_handle.sa_flags = 0;
! sigaction(SIGHUP, &hup_handle, NULL);
!
!
/* give up root privilege */
if (geteuid() == 0) {
if (!getcfg("global", "Grp", str, sizeof(str)) || setegroup(str) < 0) {
|