No quick fix, sorry. It is also limited by a fixed number of characters per line in the configuration file and many more. I will try to increase it, but it will take time. Can you maybe set-up a mailing list at your email server? This way you send only email to one destination and it gets distributed to many people.

Hello,

I just upgraded to elog 2.7.5 from 2.6.4 on my Debian system. Here is some feedback:

1) "make" fails if libssl-dev package is not installed. Documentation does not mention SSL library requirements.

2) /etc/init.d/elogd: line 10: /etc/rc.d/init.d/functions: No such file or directory (I fixed this by commenting
out that line).

3) Starting elogd: /etc/init.d/elogd: line 34: echo_success: command not found (Fixed by search/replace "echo_"
to "echo ").


Hope this helps.

George.

I just ran into the following bug:

I have a logbook where entries have several attributes, among which several dates. All of these are set to "Type <attr> = date". If I use the "Select" action, tag several entries and subsequently chose "Edit", the values of all date attributes are wiped. All other attributes are kept at their original values, unless changed explicitly. For the date entries, the date choosers are shown (as when editing a single entry), but all set to blank.

Editing single entries works fine.

elogd is crashing with a segv when I try to create a new logbook by clicking the "Create new logbook" button
with an existing logbook selected in the dropdown list as a template. I've attached my config file for
reference. As a specific example, I'm logged in as the admin user, viewing logbook "1248", which has no entries,
and I click "Config" -> "Change config file" -> "Create new logbook", Select "1248" from dropdown list, enter
"1250" for the new logbook name, and click "Create new logbook".

The server crashes, and my web browser has the following as the (incorrect) URL it's trying to load:
(Incorrect because the "/ATLAS" shouldn't be there.)

https://localhost:8080/ATLAS/1250/?cmd=Config

Nevertheless, the config file and logbook directory are properly modified for the new logbook, and on restarting
the server, everything is fine.

Oh, just noticed that if I manually enter the URL:

https://localhost:8080/ATLAS/1250/

or actually, any text in place of the "1250", it also crashes the elogd process. So, perhaps there are two bugs?

(1) Incorrect URL being given to the web client after logbook creation
(2) Requesting any incorrect URL of this form crashes elogd

 By now, I'm one step further. List conditions = 1 does have some effect in some cases - the following works:

Options Type = Type1{10}, Type2{11}
Options StatusA = Status-A-red, Status-A-orange, Status-A
{10}Style StatusA Status-A-red = background-color:red
{11}Style StatusA Status-A-red = background-color:green

This seems to get evaluated "top-down", i.e. the value of "Type" in the first row in the list sets the handling of StatusA and the background-color, the second row for the third and so on. Unfortunately, this really only depends on the order of the rows on the screen - if I sort the list differently, I get a different result.

I am also quite certain that List conditions = 1 has no effect whatsover on List display - which is what I was hoping for.

Hence, I'd like to repeat my question: Is there any way to hide columns in List view (short of editing the conf file...) - and if so, how?

Regards,

Thomas

Hi Stefan,

Is it possible to derive the time in a 'date/time' attribute from the Elog server?
We would like all our entries in GMT/UTC time and unfortunately as the time is currently derived from the client machines there are often entry descrepancies if the regional settings are not set correctly.

The '$entry time' variable can be used but seems to put a 1970 date in the field so bears no relevancy to an 'Event' time?

I'm also having issues with conditional entries in the Find page. If a conditional statement is used to hide attributes or change displayed attributes in the entry page then the attribute that is used in the conditional statement is not permanently selectable in the 'Find' page. It is available as a choice but as soon as selected the conditional action removes it? Is it possible to make conditional options/actions in the 'Find' page optional?

Hope that makes a little sense?

Many thanks

Dear Stefan,

Thanks for your reply.

I started running elog in February and it never failed. Then it started failing regularly towards the end of September. There were no system changes until then, except the daily automatic Yum updates (SLC4). Then I upgraded to the latest version (tar ball of 2.7.5). Then yesterday it crashed again. I saw that it crashed around the time when a user was doing something - inputting new data. I can monitor when it crashes and correlate it with user activity. But it is not easy to reproduce since I don't know exactly what the user is typing.

It would be necessary to record the user input forms and then replay them against a known server state. But that is not so easy.

I will think about doing something else - maybe running inside a debugger as you suggest.

Soren

Dear Soren,

sorry for the trouble, but it's very hard to diagnose this remotely. This forum here runs fine for many months, so in principle Elog should be stable (at least the current version 2.7.5). If you have an older version, please upgrade. If you have a way to reproduce the problem reliably, you can send me your config file and explain step-by-step how you make Elog crash. Then I can try to reproduce it here. Otherwise the only chance I see is to run elog from inside the debugger, and once it crashes record the stack trace and send it to me. If you don't know how to use the gnu debugger, I'm sure you find someone at CERN who knows. 

Best regards,

   Stefan