> Have a look at the gcc info pages:
> 
> $ info gcc "invoking gcc" "warning options"

Sure, I'm not stupid! I looked for ~10 minutes how to turn off the remaining 
warnings, but I could not find it. The code is now correct, like I do want the 
"%y" format specifier in the strftime() function, but the warning is wrong. The 
closest I came to was 

-W -Wall -Wno-format

which removes ther warning in strftime(), but I do want this warning, since it 
helps in many other printf() statements.

> > Have a look at the gcc info pages:
> > 
> > $ info gcc "invoking gcc" "warning options"
> 
> Sure, I'm not stupid! 

  Sorry, didn't mean to offend you.

> I looked for ~10 minutes how to turn off the remaining 
> warnings, but I could not find it. The code is now correct, like I do want the 
> "%y" format specifier in the strftime() function, but the warning is wrong.

  One way to remove the warnings would be to use "%Y" in a separate strftime() call
  and then taking only the last two digits (characters) of that string.

  Something like:
old:
   strftime(str, sizeof(str), "%A, %d-%b-%y %H:%M:%S GMT", gmt);

new:
   strftime(str, sizeof(str), "%A, %d-%b-XX %H:%M:%S GMT", gmt);
   strftime(year, sizeof(year), "%Y", gmt);
   i=strstr(str,"XX"); /* find position of XX */
   if ( i+1 < sizeof(str) ) {
     str[i]  =year[3];
     str[i+1]=year[4];
   } else ...

  Somewhat cumbersome, but should work.  Maybe consider using the four 
  digit year directly, where possible.

  Gruss, Heiko

When trying to stop elogd processes with the kill command
elogd exits only after access to the logbook.

It should exit immediately, maybe after some cleanup.

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.

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

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

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

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