We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it?

Details

We have two elog servers set up with identical elogd.cfg and password files, except that one server has "Mirror server" pointing to the other host. There are three logbooks defined.  (Their names are DoubleChooz, BigBrotherTable, and FlushingTable.)  When the mirror synchronization happens, whether by "Mirror cron" or by an administrator hitting the "Synchronize all logbooks" link, it often happens that entries requiring synchronization are corrupted on both servers (not just the one to which the entry was copied). This is particularly likely to happen if entries have been made on both servers since the previous sync.

Looking at the logbook files themselves, we see that the corrupted entries will have attributes from the wrong logbooks. E.g., we'll see an empty "Barometer: " line in a DoubleChooz logbook file, where "Barometer" is an attribute that is only in the FlushingTable logbook, or we will see there are unexpected DoubleChooz logbook attributes in the FlushingTable files.

Strangely, the entries will not be identical on the two machines after syncing, and they stay non-identical on further syncs.

Most disturbingly, data is lost from entries that were perfectly valid before the sync, on both servers.

This was happening with elogd 2.7.8, and continued to happen after upgrading to 2.8.0. Both servers are running Linux. One is a 32-bit machine and another 64-bit, in case that might matter (but read on).

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized.  This suggests it isn't specific to Linux architecture, 64-bit or otherwise.

We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.

Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?

Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-)

 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.

 Since we updated to 2.7.8 we've found a problem.

Previously, when we used 

Subst on reply subject = Re: $subject

Sorry, that appears to be an undocumented bug fix :-)

The desired behaviour should be created by

Preset on reply subject = Re: $subject

The command "Subst" is supposed to overwrite the field after it is submitted.

From the documentation you will even find a nicer possibility:

Preset on first reply Subject = Re: $Subject

The prevent replies to build a long chain of "Re: Re: Re: ...."

Cheers Andreas

I just typed a long text into this elog, clicked "submit" and it bombed with "you must select an Icon", returned me to the editor with all my text gone gone gone. I do not want to select icons, I just want to report a problem with elog. Well, 2 problems, now.

K.O.

Well, first RTFM: "Fields marked with a * are required" on top of the elog entry page. Then, use a reasonable browser on a reasonable OS  

On Google Chrome the text is still there (actually I just tried it with this entry). No idea what Safari under OSX does. Under Windows, Safari keeps the text. Actually this is controlled by the FCKEditor inside elog which is written by someone else. So complain there! Funny: We have about 1000+ entries in this forum, and you are the first one complaining about this.

Hi, I rsync an elog database from CERN to TRIUMF every few months and I notice that rsync keeps copying preview files (xxx.png.png, xxx.gif.png, etc) from very old entries. I guess that elogd creates these files from scratch each time they are needed, overwriting any previously existing preview files. This creates extra rsync network traffic and rsync takes longer to complete. Is there any way to avoid this? K.O.

Actually the thumbnail files are only created if they are not there. This is done in the function crate_thumbnail():

   i = get_thumb_name(file_name, str, sizeof(str), 0);

   if (i)

      return i;

So if these files are recreated always, something must be wrong there. Or you sysadmin runs a cron job which deletes them every evening 

Dear ELOG users,

this is to announce an important security update. As proposed by Lukasz Olejnik (CERN/PSNC), ELOG has now switched to strong encryption of password. So everybody concerned in security is advised to update to the new version 2.8.0. Existing password files for Windows users and Linux users not using HAVE_CRYPT are automatically converted. Those installations which used HAVE_CRYPT in the past under Linux have to ask their users to re-enter their password (via the link "Forgot password") after the upgrade to version 2.8.0.

Best regards,

  Stefan Ritt

I just realized that the command line elog utility did not yet use the new encryption. So automatic elog submissions using passwords are broken in version 2.8.0. I made an intermediate version 2.8.0-2 which fixes that. However you only need to update it if you use the elog utility and have problems with the 2.8.0 version.

Hi

I am trying to use this line from the documentation:

Execute new = echo "New message wiht ID $message id of type $type from $long_name on $remote_host" >> /tmp/elog.log

It does not seem to have the intended effect (of printing a line with the message id, etc in the file /tmp/elog.log
)

How can I make this line work ?

Soren

Execute new = echo "New message wiht ID $message id of type $type from $long_name on $remote_host" >> /tmp/elog.log

It does not seem to have the intended effect (of printing a line with the message id, etc in the file /tmp/elog.log
)

How can I make this line work ?

Soren

Have you started the server with the "-x" flag as written in the documentation? 

Execute new = echo "New message wiht ID $message id of type $type from $long_name on $remote_host" >> /tmp/elog.log

It does not seem to have the intended effect (of printing a line with the message id, etc in the file /tmp/elog.log
)

How can I make this line work ?

Soren

 Thanks a lot for replying despite the heat. Yes, I executed with the "-x" flag.

It is just a quoting problem, I guess. This line works:

Execute new = echo New message with ID $message id of type $type from $long_name on $remote_host >> /tmp/elog.log

It evaluates to:

SHELL "echo New message with ID 24706 of type elogtype from Soren Poulsen on 137.138.22.11 >> /tmp/elog.log"
 

So next step is to replace "new" with "edit" and "delete".

That works as well.

Soren

Execute new = echo "New message wiht ID $message id of type $type from $long_name on $remote_host" >> /tmp/elog.log

It does not seem to have the intended effect (of printing a line with the message id, etc in the file /tmp/elog.log
)

How can I make this line work ?

Soren

There is sometimes a problem with substitutions like "Execute delete = echo $message id".

It seems the problem is that if you delete a logbook entry that is not created with the current logbook attributes, the substitution variables are replaced with the variable name, and not the variable value.

In this example, according to the log file it becomes SHELL "message id" instead of SHELL "234", if the logbook entry is 234.

Soren

I tried to reproduce it, but it always worked for me. So I need a step-by-step instruction from you on how to reproduce the problem, ideally starting from the demo logbook from the distribution. Only if I can reproduce the problem, I will be able to fix it. 

 It is of course my job to reproduce it (and explain how-to).  Thanks for your consideration.

 Hi Stefan,

I'd like to request a feature: automatic alphabetization of the items in the Quick Filter menus.

We track quite a few detector assemblies, which are produced with non-sequential designations. It would be useful if the Quick Filter list was automatically sorted alphabetically to make it more convenient for folks to find a particular item.

I know people can always search by designation but it would be handy to have this alpha sorting feature. Would it be possible to include that in a future release?

Thanks again for a *very* useful logging system!

Dennis

The order of items in a Quick Filter menu is exactly as in the configuration file. Like if you have items

Options Type = C, D, A, B

they are shown like that in the quick filter menu. If you want to sort them, just do the sorting yourself in the configuration file like

Options Type = A, B, C, D

I have not implemented automatic sorting since some people want a different order, like some main topics at top. So by following the order from the configuration file, everybody can be satisfied just by chaning the order in the config file.

- Stefan 

 Yes, I have been manually sorting and resorting. We have extendable attributes and the list keeps growing so I have to resort every so often. I thought perhaps a simple alphanumeric sort as an option would be popular with most users so I thought I'd ask for it. It would really simplify things for me. Users who want to sort manually could do so by disabling the option. It never hurts to ask!

Ok, I implemented

Sort attribute options = 1

in the current SVN revision. 

 I've tried adding this statement to my cfg file but the attributes are still unsorted in the QuickFilter menus. Was this implemented in 2.7.7?

You need revision 2252 or later. So you have to upgrade to 2.7.8. 

 We have upgraded to 2.7.8 but this still doesn't seem to work. The quick menus are still unsorted. Does it work for you?

Sorry, there was a typo, you need

Sort attribute options <attribute> = 1

where <attribute> is the name of the attribute to be sorted (in case you want some attributes sorted, but not all). 

 That did the trick. That was a good idea, to give us the option of which attributes to sort, too. Thanks again for adding this feature!

I wondered if there was a config line that enabled/disabled the forward and backward navigation keystrokes that were implemented in 2.7.0?

The current definitions (Control-PgUp/PgDown/Home/End) interfere with those keys I use to navigate between tabs in Firefox.  It'd be nice if they could either be turned off.. or redefined.

They are defined in

<ELOG directory>\scripts\elcode.js

Just go to the browse(evt) function and redefine or remove them there. 

 Got it to work as desired.

Thanks for your help and your quick response.