I have a crontab set-up for root:

crontab -e

* * * * *       if ! ps -C elogd >/dev/null;then /sbin/service elogd restart;fi

The script just checks if elogd is still running and if not, it'll restart it. We run Centos, but I'm sure it'll be easy to adapt for Ubuntu (I don't know much about Debian).

This will only help if elogd really crashed; in case it is still running at 100% cpu load this won't help.

In our case (~30 logbooks, > 100 entries per day, ~ hundred users) elogd is crashing about once a week. With the help of this script it means 1 minute downtime a week: that's acceptable.

See https://midas.psi.ch/elog/config.html on how to use a logfile with elogd. Here's the relevant excerpt:

• Logfile = <file>
  This option specifies a filename which logs all login/logout activities and successful user connections for logbooks with user level access. The the logging level (see below) is larger than 1, also read and write accesses can be logged.
• Logging level = 1 | 2 | 3
  Specifies the logging level. The higher this value, the more information is logged. Default is 2:
  • 1: Log only logins and logouts
  • 2: Log also write accesses
  • 3: Log also read accesses

By desing, there is no collision between different users, since all requests are executed in sequence (single thread). The only problem is that the server becomes unavailable for others if it executes a long search. This is why most users of large lobooks restrict their search to let's say the last month or so by default. This speeds up the search and limits the dead time for others. This can be done via the show last default = <days> directive.

We have reduced entries for Search reasons by removing older text files and that seems to speed up things. 
However, a recurring problem persists during peak period where the service connection is lost (site says "Not 
found" on both client and directly on server), and it cannot be restarted or killed. Only a reboot of the 2010 
x64 virtual server will make it available again. 

Any further info or details I can provide please advise. Thank you Stefan.

I grant that this may be a complete red herring, but your description below  - not available and having to reboot - 
might have another explanation.  At least in Linux.

I have found that if you have a broken thread, and you try to access that thread, the daemon goes into an endless
loop and
I could not kill off the daemon by normal means, but had to reboot the computer.  The daemon cannot cope with not
finding 
an entry where one is referenced by a subsequent (or previous, I assume) entry.

A broken thread can occur if you move a thread with a large number of subsequent entries - more than say 50 (I
don't know 
the precise number) from one log book to another.  The copy part of the move works, but the deleting of the entries
in the 
original log book is incomplete, leaving an orphan set of (later) entires.  Access those, and it's time for a
reboot.  Which makes 
finding them a potentially tedius and multiple rebooting exercise.  I know, because I've had to track a number in
my time.

Just a thought.

David.


> We have reduced entries for Search reasons by removing older text files and that seems to speed up things. 
> However, a recurring problem persists during peak period where the service connection is lost (site says "Not 
> found" on both client and directly on server), and it cannot be restarted or killed. Only a reboot of the 2010 
> x64 virtual server will make it available again. 
> 
> Any further info or details I can provide please advise. Thank you Stefan.

Being not able to kill a server running in an endless loop seems strange to me. If you put any program artificially into an endless loop, you can kill it via "kill -9 <pid>". Have you tried that? The only exception I 
can imagine is if there is a problem in the file system, like your elog logbooks are mounted via NFS or some other remote filesystem, and you have a problem there. Since the process might be stuck in kernel 
mode, you cannot kill it. That's why I have all my servers running on local file systems. Just another thought.

/Stefan

You need the netdb.h header file to compile elog. I see that you compile under Windows. You have to make sure that your compiler installation comes with all header files. The netdb.h file is usually in /usr/include under Unix.

Welp, nevermind, I dug a little more and managed to compile it on 14.1 using cmake.

The detection in elogd works by executing the command "convert" and check if the program executes. If you start elogd as a service, the program might see another path variable. Maybe reboot Windows or start the service in the environment of a real user instead of system, where it might miss your modified "path".

Stefan