| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
65632
|
Thu Oct 25 12:04:02 2007 |
 | Peter Rienstra | peter.rienstra@gmail.com | Bug report | Other | 2.6.5:1946 | Date attribute in Quick filter |
Stefan,
I downloaded the latest source (ELOG V2.6.5-1946) to solve another problem. But now I get:
Error: "Attribute "Date" for quick filter not found", see attachment.
In the configfile I have: Quick filter = Date
A bug?
(It works fine, so it's not really a big problem.) |
| Attachment 1: error.jpg
|
|
|
65633
|
Thu Oct 25 20:15:46 2007 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.5:1946 | Re: Date attribute in Quick filter |
| Peter Rienstra wrote: | I downloaded the latest source (ELOG V2.6.5-1946) to solve another problem. But now I get:
Error: "Attribute "Date" for quick filter not found", see attachment.
In the configfile I have: Quick filter = Date
A bug? |
Yep. Fixed in V2.6.5-1951. |
|
66041
|
Tue Nov 11 16:45:04 2008 |
 | Kester Habermann | kester.habermann@gmail.com | Bug report | Other | 2.7.5 | 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. |
|
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. |
|
66099
|
Mon Dec 8 08:59:56 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Other | 2.7.5-2143 | Re: Change background color |
| mike cianci wrote: |
|
I copied the following line from the ELOG documentation file to my config file (with the appropriate changes to the attribute and value fields) and nothing happens. Am I missing something?
Style importance severe = background-color:red
Thanks for all your help.
|
Just the "usual candidates":
- Any typo?
- Edited the wrong file?
- Must send a HUP signal to elogd if running under linux
- Note that the style changes only in the list display
I just tried with a minimal configuration file:
[demo]
Attributes = Author, Importance, Subject
Options Importance = normal, severe
Style Importance severe = background-color:red
and it just worked fine:
|
|
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) {
|