We have been using elog on Windows 10 for a long time. Today, after a Windows update, the elogd service started crashing (error 1067, unexpected termination). It ran fine just before the Windows update (which took > 1 hour, so it was a major one). Uninstalling and re-installing did not help, including replacing my elogd.cfg with the default. Installing on another PC (that also has this update) fails in the same way. I have a good backup of my logbook.

Any suggestions?

Hi all,

I try to implement a shift check list for our facility. The attributes called "a1, a2, b1, b2 etc" are used in original shiftcheck.html， However, we would like to use "1.1, 1.2, 2.1, 2.2 etc". So I try to change the name of checkbox in shiftcheck.html and the attributes in elogd.cfg file to "1.1, 1.2, 2.1, 2.2 etc". The elog web page can display the attributes like "1.1, 1.2...", but the checked value of "on" seems not working. And I have used wirshark to monitor the http package, the request message seems correct, but the service response seems can't deal with attributes like "1.1, 1.2...", so is there a way to work around?

An attribute is similar to a variable. Do you know any programming language that allows to start a variable with a digit? I don't.

The solution is very obvious: start your attributes with a letter.

Cheers, Andreas

That's true. Thanks for your explanation.

Cheers, Xuan

We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000... 

68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...

Is this a know bug we can find a fix for? We are using:  elogd 2.9.2 built Jul 14 2015, 18:58:06 revision

I am not sure I understand your bug report.

I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?

Cheers, Andreas

Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.

You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX  The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message

Well, in my example the ID link worked just fine.

There could be a string length limitation, but it could be as well the way you are creating the ID that is the source of the problem: I would need the part of your elogd.cfg that defines how you format your ID in order to try to reproduce your problem.

Cheers, Andreas

ah yes, that was a helpful clue. Our elogd.cfg file led me to a .js file which redefines the ID to the elog:SequencerEvents/XXXXX format and it indeed had a silly hard coded length of that string.

Since I am pretty sure this is our code, I think it is safe to say that this is not a bug in the elog

Thank you all for your kind responses. Please consider this thread resolved: no bug in elog

As Andreas said we have to reproduce the problem. What is special in your case is the elog:SequencerEvents/XXXXX. This is non-standard and must be created through your configuration of elog or by an external script. I just guess that you have something like

Preset ID = elog:SequencerEvents/#####

which causes elog to preset the ID with the above string. Can it be that you just put five hashmarks in the preset?

Stefan

Hi,
I´m new in ELOG,
Can u explain me how i config the Mailing?
in my Configuration i do have not the ability to set an Email Host/Server. or i didn´t find it....

I have to use ELOG as ticket system, is it possible to send an email automatically after expiration of a period?

SMTP host = ...

as written in the documentation!

Automatic email after expiration is not possible.

many thanks

SMTP host = ...

MUST be set in the [global] section of your configuration - it will likely not work when you try to set it for a specific logbook.

I don't see how ELOG can send an automatic email after a date expired.

Hi All,
I just installed elog latest version. I can see that my chkeditor (HTML encoding) is pretty simplified with respect to the version i can see there. Why this ? For example, it does not offer the possibility to upload images.

Could you please help me ?

Thank you
Andrea

Can you post a picture here?

If i try to upload an image here, i got the error "Image Source URL Is Missing"...

can you help me further ?
Best regards,
Andrea

Yes, I can help with that: you've tried to put the picture into the text body. Try to make it a normal attachment, that'll work always.

Hello!  The CDMS collaboration is using e-Log as one of it's issue tracking systems.  In the last few months, I have noticed a problem when either creating or editing entries from my usual Safari browser (currently 11.1 on MacOSX 10.13.4):  The [Submit] button triggers a spinning beach ball, with no connection to our e-Log server, and after several minutes, Safari complains the the page had to be reloaded, discarding all of my edits, uploads, whatever.  This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.

Now, I am also seeing the same problems with Firefox, but at the "occasional" level.  The difference is that Firefox produces some diagnostic information, which is why I'm posting here.  When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:

Warning: unresponsive script

A script on this page may be busy, or it may have stopped responding.  You can stop the script now, open the script in the debugger, or let the script continue.

Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30

[] Don't ask me again

[Debug script]                       [Stop script]     [Continue]

If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:

16   var in_asend = false;
17
18   function chkform()
19   {
20     if (last_key == 13) {
21       var ret = confirm('Really submit this entry?');
22       if (!ret) {
23         last_key = 0;
24         return false;
25       }
26     }
27
28     if (autoSaveTimer != null)
29       clearTimeout(autoSaveTimer);
30     while (in_asend);               <=== This is the stuck line
31     submitted = true;
32     return true;
33   }

I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.

Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve?

I dont' have a solution, but I just wanted to bring more attention to your post. I too am having the same issue with the ELOG system and the Safari browser. I have noticed that ELOG is most stabel and function on the client end from the IE browser. A few weeks ago I also had to switch from using ELOG on the client end from Safari to Firefox.

I'm not 100% sure, but I believe it should work without the 

while (in_asend);

So can you please remove that line (it's in src/elogd.c) and recompile elogd and test it?

Stefan

Thank you for your suggestion, Stefan!  The sysadmin who handles our e-Log server implemented your suggestion earlier today (Saturday).  I have been able to successfully create and modify e-Log entries with Safari since then.  Since the "slow script" issue has been intermittent in the past, I plan to continue testing and monitoring for the next day or so.  Nevertheless, it appears that removing the waiting loop has alleviated my problem.

  -- Mike Kelsey

Followup Sunday 15 Apr (U.S. Pacifiic time):  I think your suggestion has solved my problem.  I've been able to create and modify e-Log entries through our server multiple times over the weekend.  There have been no hangs, timeouts, or lost content.  Thank you very much for your response!

Ok, I removed the code from the official code now. 

A bit background: The "autosave" mechanism in elog saves regularly the current content in a "draft" message, so that the data does not get lost if the browser for example crashes. The saving is done asynchronously via some AJAX call. This call takes some time, since it's a round-trip to the elogd server. If the user hist "submit" during such a save, the second save might be issue before the first one has been finsihed. That's why I had a "while (in_asend)" in the code, where in_asend gets set to true when the AJAX call is started and false when it completes. Now JavaScript is not really multi-threading, so having a loop "while (in_asend)" can actually prevent the AJAX request to complete. This might have been different when I implemented that feature, which is the reason that it worked before. Without that code, it can now happen that a second HTTTP POST is sent before the first request finishes, but I guess this should not be a problem, since both requests come sequentially to the elogd server and are executed one after the other. So in worst case the elog entry text is just saved twice.

Hello, the "drop attachments here..." feature is very useful, especially when I have multiple files. I can drag them all over in one operation, however I have noticed that this feature only works well in the IE browser.

It does not work reliably in Safari/Chrome/Firefox. I have tired in both 3.1.3 and 3.1.2. I also have the same symptom on the Demo log book of this site.

Please advise. Thank you for the continued development of Elog.

-Michael Hibbard

Hello, Sorry if this has been addressed elsewhere, but I could not find info.

I am wanting to submit a new elog entry (that should have been) for a past date, to predate log entrys currently in my system.

I assume I must manually create a new .log file. What ID# should I assign to this entry? Should I sub-increment (i.e 33.1)? I presume the correct thing to to would be to automate ID# increments in all sucessive logs with a script (python).

Please advise.

Thank you,

-Michael Hibbard

Hi Michael,

Elog purists, look away now.

There is an "official" way to do this, which is to have fields for entry date (so can be in the past), but the yymmdda.log file will be of the date and time you make the entry.  This is in the offical documentation.

If you are not bothered by the ID number being out of sequence (and elog does not really mind, although it occasionally throws a hissy fit/throws its toys out of the pram, which a restart sorts out), but you are one who wants the date of the entry in the log file to also be in the past, skipping the entry date fields issue, it's perfectly do-able.  So long as you can access the yymmdda.log files.

What I, and some others, do is to create a new entry now (for ease, the first entry of the day, but that's not critical), then go to the log files, and with an editor open today's file, find the entry, and edit the day, date and if necessary time; I always set the time as post 22:00, as code for an edited late entry.  I also then cut-and-paste the entry into the log file for the day it should have been entered in (creating it if necessary, in linux make sure the permissions are correct, specifically the user).

If you have attachments, and want those also to reflect the date, you'll need to edit the Attachments section of the elog entry headers (format is obvious), and also rename the attachment files in the directory.

I've not tried an ID number being other than an integer, I guess it would not work.  ID numbers not being in sequence with the date doesn't seem to matter.  Messing with ID numbers can have a number of consequences, such as elog running away, burning CPU time etc (looking for a previous entry that does not exist), or rogue listings of a entry ID no./# 0 (looking for a later entry that does not exist).

One caveat; I use Linux, and on elog 2.9.2.  Later elogs and Windows may have a different reaction to what I've written above.

Elog purists can now look again.

Thank you David, Andreas. Very useful forum.

David answered the question already.