Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 272 of 807  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Show attachments  Show only new entries    6451 Entries 
Goto page Previous  1, 2, 3 ... 271, 272, 273 ... 805, 806, 807   Next  
ID Date Icon Author Author Email Category OSdown ELOG Version Subject
  65632   Thu Oct 25 12:04:02 2007 Entry Peter Rienstrapeter.rienstra@gmail.comBug reportOther2.6.5:1946Date 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.)
  65633   Thu Oct 25 20:15:46 2007 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.5:1946Re: 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 Angy Kester Habermannkester.habermann@gmail.comBug reportOther2.7.5elogd 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 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.7.5Re: 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 Reply Stefan Rittstefan.ritt@psi.chQuestionOther2.7.5-2143Re: 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:

Capture.png

  66367   Wed Jun 3 19:53:13 2009 Reply Paul T. Keenerkeener@hep.upenn.eduBug reportOther2.7.5Re: 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 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.7.5Re: 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 Reply Paul T. Keenerkeener@hep.upenn.eduBug reportOther2.7.5Re: 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.
Goto page Previous  1, 2, 3 ... 271, 272, 273 ... 805, 806, 807   Next  
ELOG V3.1.5-3fb85fa6