Date attribute in Quick filter, posted by Peter Rienstra on Thu Oct 25 12:04:02 2007 
|
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.) |
Re: Date attribute in Quick filter, posted by Stefan Ritt on Thu Oct 25 20:15:46 2007
|
| 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. |
elogd dies after receiving second SIGHUP, posted by Kester Habermann on Tue Nov 11 16:45:04 2008
|
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. |
|
Re: elogd dies after receiving second SIGHUP, posted by Stefan Ritt on Mon Nov 17 10:27:23 2008
|
> 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. |
|
Re: Change background color, posted by Stefan Ritt on Mon Dec 8 08:59:56 2008
|
| 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:
|
|
Re: elogd dies after receiving second SIGHUP, posted by Paul T. Keener on Wed Jun 3 19:53:13 2009
|
> > 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(). |
|
Re: elogd dies after receiving second SIGHUP, posted by Stefan Ritt on Thu Jun 4 09:49:13 2009
|
> > > 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. |
|
Re: elogd dies after receiving second SIGHUP, posted by Paul T. Keener on Thu Jun 4 18:49:29 2009
|
> > > > 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. |