This is not a bug, this is a feature! Once you log in to ELOG, your credentials are stored in cookies of your local browser. If you access a logbook entry, like via the link you in your email, you still use that credentials. If you clear all cookies of your browser, or log out explicitly from ELOG, then of course you will only get guest access. 

Hi

The problem is not exactly what I thought, but I did track it down. Here is a logbook definition that reliably creates a segmentation fault in e-log. This logbook's only useful purpose is in fact to create a segmentation fault:

You select "New", then "Select", without entering anything.

--------------

Login user = Admin

Attributes = Link

Change Link = <a href="https://$Link"">$Link</a>

---------------

I would be able to create some more debugging information of course, if needed.
 

Regards

Soren

 Thanks Stefan

This was probably a buggy bug report. Was just testing things out on a local machine and cookies were send to the local machine. so the mail was using these cookies also.

In Practice this could never happen. 

> > 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(). 

> > > 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.

Actually I do want to receive a copy, just to be sure that the emails got sent out correctly. I agree that an option would be good for that but it's not implemented right now. An alternative solution is to define a filter in their email client to discard these messages (like if subject contains ELOG and sender equals your own mail address).

I had finally the same problem. This is due to a bug indeed inside is_script(). It has been fixed in revision 2201. 

Thanks for reporting this bug. I fixed it in revision #2203.