Also see this in ALPHA at CERN. Eventually there are so many defunct elogd processes that the user runs out of "maxproc" quota and automatic submission 
of elog messages starts to fail. (and the users complain, reboot all computers, etc).

The elogd we use is this:
https://bitbucket.org/ritt/elog/commits/44800a769b99599db7620779e2142b1161c694fc?at=master

The best I can tell, the main elogd is spawning something but does not reap finished subprocesses (wait() syscall). My guess it is spawning ImageMagik stuff 
to create preview images.

K.O.

You are using the entry ID to sort your entries: there is no good way to insert a new entry ID, like 300.5

But you could sort your entries by other means, that allows you to insert entries later between existing entries.

I use for example a "when" attribute of type datetime. Here's an excerpt from the relevant part of my config file:

There is nothing within elog itself to insert entry 310 between 300 and 301.  If you allow branching in your logbook. make a second reply to entry 300, and add in the missing details.  That entry will always be there as a reply to 300, but not obviously between 300 and 301.

From this point, any way to improve matters will require editing of the log files (default location /usr/local/elog/logbooks).  I should warn that editing these files can cause problems, including elog to crash, and spotting your error can take a lot of effort.  I speak from experience. I suggest that you have a look at a few entries, the layout of the entries etc first, and if you're still up for it I'll give a quick spin on how to improve the tidyness of how your entires look with 310 inserted between 300 and 301.

I should add what I would write only applies for certain for linux users, as it is my OS of choice.

 I would like to put between two entries a new entry.

My Users forgot to put a entry, and now they would like to put a new entry between olders entries.

For Example:

We have 10 entries order by Id:

300

301

302

...

They want to put between the entry 300 and 301 a new entry.

Is possible to do this feature?

Thanks! 

IMPORTANT SECURITY ANNOUNCEMENT

Recently the POODLE vulnerability has been announced: http://en.wikipedia.org/wiki/POODLE 

ELOG is prone to this vulnerability if it runs directly the SSL protocol and can be accessed from the internet. If ELOG runs behind an Apache proxy, and the Apache server has been correctly configured (disabled the SSLv23 protocols), ELOG is safe as well.

To fix this vulnerability, ELOG needs to be recompiled after the attached patch has been applied. This prohibits ELOG to fallback to the insecure SSLv2 & v3 protocols and only use the safe TLSv1 protocol.

If you do not know how to recompile ELOG, please do not run ELOG directly accessible from the internet until the next binary release has been published.

/Stefan Ritt

ELOG contains Kerberos authentication at a basic level. If I'm not mistaken, the Windows Domain controller is based on Kerberos. I do not have any 2008 or 2012 domain controller, so I cannot test, but it's worth giving it a try.

/Stefan 

Andreas Luedeke wrote:

Chris Jennings wrote: Chris Jennings wrote: I have an attribute formatted as a date (but not labeled as date) and is sorted as second priority. The sort works fine until I enter a date older than Jan 1st 2002. When I do this it is sorted as the latest. Is this a bug or simply not designed to use dates this old? Thanks in advance, Chris  Sorry, my mistake. The cutoff date is anything before September 9th 2001 does not sort. I think I remember that this has been discussed earlier: it is a little bug in elogd. You can see where it comes from if you type in the little command 'date -d "9-Sep-2001 3:46:40" +%s' Converted to "seconds of the epoche" (seconds since 1970-01-01 00:00:00 UTC) the date "9-Sep-2001 3:46:40" has one digit more than "9-Sep-2001 3:46:39". Since elog makes a string comparison, suddenly 1'000'000'000 is less than 999'999'999; therefore the wrong sorting. Workaround: you can modify your old entries and add a leading zero to all entries where your specific date field starts with a '9'. Stefan: you should fix it at least well before 20-Nov-2286 18:46:40, when the same bug strikes again!

Ok, well before 2286 approaches I fixed that bug and committed it to the GIT repository (master branch).

/Stefan