I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".

Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.

However, if eLog is run with "-v" in place of "-D", it does not crash.

Environment:

        CentOS 5.4

        eLog 2.8.0 built Aug  5 2010, 12:24:11

I could never get shell execution work when elogd is started as a service. This has probably to do with system permissions or so under Windows. If anybody has a clue, please let me know. Under Linux this works nicely, but this is probably not an option for you...

Dear colleagues,

I am trying to use the elogd as a service with activated shell-execution. Invoking 'elogd -x' on the command line works fine, as well as 'elogd -install'. The option 'elogd -x -install' does not seem to be implemented, so I followed two ways to get this to work:

1) creating my own service with instsrv/srvany and registry editing: starting 'elogd -x' does not work (error 1053), the -D option has to be added, to start the service without time out. But then shell execution seems to be not working, because no input to the elog is generated, but also no message saying shell execution was not enabled!

2) using 'elogd -install' and modifying the registry entry by adding the -x option to the command line in the 'HKLM\System\CurrentControlSet\Services\elogd\ImagePath': This enables shell execution, but instead of piping the output to the logbook, some DOS boxes pop up executing the shell command and terminate. No entries are generated.

Has anyone an idea?

Best regards

 Robert

Hi Stefan,

> There was a timeout of 1 sec. in the elogd daemon, which probably is too short for a satellite connection. Unfortunately I have no satellite here 
> around to test it, so I "blindly" increased it to 6 seconds in the current SVN version. Please give it a try.

The latest release (2.8.0-2313) does fix this problem.  Our user is now able to modify entries and upload attachments using their satellite connection.

Thank you very much for your time and help.  I am sorry I didn't receive this in time to help test the old SVN version.

Sincerely,
Devin

Answer : Problem solved. It is not window7 related. When I did a fresh install ( not installing over the old directory ) everything is working as expected. So I did something wrong with installing over the old elog directory.

Thanks for you're time and the inconvenience.

Hello

Using windows7 and the elogd 2.7.7 built Jul 31 2009, 13:01:20 revision 2246.  I noticed a bug in the tables created with fckeditor. When on winxp there is no problem. So it seems windows7 related. 
Don't know if I should post here or somewhere else. When i Click the table icon i get : 
When I want to continue ( Pressing Yes) i get

So the OK button is removed, and i can only cancel. So it's impossible to create a new table in elog. ( yes , create it by hand, but that is not so nice )
Download the latest version of elog : elogd 2.8.0 built Aug  2 2010, 12:16:05 revision 2312 . Just to see if this helps. The result is the same.
Is there some solution/workaround for this ?

Thanks for elog : it's great.

 I have been using the mirror mechanism for one year for the online T2K /ND280 (neutrino oscillation experiment at J-PARC, Japan).  It has been a savior to allow access to all collaborators to the Elog.  The experiment online computers are all behind a double firewall that allow only communication through ssh and http in one direction: from the inside to the outside. The master Elog is located in Canada and accessible remotely to all collaborators.  The mirror Elog is located inside the firewall on one of the online machines in Japan and synchronization is setup to run automatically every 5 minutes. There are 10 logbooks defined for each of the sub-detector groups.

At first I encountered a big problem when messages were added on both sides.  It turned out that Elog mirroring does not work when the two instances are running on different time zones. After I set the machine in Canada to run on Japan time (JST), no further problems have happened. Postings are routinely entered on either of the Elogs and synchronization works well.  This feature is essential to having a workable Elog for the T2K experiment. 

I had reported the problem of timezones to Stefan last year. He was going to put it on his wish list.