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

> > [...]
> > > Probably it is fine to display only files ending in '.txt' per default.
> > > In addition a file that has more than say 1000 lines should probably 
> > > also not be displayed (as default, optional OK).  
> > 
> > No, '.txt' would definitely not be enough for me. I'm using elog to log all
> > administration of our network. In many cases, I simply attach a configuration
> > file. All those files are plain ASCII and none of them end in '.txt' - and I
> > would most definitely like them to be displayed inline like they are now. In
> > fact, this change was the main reason for me to upgrade to 2.5.4
> > 
> > Maybe a configuration option or a "display attachment" button would be the
> > best solution, then?
> > 
> > Cheerio,
> > 
> > Thomas
> 
> So to make everybody happy, it would probably be enough not to display inline any
> *.ps file, is that right? 

I think there should be size limit.  Imagine a multi MB text file (whatever it is;
elogd.c is already more than 1/2 MB and is likely to increase due to your
excellent support).  A client on an ISDN line would have to wait
several minutes and during this time elogd is busy and no other client can connect
(correct?).  Of course, if somebody really wants to see this file then there is
nothing to be done, but likely someone is flipping throught the messages using
to arrows on top to find the right entry....
So a configurable size limit seems appropriate, from which on 
only 'Display attachment' is displayed.  And/Or, for files
exceeding this limit, the first N (new config option) lines could be displayed.

But this should only influence ASCII files.  E.g. the behaviour for jpeg files
should not change, which is controlled by 'Hide default'.  Maybe a 'Display/Hide
defaut extension' option, where the extensions are listed that are to be displayed
is another idea, in addition to a 'Max Display ASCII inline size' option,
which can be set to zero to disable it altogether.

In any case, whatever you think is best.

Cheers, Heiko

> Is there any other ASCII format, which should not be
> displayed? PDF is binary, so it won't be displayed. What about long C files? Most
> people want to see them. In the recent version there is the "Hide attachment"
> link which can be clicked to not display an attachment inline. Mabe there should
> be a "Hide default = 0|1" config option...

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

> So a configurable size limit seems appropriate, from which on 
> only 'Display attachment' is displayed.  And/Or, for files
> exceeding this limit, the first N (new config option) lines could be displayed.

Ok, I changed elogd such that only the first 1000 lines of inline attachments are
displayed, with a note of how many lines are truncated. By clicking on the attachment
name, one can still download the complete attachment. I guess the number of lines do
not have to be configurable, but if someone is not happy with the 1000 lines that could
be added.

> > > Couldn't one include the extra <table> tag only when there is really more than
> > > one attribute per line.  All other lines could then be aligned properly.

I added that code in revision 1.471.

I am getting the following error message with version 2.5.4-4 when I try to
add a new entry to a log book.

Attachment file "" empty or not found

If I add the following line to me elogd.cfg I do not get the error, but will
not be able to use attachments.

Enable attachments = 0

I recently upgraded from version 2.2.5 which did not have the problem.  I
did not see anything in the changelog referencing this type of change to how
attachments are handled.

I there something I need to set in the config so that an attachment is not
expected every time a new entry is made?

That problem has been fixed in 2.5.4-5

When creating new logbooks, I will create a single entry to test the  
configuration. After revising the configuration I want to delete that  
single entry and create a new one based on the revised config.  
  
elogd will crash every time upon deleting that single entry with an  
xrealloc error. Here are the syslog entries leading up to the crash:  
  
Oct  9 08:09:41 obstin8 elogd[20614]:  
GET /Support/1?cmd=Delete&nextmsg=0&confirm=Yes HTTP/1.1^M Connection:  
Keep-Alive^M User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux)  
(KHTML, like Gecko)^M Referer: http://localhost:8080/Support/1?cmd=Delete^M  
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*^M  
Accept-Encoding: x-gzip, x-deflate, gzip, deflate^M Accept-Charset:  
iso-8859-1, utf-8;q=0.5, *;q=0.5^M Accept-Language: en^M Host:  
localhost:8080^M Cookie: urem=0; upwd=dDRubjNyBDI=; unm=mstolove  
Oct  9 08:09:41 obstin8 elogd[20614]: xrealloc: not enough memory  
  
This is on a Slackware 10 box using kernel 2.6.7. Elogd is accessed  
directly, not through an Apache proxy.