First, thank you so much for elog;
after using it for about 3 years, it has proven really handy and reliable.

When there is a very long URL in a message in "plain" encoding,
and this message is displayed in a list of messages,
a very long scrollbar appears at the bottom (same "scroll width" as the URL)
and some tabs and and dropdowns (filters) are unreachable without scrolling.

This does not happen if

• the message is displayed in single message page
• the message has a ELCode encoding

The exact version used is
0b9f7ed0 Merge branch 'develop'

There are no relevant instructions in elog.css for .messagelist,
and I did not find any obvious fix in the source code.

That make sense. Is there a way to recovery when hung except restart elogd? On the other hand, whether could  prompt for reloading attachment when interpreter detect error but not hang?

Wu Xuan

The problem is you have some weird characters in your file name R2BLM15 ? ? ? ? ? .PNG which confuses the interpreter. There should not be any special character or blanks in attached images.

Stefan

I tried to run elog with SSL so I created key and crt files. In crt file I added client certificate and intermediate certifacte. Unfortunately, when I try to run openssl s_client -showcerts -connect myexample.com:443 I got only the first certificate from the chain. Anyone has idea why this happens?

Sounds really strange to me. The remote server does not "know" that "S:\" is a network drive, so the syncing process should work exactly as before. The only idea I have is that the access to the network files take pretty long, and you run into a timeout during syncing. We had this in the past (for AFS netwhor shares, not Windows shares), where sometimes we have a blocking behaviour where the file access lasted 10-20 seconds, and the server process was simply blocked. Since then I do not recommend to put logbook on network shares.

Stefan

We have a number of temperature chambers – each has its own laptop running a local ELOG server, with unique logbook for each.  Using the mirror feature, these individual logbooks periodically synchronize to a single remote desktop server, which has a copy of each of the logbooks.  All of that works great, as long as each of the ELOG servers are storing the logbook(s) to their respective local hard drive.

I wanted the remote server to store its copy of the logbooks on the network file server.  I changed the global options of the elogd.cfg file, adding the following:

               Logbook dir = S:\SHARED\LOGBOOKS

That change worked fine on the remote desktop server – new logbook entries were now being stored on the network file server.

Unfortunately, I lost the ability to sync from the individual logbooks to the remote desktop server.  During synchronization, I now get the following error message: “Error sending local entry: Error transmitting message". 

Has anyone run into this? Does this make sense? Am I missing something? Is there a workaround? Is there a wrong time to drink beer?

Thanks,

Frank

May I slip my vote in for this, especially if it would allow more than 100 attributes (the default, and I do know how to increase it).

I even considered cutting that into two groups,. the first being words like "New", "Re-" and the second being actions.  Clunkey and binned.

Just my two cent - I would have many very good applications for that feature:

• Keep option lists identical over different logbooks.
• Keep option lists identical over different applications.
• Create option lists from a database - that allows to use the options in many applications and in the database; e.g. a list of systems with a failure database, but failure reports in the regular ELOG.
• Export extendable option lists to other applications:
  • Inform administrator about options that have been newly added to a logbook for a review.
  • Provide option lists as menu buttons in these applications.
  • Prevent other applications to submit elog entries with illegal option choices.
• Import extendable option lists from other applications (at least after next elogd restart, if no "update option list" URL/command is provided for elogd).

We recently went through the process of renaming a "system list" in several logbooks, to make it consistent over several facilities. If the "on-call service" is called "radio frequency", but the "system" is called "RF", then searching the logbook can become difficult. It was painful: half a dozen applications had to be adapted at the same time the lists were updated, because they had features to create a failure report to ELOG - assuming specific "system" names.

So I'm in favour of putting that high up in the wishlist :-)