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.

Most mail delivery systems have a maximum size for attachments. In the past, if an elog attachment was larger than this size, the email server refused to accept this email and no notification is sent. Now one can specify the maximum allowed email attachment size with

Max email attachment size = <n>

where <n> is the number of bytes. If an email attachment is larger than <n>, the attachment is not sent with the email notification, but rather replaced by a link to the elog server for that attachment. By clicking on the link in the email notification, a browser will then open and download the large attachment. For each each elog installation, the admin has to figure out what the maximum attachment size of their SMTP server is, and then put this number into the elogd.cfg setting  above. For most installations, the default of 10 MB will just work fine.

Stefan

Hi,

I have been using elog for a few years and it is a wonderfull software and has been one that I can't go without. So thank you very much for making it. 

After about a year, I upgraded to the latest version. I noticed that it causes the system to crash. It doesn't seem to happen that often. 

I have installed this on 2 machines, one Windows 10 and one on Windows 7. Over the last week I got one BSOD on each OS. 

The elogs have different configs and logbooks. One is a simple elog that doesn't have any attachments or anything funky. Just straight text.

Please see attached a screenshot of the Memory.DMP which has happned seconds after an schedule restarted the elog service on my PC. 

I will keep monitoring and see if will happen again. But I thought I log it here anyway.

Thanks.

Cheers.

Ales.

The dump does not help me much. I need to reporduce the problem in a controlled environment.

Stefan

Hello!

First of all, thank you for this great piece of software! For now it seems to perfectly cover our need to log very basic events, there was a setting for everything we wanted to set.

However we have one problem and that is the saving of the letter "č" (Slovenian) into the log files. That is unicode character U+010C and U+010CD https://unicode-table.com/en/010C/. When writing to the log file it is replaced with "&#268;" and "&#269;". Is there a known fix for this?

Thank you and best regards,

Matej

I see the same problem exists on this board as well. Actuall it appears only the attribute fields are affected. The č character was incorrectly written to the log file from the subject field above, but correctly from the body text below.

Actually unicode characters are converted by your browser into HTML code (such as &#268) where 268 decimal = 10C hex. elog just writes to file what it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is necessary since log files are ASCII and thus encode one charecter in one byte. Your Slovenian characters require two bytes in unicode, so some kind of "special" encoding is necessary.

Stefan

Hello Stefan,

thank you for the reply. The explanation does not solve my problem though. 

1) Could you elaborate, why the body text field CORRECTLY writes the character while the attribute fields write and display the HTML code?

2) If I understand you correctly the problem also contradicts your statement: "When an existing elog entry gets shown by the browser, the code is translated back to the character." and is visible in this very post. The subject field writes and displays it incorrectly, while the body text writes and displays it perfectly OK. See: Č č ?

3) We do not use any scripts. If we were to use a script to replace the HTML code with the actual character, the attribute fields would still display È instead of Č. Also, I have no idea how to write such a script. :)

Thanks,

Matej

In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put

allow html = 1

into your config file.

Stefan

This tag does not change the behaviour, but I have noticed that I only have the problem in Chrome and Firefox but not in Internet explorer.

Matej

To conclude this topic, we sadly can't use the characters č and Č propperly in the application. I have marked the problems in the screenshots below:

red square - the user name is changed immediately after saving. It is also written into the log file in the attribute "Lovec" preset as $long_name. This cannot be displayed correctly even when using HTML and the text tag.

orange sqare - This appears in translated menus and in the attribute "Preža" where the options are listed. The character is written correctly in the translation and the log file, but is displayed incorrectly as È and è.

pink square - After using the script on this attribute "Opis" to insert the html text tag the field correctly displays the characters. The minor problem remains when exporting this to a csv file where the html text tag remains.

I have no idea what effort it would take to change the ANSI background of the application to UNICODE and I can't really expect you to do this. On the other hand most modern applications go through this step eventually, mostly because of the Chinese and the Russian markets.

Thanks again for the otherwise great product, I guess we'll have to start using letters c and C instead. Best reagards,
Matej

I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.

Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current POC log resides.  

Easiest is to install the Cywgin environment (www.cygwin.com) and there select the C compiler package which installs also "make".

Phew, made it, sort of. Had to copy the contents of the mxml folder from an older version, the folder was empty in this git. I also had to change the SSL to 0 and then it compiled without errors plus I had to copy the cygwin1.dll to the folder to make the service run.

So yes, I can confirm that manually inputting the Č in the attribute field now works correctly. Excellent! This solves the pink problem then. Any similar solutions for the red and orange ones?

Thanks,
Matej

Pink problem: Yes the CSV export preserves the html tags, but what to do. CSV files are plain text with 8 bit characters. Unicode characgers have to be represented with more than one byte. So either HTML encoding or some special escape sequence encoding. If you like the second better than the first, I'm sure you find some conversion program on the internet.

Orange problem: No clue how C is converted to E. Maybe depends on the encoding of your browser? There is a elog option "charset = xxx" with which you can play.

Special characters in use names should now work in the current version.

That's great, Stefan, it works indeed. I tried fiddling around a bit with different charsets but haven't been succesful yet. I'll play around some more.

Hi,

I recently upgraded elog from 2.7 to 3.1 and have a hard time to insert images inline. The attachements work just fine. I am certain it is something silly, but I cannot figure it out.

1. In edit mode, I click the image icon
2. A pop-up "Image Propertied" shows with two tabs "Image Info" and "Upload" (selected)
3. Click on Browse button and select an image
4. Now
   • if I click OK, I get an error "Image source URL is missing".
   • if I go to "Image Info" tab - what URL am I supposed to enter, 68757/<1> ?

I found an old thread elog:68410 (from 2016) but could not find a solution that would work for me. Where does "Preview attachments" option should be inserted? In the global section?

Hopefully there's a simple explanation for this

Piotr

Before you click OK on your point 4, click on "Send to Server".

Stefan

I did just that. The image was properly send to the server (it appears in the attachement list). However clicking OK still produces "Image source URL is missing".

What is the URL that refers to an attachment? I've tried 68759/<1> and 68759/1 and even elog:1234/<1> (where 1234).

Got it to work.  Removed "Preview attachments = 1" from the global section.

Thanks for your help.

Piotr

Hi!

Tryed windows an linux version. On booth the "Register new User" dialog is not displaying a password line.
so what password is used for the new user? Further the user can't change his password, because he didn't know the old one.

And if an admin user trys to change the password of an other user, a error is displyed that the old password of the admin user is
wrong and nothing happens with the password of the non-admin user.

elog console (admin user awrzkrz changes the password of testuser1):

GET /demo/?cmd=Config&config=TestUser1&cfgpage=1&admin=1&cfg_user=TestUser1&active=1&new_user_name=TestUser1&new_full_name=TEST+User&new_user_email=test%40heaven.org&cmd=Change+password HTTP/1.1
Returned 1032 bytes
GET /demo/?config=TestUser1&newpwd=test1234&newpwd2=test1234 HTTP/1.1
Returned 20 bytes
GET /demo/?cmd=Change%20password&config=awrzkrz&fail=1 HTTP/1.1
Returned 1215 bytes
 

Thanks for help!

Have you configures user-level access via

password file = anyfile.pwd

Can your elogd server write to that file?

If yes, can you please post your config file?

Stefan

Hi Stefan,

thanks for the quick reply.

Yes, i've configured user-level access. Here is my cfg:

[global]
port = 9191
Usr = abc
Grp = abc
SMTP host = mail.xy.at
Protect Selection page =  1
Password file = elog_pw.xml
Logfile = elog_log.txt
Logging level = 2
Admin user = User1, Admin
Self register = 2
Restrict edit = 1
Allow password change = 1

[demo]
Theme = default
Authentication = Kerberos
Comment = General Linux Tips & Tricks
Attributes = Author, Type, Category, Subject
Options Type = Routine, Software Installation, Problem Fixed, Configuration, Oth                                                          er
Options Category = General, Hardware, Software, Network, Other
Extendable Options = Category
Required Attributes = Author, Type
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type

And, yes, the password file is r7w accessible for the elogd:
[root@localhost logbooks]# cat elog_pw.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- created by MXML on Tue Feb 27 14:54:52 2018 -->
<list>
  <user>
    <name>Admin</name>
    <password encoding="SHA256">3c2QQ0KjIU1OLtB29cl8Fplc2WN7X89bnoEjaR7tWu.</password>
    <full_name>Admin</full_name>
    <last_logout>0</last_logout>
    <last_activity>0</last_activity>
    <email>admin@hell.org</email>
    <inactive>0</inactive>
    <email_notify/>
  </user>
  <user>
    <name>TestUser1</name>
    <password encoding="SHA256">3c2QQ0KjIU1OLtB29cl8Fplc2WN7X89bnoEjaR7tWu.</password>
    <full_name>User1</full_name>
    <last_logout>0</last_logout>
    <last_activity>0</last_activity>
    <email>test@heaven.org</email>
    <inactive>0</inactive>
    <email_notify/>
  </user>
</list>
 

br, Rainer

password file = anyfile.pwd

I'm afraid that there is something wrong because each user will be written with the same (hashed) password to the local password file,
irrespective of the given password within the "new User dialog".

So for instance, every user in my password file lokks like this:

    <name>TestUser1</name>
    <password encoding="SHA256">3c2QQ0KjIU1OLtB29cl8Fplc2WN7X89bnoEjaR7tWu.</password>
    <full_name>TEST User</full_name>
    <last_logout>0</last_logout>
    <last_activity>0</last_activity>
    <email>test@heaven.org</email>
    <inactive>0</inactive>
    <email_notify/>
  </user>
 

"password encoding" has got the same value for each user after creating them with their own passwords....

That's the main issue i have, because i don't know this password and can't set a known one....

frustrating....

any help would be appreciated

password file = anyfile.pwd

What happens when you don't use Kerberos authentication?

password file = anyfile.pwd

Yeah!!

That did it! I remove the line "Kerberos authentication" and now it works!

Thanks!

password file = anyfile.pwd