Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 794 of 804  Not logged in ELOG logo
ID Date Icon Authordown Author Email Category OS ELOG Version Subject
  68657   Fri Aug 18 15:10:15 2017 Reply Alan Grantagrant@winnipeg.caQuestionWindows3.1.2Re: elogd hangs

Yes I think I recall the incident in the Forum you're talking about from previous searches I've done on hanging however so far I haven't used Reply To's in this elog instance. Nevertheless, you explained it very well and it's good points to keep in mind should I ever use them, thank you David.

David Pilgram wrote:

I have experience of elog hanging (under linux).  I'll describe my situation, although it may not apply to you.  I still use elog 2.9.2 but I am unaware of this issue ever being resolved although I have mentioned it in the past.  (Possibly because I'm one of the few who has this situation).  I certainly recall other person had this as the problem, and my reply on this forum solved their problem.  The cause is the following:

1.  A thread with a large number of replies - something over 40 I think.

2.  This long thread is deleted from the first entry.  This will crash elog,

3.  Once restarted, the later entries of the deleted thread (which survived the deletion attempt when elog crashed) are accessed.  This will cause elog to go into an endless loop and hang.  Until I learnt better, I had to reboot the computer.  Under linux kill -9 (process) does the job, but kill (process) does not.

The problem lays with the first entry that survived the attempt at deletion.  It has an "In reply to" line in the entry in the yymmdda.log file, referring to an entry that has now been deleted.  Manually editing the yymmdda.log file to remove that line does the trick, and then the surviving entries can be accessed and deleted.

A good work-around is that if you are about to delete a long thread is to delete it in sections, starting at the end.  It is useful to note the entry number or some other way to find it again after the last section is deleted, as of course it will now be back in with the even older entries.  Or have two tabs on your browser accessing the same thread.

If you want to move the long thread to another logbook, to avoid the problem, Copy the thread, and then do the deletion in stages.  Moving a long thread does the same computer crash/computer hang, although the Copying part is done fine, the deletion part is the problem.

You don't have to have a large number of replies to an entry to cause the hang in controlled conditions.  Just edit the yymmdda.log file of a new entry adding in a "In reply to" line referring to an earlier entry number that does not exist is enough to cause the problem when you try and access the thread.

If this is the cause of your issue, the problem is to find the orphan thread that is causing the hang, especially after all this time.  Also, you may have more than one orphan thread.  Even though I am aware of the problem, I do occasionally find orphan threads in my logbooks.  In my case I use the ticketing system, and searching by ticket number will find an orphan thread without hanging the computer, but if you then click on any entry found - hang.

 

There is a related issue, which I think I have now resolved.  If the entry in the "Reply to" field in the yymmdda.log file does not exist, that is a later entry (not earlier, as above), elog will cause a duplicate entry, always in bold, with entry no 0 to appear in the listings.  This entry is an artifact that appears in the listings, not a real entry in a yymmdda.log file.  Again, finding the rogue entry is the tricky bit.

Stefan Ritt wrote:

I have to figure out where elog hangs. I guess it must be some kind of endless loop, triggered by some corrupt data in one of the elog entries. Under linux this is fairly simple (just run elogd under the gdb debugger, wait until it hangs, then press ctrl-c and enter "where" to see a full stack dump where elogd is currently executing). Under Windows this is more difficult, since you need Visual C++ from Microsoft to do the debugging. One thing you can do however without VC is to check if the CPU time is consumed to 100% by elogd, indicating an endless loop.

Stefan

Alan Grant wrote:

I have a very long standing problem with elog over the last few versions where almost daily the service will hang. Cannot even Restart elogd, that just hangs. Clients experience Page not Found. I can only get the service reinitialized by rebooting the VM machine. I have Elog verbose logging On plus a number of external triage monitors running but nothing is yielding clues beyond the precise time the hang occurs. Aside from providing the Config and log files what else can I provide for you to assist, and what other triage measures can you suggest I try? FYI, there can be up to 20 users at one time doing searches (not updates), and I've trimmed the depth of log files that can be searched so that the CPU/service doesn't bog down but that hasn't helped either. Inserts happen in the background using the elog client app (about 2 or 3 inserts per batch at sporadic times).

 

 

 

  68658   Fri Aug 18 15:15:57 2017 Reply Alan Grantagrant@winnipeg.caQuestionWindows3.1.2Re: elogd hangs

Yes I think I recall the incident in the Forum you're talking about from previous searches I've done on hanging however so far I haven't used Reply To's in this elog instance. Nevertheless, you explained it very well and it's good points to keep in mind should I ever use them, thank you David.

David Pilgram wrote:

I have experience of elog hanging (under linux).  I'll describe my situation, although it may not apply to you.  I still use elog 2.9.2 but I am unaware of this issue ever being resolved although I have mentioned it in the past.  (Possibly because I'm one of the few who has this situation).  I certainly recall other person had this as the problem, and my reply on this forum solved their problem.  The cause is the following:

1.  A thread with a large number of replies - something over 40 I think.

2.  This long thread is deleted from the first entry.  This will crash elog,

3.  Once restarted, the later entries of the deleted thread (which survived the deletion attempt when elog crashed) are accessed.  This will cause elog to go into an endless loop and hang.  Until I learnt better, I had to reboot the computer.  Under linux kill -9 (process) does the job, but kill (process) does not.

The problem lays with the first entry that survived the attempt at deletion.  It has an "In reply to" line in the entry in the yymmdda.log file, referring to an entry that has now been deleted.  Manually editing the yymmdda.log file to remove that line does the trick, and then the surviving entries can be accessed and deleted.

A good work-around is that if you are about to delete a long thread is to delete it in sections, starting at the end.  It is useful to note the entry number or some other way to find it again after the last section is deleted, as of course it will now be back in with the even older entries.  Or have two tabs on your browser accessing the same thread.

If you want to move the long thread to another logbook, to avoid the problem, Copy the thread, and then do the deletion in stages.  Moving a long thread does the same computer crash/computer hang, although the Copying part is done fine, the deletion part is the problem.

You don't have to have a large number of replies to an entry to cause the hang in controlled conditions.  Just edit the yymmdda.log file of a new entry adding in a "In reply to" line referring to an earlier entry number that does not exist is enough to cause the problem when you try and access the thread.

If this is the cause of your issue, the problem is to find the orphan thread that is causing the hang, especially after all this time.  Also, you may have more than one orphan thread.  Even though I am aware of the problem, I do occasionally find orphan threads in my logbooks.  In my case I use the ticketing system, and searching by ticket number will find an orphan thread without hanging the computer, but if you then click on any entry found - hang.

 

There is a related issue, which I think I have now resolved.  If the entry in the "Reply to" field in the yymmdda.log file does not exist, that is a later entry (not earlier, as above), elog will cause a duplicate entry, always in bold, with entry no 0 to appear in the listings.  This entry is an artifact that appears in the listings, not a real entry in a yymmdda.log file.  Again, finding the rogue entry is the tricky bit.

Stefan Ritt wrote:

I have to figure out where elog hangs. I guess it must be some kind of endless loop, triggered by some corrupt data in one of the elog entries. Under linux this is fairly simple (just run elogd under the gdb debugger, wait until it hangs, then press ctrl-c and enter "where" to see a full stack dump where elogd is currently executing). Under Windows this is more difficult, since you need Visual C++ from Microsoft to do the debugging. One thing you can do however without VC is to check if the CPU time is consumed to 100% by elogd, indicating an endless loop.

Stefan

Alan Grant wrote:

I have a very long standing problem with elog over the last few versions where almost daily the service will hang. Cannot even Restart elogd, that just hangs. Clients experience Page not Found. I can only get the service reinitialized by rebooting the VM machine. I have Elog verbose logging On plus a number of external triage monitors running but nothing is yielding clues beyond the precise time the hang occurs. Aside from providing the Config and log files what else can I provide for you to assist, and what other triage measures can you suggest I try? FYI, there can be up to 20 users at one time doing searches (not updates), and I've trimmed the depth of log files that can be searched so that the CPU/service doesn't bog down but that hasn't helped either. Inserts happen in the background using the elog client app (about 2 or 3 inserts per batch at sporadic times).

 

 

 

  68660   Fri Aug 18 16:39:21 2017 Reply Alan Grantagrant@winnipeg.caQuestionWindows3.1.2Re: elogd hangs

Okay I will just try the debugger approach first and then take it from there. Thanks Stefan.

Stefan Ritt wrote:

Well, having the config and data files only help if I can reproduce the hanging. If if you give me your files and a step-by-step instruction on how to reproduce the hanging, I can give it a try. But if it happens randomly after a while, it will be very hard for me to reproduce and fix it without the exaclty same user access pattern which of course I don't have.

Alan Grant wrote:

I could begin debugging with C++. In the interim, if you think it will help, I can also provide you with my Config and log files, and the section of redacted data encompassing the time of the hang - just let me know. Regarding CPU usage, I have noted that in the past and have never seen very high CPU usage during an Elog hang. The VM itself remains responsive.

Stefan Ritt wrote:

I have to figure out where elog hangs. I guess it must be some kind of endless loop, triggered by some corrupt data in one of the elog entries. Under linux this is fairly simple (just run elogd under the gdb debugger, wait until it hangs, then press ctrl-c and enter "where" to see a full stack dump where elogd is currently executing). Under Windows this is more difficult, since you need Visual C++ from Microsoft to do the debugging. One thing you can do however without VC is to check if the CPU time is consumed to 100% by elogd, indicating an endless loop.

Stefan

Alan Grant wrote:

I have a very long standing problem with elog over the last few versions where almost daily the service will hang. Cannot even Restart elogd, that just hangs. Clients experience Page not Found. I can only get the service reinitialized by rebooting the VM machine. I have Elog verbose logging On plus a number of external triage monitors running but nothing is yielding clues beyond the precise time the hang occurs. Aside from providing the Config and log files what else can I provide for you to assist, and what other triage measures can you suggest I try? FYI, there can be up to 20 users at one time doing searches (not updates), and I've trimmed the depth of log files that can be searched so that the CPU/service doesn't bog down but that hasn't helped either. Inserts happen in the background using the elog client app (about 2 or 3 inserts per batch at sporadic times).

 

 

 

 

  68686   Fri Sep 15 00:56:38 2017 Question Alan Grantagrant@winnipeg.caQuestionLinux3.1.2Elog System Requirements

In response to an elog-hang issue I've been having on the Windows platform, I am building a new Unbuntu 14 TLS VM machine to host the identical configuration so that I can more easily debug when the hang happens again. I don't mind beefing up the hardware resources to either eliminiate that as a factor or resolve the problem. I'll have a higher end CPU to deal with 20 to 50 clients doing searches through the data (since the elog configuration currently does not provide a setting to limit how far back it can search with Quick Filters - pretty please add this basic setting!), but the main question I have now is what is a good amount of memory to add to the VM? I suspect even with 30 concurrent searches going CPU power will have more impact than memory in the case of elog. Can someone please confirm my suspicion and also recommend a suitable amount of memory I should install? My data volume is about 25 MB, all textual (no attachmemts), and the number of daily files goes back about 5 years. Any other tips for the build is very welcome.

  68717   Mon Jan 15 16:46:58 2018 Entry Alan Grantagrant@winnipeg.caRequestWindows3.1.2Drop down order

Can you please make a change to have the Quick Filter ComboBox controls reference the field type for ordering purposes?

For example, if attribute Lot Number is Type Numeric then the ComboBox should be listed in numerical order instead of alphanumeric (eg: 1,2,3,11,21 vs 1,11,2,21,3).

Best Regards.

  68892   Wed Feb 20 21:56:32 2019 Reply Alan Grantagrant@winnipeg.caQuestionWindows3.14Re: Unwanted double entries eg. double clicking submit button

I'm also happy to see this change implemented as we've had to deal with the same issue at times as well. Will this change be incorporated into the latest version (314-2, aka elog-latest.exe), or will there be a new version release (that is not in Changelog yet)? If so, can you give any ETA on this new code availability?

Also I noticed that the Elog Home page still says "Current version is: 3.1.2". I assume that only means it hasn't been updated, not that it means it's the current STABLE version and subsequent releases are beta -- please correct me if I'm wrong. I just want to make sure I understand how the versions and releases work.

Endless thanks for this product and all your work Stefan.

Stefan Ritt wrote:

I just committed some code which disables the "Submit" button after the first click and replaces the text with "Please wait...". So double submits should not be possible any more.

David Pilgram wrote:

I too have this as an occasional issue, although in my case due to a dodgy pointer.  I too manually delete the entries.

Interestingly, it gives double entries - and thus the start of a branch - even in logbooks were branches are not allowed.

Finn Junker wrote:

I'm having a minor issue that were getting double entries due to the user is using the "submit" button more than once.

I seems like when there is a lag either on the machine or on the network it is possible to tap the "submit" button more than once resulting i a double or triple entry containing the same text and a almost identical timestamp.

Is there a way to aviod this?, my "solution" so far has been to select the entries and manually delete them. I'm using Elog version 3.14

Kind Regards Finn

 

 

 

  68893   Wed Feb 20 22:24:05 2019 Idea Alan Grantagrant@winnipeg.caRequestWindows3.1.2New feature request for Options list

Is it possible to include an option in the next release to have the Options list reference a text file of attributes rather than explicity listing the attributes in the Config file directly?

This would make it much easier to maintain a particular list that is referenced in several log books.

  68922   Thu Mar 28 21:55:14 2019 Question Alan Grantagrant@winnipeg.caQuestionWindows3.1.2Hiding Logbook tabs

I know you can restrict access to logbooks on per user basis but can anyone tell me if it is possible to HIDE certain logbook tabs/groups on per user basis (ie, so they would just see logbooks they are authorized to see)?

ELOG V3.1.5-3fb85fa6