elogd hangs, posted by Alan Grant on Fri Aug 18 05:28:16 2017
|
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). |
Re: elogd hangs, posted by Stefan Ritt on Fri Aug 18 08:59:08 2017
|
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).
|
|
|
Re: elogd hangs, posted by David Pilgram on Fri Aug 18 12:40:21 2017
|
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).
|
|
|
|
Re: elogd hangs, posted by Alan Grant on Fri Aug 18 15:10:15 2017
|
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).
|
|
|
|
|
Re: elogd hangs, posted by Alan Grant on Fri Aug 18 15:15:57 2017
|
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).
|
|
|
|
|
Re: elogd hangs, posted by David Pilgram on Fri Aug 18 21:16:12 2017
|
Hi Alan,
Just to be clear (and for others) if any entry is a reply to a previous one, such as this one is to yours, then there will be "Reply to" and "In reply to" fields in the entry as found in the yymmdda.log files. They are automatically generated as part of the elog program's internal structure, but are only there when there is a reply - so a new entry on a new topic does not have either field (at all) until there is a reply to that entry, when the fields start to appear in the log file.
David.
| Alan Grant wrote: |
|
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).
|
|
|
|
|
|
Re: elogd hangs, posted by Alan Grant on Fri Aug 18 14:49:42 2017
|
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).
|
|
|
|
Re: elogd hangs, posted by Stefan Ritt on Fri Aug 18 16:26:14 2017
|
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).
|
|
|
|
|
Re: elogd hangs, posted by Alan Grant on Fri Aug 18 16:39:21 2017
|
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).
|
|
|
|
|
|
Enable LDAP on Windows, posted by Gerardo Abihaggle on Sun Jul 30 07:39:23 2017
|
Hi All,
I'm running ELOG on a Windows machine and I would like to use LDAP for Authentication, however to achive this I need to compile elog. Any advice on how to do that on Windows?
Thanks! |
|
Conditional attribute activation, posted by Devrim Esenturk on Fri Jul 21 15:24:33 2017
|
I have a stock database running latest elog version on windows. I am reserving some products which not been sent to customer mistakenly and using value "reserved" for it. But I need another attribute for comment reason of reserving but this attribute must be activated when reserved value selected. Is this possible? I didn't see any option for this at admin guide.
Thank you |
|
Re: Conditional attribute activation, posted by Andreas Luedeke on Mon Jul 24 14:33:51 2017
|
Yes, this is possible by using "Conditional Attributes". Have a look at the ELOG syntax help: https://midas.psi.ch/elog/config.html#conditional
To hide attributes on edit, you can use "Show Attributes Edit = ..." for the conditions; and you only list the comment reason for the case where the value of the other attribute has the value "reserved".
If you don't get it to work, then just post your logbook config with some comments on what you want to achieve.
Cheers, Andreas
| Devrim Esenturk wrote: |
|
I have a stock database running latest elog version on windows. I am reserving some products which not been sent to customer mistakenly and using value "reserved" for it. But I need another attribute for comment reason of reserving but this attribute must be activated when reserved value selected. Is this possible? I didn't see any option for this at admin guide.
Thank you
|
|
|
Password Protect Delete, posted by Michael Cianci on Thu Jul 20 18:38:20 2017
|
We don't use a password file but would like to password protect (Admin only) the DELETE function in the MENU Thank You |
|
Re: Password Protect Delete, posted by Andreas Luedeke on Fri Jul 21 08:54:03 2017
|
You can allow guests to create entries, but only registered users (Admins) to delete (or edit) entries:
Menu commands = List, New, Edit, Reply, Delete, Find, Config, Logout, Help
Guest menu commands = List, New, Reply, Find, Login, Help
See https://midas.psi.ch/elog/config.html#general for details.
| Michael Cianci wrote: |
|
We don't use a password file but would like to password protect (Admin only) the DELETE function in the MENU Thank You
|
|
|
Email Notification (Not) Initiated by elog Client Utility, posted by Phil Rubin on Fri Jul 14 19:26:06 2017
|
Our configuration sends out e-mail notifications based on a hierarchy of attributes, and works fine with WEB submissions, but not with client utility submissions (no notifications are sent; the log doesn't show it even trying to send any: 14-Jul-2017 18:36:01 [rubinp@nn.nn.nn.nn] {Notebook} NEW entry #0) . Since notification is the default (suppression requires -x), I presume there is something wrong with the way we're going about this. Can you see what it is? Could it be the parentheses in the type Problem(s), which have to be sent at the shell in the client command as Type=Problem\(s\)?
[global]
.
Suppress Email to users = 1
.
[Notebook]
.
Attributes = Author, Type, Category, Subject
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = ... TDAQ ...
.
{1} Email Category TDAQ =
{2} Email Category TDAQ = user1@aa.bb, user2@cc.dd,...
{3} Email Category TDAQ =
.
Use Email Subject = Elog Notice: $subject
Command: /usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text" |
|
Re: Email Notification (Not) Initiated by elog Client Utility, posted by Andreas Luedeke on Wed Jul 19 08:50:16 2017
|
Yes, parentheses in field content might be difficult to pass from a shell command. You did not even mention which Linux shell you are using and you did not show the actual elog command. Maybe you want to add that information?
| Phil Rubin wrote: |
|
Our configuration sends out e-mail notifications based on a hierarchy of attributes, and works fine with WEB submissions, but not with client utility submissions (no notifications are sent; the log doesn't show it even trying to send any: 14-Jul-2017 18:36:01 [rubinp@nn.nn.nn.nn] {Notebook} NEW entry #0) . Since notification is the default (suppression requires -x), I presume there is something wrong with the way we're going about this. Can you see what it is? Could it be the parentheses in the type Problem(s), which have to be sent at the shell in the client command as Type=Problem\(s\)?
[global]
.
Suppress Email to users = 1
.
[Notebook]
.
Attributes = Author, Type, Category, Subject
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = ... TDAQ ...
.
{1} Email Category TDAQ =
{2} Email Category TDAQ = user1@aa.bb, user2@cc.dd,...
{3} Email Category TDAQ =
.
Use Email Subject = Elog Notice: $subject
Command: /usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
|
|
|
Re: Email Notification (Not) Initiated by elog Client Utility, posted by Phil Rubin on Wed Jul 19 08:59:52 2017
|
Thank you for responding.
I thought I provided the command at the end of the note:
/usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
This results in an entry being appropriately logged in Notebook with the correct author, type, category, subject, and text. The only problem is that, when the type is such that email notification should be sent to the list associated with category, it is not sent.
For the record, I reconfigured elogd.conf so that parentheses are no longer there, but this made no difference, so this isn't the problem.
Sorry for forgetting these details: bash shell; linus version 2.6.32-696.el6.x86_64
| Andreas Luedeke wrote: |
|
Yes, parentheses in field content might be difficult to pass from a shell command. You did not even mention which Linux shell you are using and you did not show the actual elog command. Maybe you want to add that information?
| Phil Rubin wrote: |
|
Our configuration sends out e-mail notifications based on a hierarchy of attributes, and works fine with WEB submissions, but not with client utility submissions (no notifications are sent; the log doesn't show it even trying to send any: 14-Jul-2017 18:36:01 [rubinp@nn.nn.nn.nn] {Notebook} NEW entry #0) . Since notification is the default (suppression requires -x), I presume there is something wrong with the way we're going about this. Can you see what it is? Could it be the parentheses in the type Problem(s), which have to be sent at the shell in the client command as Type=Problem\(s\)?
[global]
.
Suppress Email to users = 1
.
[Notebook]
.
Attributes = Author, Type, Category, Subject
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = ... TDAQ ...
.
{1} Email Category TDAQ =
{2} Email Category TDAQ = user1@aa.bb, user2@cc.dd,...
{3} Email Category TDAQ =
.
Use Email Subject = Elog Notice: $subject
Command: /usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
|
|
|
|
Re: Email Notification (Not) Initiated by elog Client Utility, posted by Andreas Luedeke on Wed Jul 19 10:14:44 2017
|
If that is your command then it is obvious why no email is send:
you do set "Type=Type", but only for "Type=Problem(s)" and "Category=TDAQ" you would send an email.
Instead of writing "-h host" you should as well define the actual hostname, like "-h midas.psi.ch", likewise for all other parameter.
| Phil Rubin wrote: |
|
Thank you for responding.
I thought I provided the command at the end of the note:
/usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
This results in an entry being appropriately logged in Notebook with the correct author, type, category, subject, and text. The only problem is that, when the type is such that email notification should be sent to the list associated with category, it is not sent.
For the record, I reconfigured elogd.conf so that parentheses are no longer there, but this made no difference, so this isn't the problem.
Sorry for forgetting these details: bash shell; linus version 2.6.32-696.el6.x86_64
| Andreas Luedeke wrote: |
|
Yes, parentheses in field content might be difficult to pass from a shell command. You did not even mention which Linux shell you are using and you did not show the actual elog command. Maybe you want to add that information?
| Phil Rubin wrote: |
|
Our configuration sends out e-mail notifications based on a hierarchy of attributes, and works fine with WEB submissions, but not with client utility submissions (no notifications are sent; the log doesn't show it even trying to send any: 14-Jul-2017 18:36:01 [rubinp@nn.nn.nn.nn] {Notebook} NEW entry #0) . Since notification is the default (suppression requires -x), I presume there is something wrong with the way we're going about this. Can you see what it is? Could it be the parentheses in the type Problem(s), which have to be sent at the shell in the client command as Type=Problem\(s\)?
[global]
.
Suppress Email to users = 1
.
[Notebook]
.
Attributes = Author, Type, Category, Subject
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = ... TDAQ ...
.
{1} Email Category TDAQ =
{2} Email Category TDAQ = user1@aa.bb, user2@cc.dd,...
{3} Email Category TDAQ =
.
Use Email Subject = Elog Notice: $subject
Command: /usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
|
|
|
|
|
Re: Email Notification (Not) Initiated by elog Client Utility, posted by Phil Rubin on Wed Jul 19 10:25:08 2017
|
I didn't realize you required every detail of the command, since the entry is being logged, but here is an example (only the user information is blanked out):
/usr/local/bin/elog -h vmna62s1 -p 8080 -l NA62Logbook -u xxxx xxxx -a Author=Rubin -a Type=Problem\(s\) -a Category=Elog -a Subject="Client Initiated E-mail Notification" "Tests"
From elogd.cfg:
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = Access, Beam, CHANTI, CHOD, Computer/Network, DCS/DSS, Elog,
GTK, HASC, IRC/SAC, KTAG, LAV, LKr, MUV, NewCHOD, Online Monitor, RICH, Run, Run
Control, Shift, STRAW, TDAQ
{1} Email Category Elog =
{2} Email Category Elog = Philip.Rubin@cern.ch
{3} Email Category Elog =
The TDAQ-category command that is misbehaving is essentially identical:
/usr/local/bin/elog -h vmna62s1 -p 8080 -l NA62Logbook -u xxxx xxxx -a Author="Run Control" -a Type=Problem\(s\) -a Category=TDAQ -a Subject="Board Reload" "KTAG4"
| Andreas Luedeke wrote: |
|
If that is your command then it is obvious why no email is send:
you do set "Type=Type", but only for "Type=Problem(s)" and "Category=TDAQ" you would send an email.
Instead of writing "-h host" you should as well define the actual hostname, like "-h midas.psi.ch", likewise for all other parameter.
| Phil Rubin wrote: |
|
Thank you for responding.
I thought I provided the command at the end of the note:
/usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
This results in an entry being appropriately logged in Notebook with the correct author, type, category, subject, and text. The only problem is that, when the type is such that email notification should be sent to the list associated with category, it is not sent.
For the record, I reconfigured elogd.conf so that parentheses are no longer there, but this made no difference, so this isn't the problem.
Sorry for forgetting these details: bash shell; linus version 2.6.32-696.el6.x86_64
| Andreas Luedeke wrote: |
|
Yes, parentheses in field content might be difficult to pass from a shell command. You did not even mention which Linux shell you are using and you did not show the actual elog command. Maybe you want to add that information?
| Phil Rubin wrote: |
|
Our configuration sends out e-mail notifications based on a hierarchy of attributes, and works fine with WEB submissions, but not with client utility submissions (no notifications are sent; the log doesn't show it even trying to send any: 14-Jul-2017 18:36:01 [rubinp@nn.nn.nn.nn] {Notebook} NEW entry #0) . Since notification is the default (suppression requires -x), I presume there is something wrong with the way we're going about this. Can you see what it is? Could it be the parentheses in the type Problem(s), which have to be sent at the shell in the client command as Type=Problem\(s\)?
[global]
.
Suppress Email to users = 1
.
[Notebook]
.
Attributes = Author, Type, Category, Subject
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = ... TDAQ ...
.
{1} Email Category TDAQ =
{2} Email Category TDAQ = user1@aa.bb, user2@cc.dd,...
{3} Email Category TDAQ =
.
Use Email Subject = Elog Notice: $subject
Command: /usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
|
|
|
|
|
|
Re: Email Notification (Not) Initiated by elog Client Utility, posted by Andreas Luedeke on Wed Jul 19 13:37:33 2017
|
Okay, I can confirm that this does not work. It is likely related to the disclaimer in the ELOG documentation (https://midas.psi.ch/elog/config.html#conditional)
Conditional attributes are usually only used for change items in the entry form.
I guess that the "Email" command never worked with conditional attributes. I use the "Email" command and conditional attributes extensively, but I've never tried before to use "Email" in a condition.
I've tested the functionality with the following minimal configuration for the latest ELOG version 3.1.3-aded4ae :
Attributes = A, B
Options A = X{1}, Y{2}
Options B = N, M
{2} Email B M = andreas.luedeke@psi.ch
The following elog command creates the desired entry, but does not send out an email. Creating the identical entry via the web form does initiate the email.
elog -u <user> <password> -h <host> -p 80 -l <logbook> -a "A=Y" -a "B=M" -n 1 "entry by elog cmd"
Thank you Phil for pointing out the problem.
Cheers, Andreas
| Phil Rubin wrote: |
|
I didn't realize you required every detail of the command, since the entry is being logged, but here is an example (only the user information is blanked out):
/usr/local/bin/elog -h vmna62s1 -p 8080 -l NA62Logbook -u xxxx xxxx -a Author=Rubin -a Type=Problem\(s\) -a Category=Elog -a Subject="Client Initiated E-mail Notification" "Tests"
From elogd.cfg:
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = Access, Beam, CHANTI, CHOD, Computer/Network, DCS/DSS, Elog,
GTK, HASC, IRC/SAC, KTAG, LAV, LKr, MUV, NewCHOD, Online Monitor, RICH, Run, Run
Control, Shift, STRAW, TDAQ
{1} Email Category Elog =
{2} Email Category Elog = Philip.Rubin@cern.ch
{3} Email Category Elog =
The TDAQ-category command that is misbehaving is essentially identical:
/usr/local/bin/elog -h vmna62s1 -p 8080 -l NA62Logbook -u xxxx xxxx -a Author="Run Control" -a Type=Problem\(s\) -a Category=TDAQ -a Subject="Board Reload" "KTAG4"
| Andreas Luedeke wrote: |
|
If that is your command then it is obvious why no email is send:
you do set "Type=Type", but only for "Type=Problem(s)" and "Category=TDAQ" you would send an email.
Instead of writing "-h host" you should as well define the actual hostname, like "-h midas.psi.ch", likewise for all other parameter.
| Phil Rubin wrote: |
|
Thank you for responding.
I thought I provided the command at the end of the note:
/usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
This results in an entry being appropriately logged in Notebook with the correct author, type, category, subject, and text. The only problem is that, when the type is such that email notification should be sent to the list associated with category, it is not sent.
For the record, I reconfigured elogd.conf so that parentheses are no longer there, but this made no difference, so this isn't the problem.
Sorry for forgetting these details: bash shell; linus version 2.6.32-696.el6.x86_64
| Andreas Luedeke wrote: |
|
Yes, parentheses in field content might be difficult to pass from a shell command. You did not even mention which Linux shell you are using and you did not show the actual elog command. Maybe you want to add that information?
| Phil Rubin wrote: |
|
Our configuration sends out e-mail notifications based on a hierarchy of attributes, and works fine with WEB submissions, but not with client utility submissions (no notifications are sent; the log doesn't show it even trying to send any: 14-Jul-2017 18:36:01 [rubinp@nn.nn.nn.nn] {Notebook} NEW entry #0) . Since notification is the default (suppression requires -x), I presume there is something wrong with the way we're going about this. Can you see what it is? Could it be the parentheses in the type Problem(s), which have to be sent at the shell in the client command as Type=Problem\(s\)?
[global]
.
Suppress Email to users = 1
.
[Notebook]
.
Attributes = Author, Type, Category, Subject
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = ... TDAQ ...
.
{1} Email Category TDAQ =
{2} Email Category TDAQ = user1@aa.bb, user2@cc.dd,...
{3} Email Category TDAQ =
.
Use Email Subject = Elog Notice: $subject
Command: /usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"
|
|
|
|
|
|
Weird behaviour of category filter, posted by Daniel Sajdyk on Fri Jul 14 13:18:30 2017 
|
Hello.
Today I noticed that when I use category filter in the top, right of Elog I got different results, that depends on that if I select Category and Subcategory or just Subcategory option.
What I mean.
- When I select category Software (in Polish "Oprogramowanie") and subcategory Antywirus I got results that have only this subcategory specified (screenshot Category-Software_and_Subcategory-Antywirus.png)
- But when I write by myself Antywirus (which is subcategory of Software) in subcategory option (category leave as default), then I got results that have this, and other subcategories specified (screenshot Subcategory-Antivirus.png).
In my opinion in first example Elog shoud also displays all entries that have Antywirus subcategory specified. Not only when it is the only subcategory.
Sorry, for my english, but I have hope that you can understand what I mean.
Daniel |
|
Re: Weird behaviour of category filter, posted by Andreas Luedeke on Wed Jul 19 08:58:51 2017
|
Hi Daniel,
I agree: it should. And it does in my case; it works perfectly fine for my logbooks. Maybe you should have a closer look for special characters in you configuration? Otherwise I don't know why it does not work for you.
If you haven't figured it out already you would need to send a working snippet of your logbook configuration together with a minimal collection of entries that are filtered wrongly.
Cheers, Andreas
| Daniel Sajdyk wrote: |
|
Hello.
Today I noticed that when I use category filter in the top, right of Elog I got different results, that depends on that if I select Category and Subcategory or just Subcategory option.
What I mean.
- When I select category Software (in Polish "Oprogramowanie") and subcategory Antywirus I got results that have only this subcategory specified (screenshot Category-Software_and_Subcategory-Antywirus.png)
- But when I write by myself Antywirus (which is subcategory of Software) in subcategory option (category leave as default), then I got results that have this, and other subcategories specified (screenshot Subcategory-Antivirus.png).
In my opinion in first example Elog shoud also displays all entries that have Antywirus subcategory specified. Not only when it is the only subcategory.
Sorry, for my english, but I have hope that you can understand what I mean.
Daniel
|
|
|
Virus in latest elog?, posted by Daniel Sajdyk on Fri Jul 14 13:11:48 2017
|
Hello.
Today I wanted to download latest elog version, and got information from Eset Endpoint Antyvirus, that downloaded file has trojan horse "Generic.GQWFFXB".
It this false positive alarm?
Daniel
|
|
Re: Virus in latest elog?, posted by Stefan Ritt on Fri Jul 14 16:58:48 2017
|
Hi Daniel,
you're the first one reporting about this virus. We have different virus checkers here at our lab and none of them triggered. So I guess it is a false alarm.
Best,
Stefan
| Daniel Sajdyk wrote: |
|
Hello.
Today I wanted to download latest elog version, and got information from Eset Endpoint Antyvirus, that downloaded file has trojan horse "Generic.GQWFFXB".
It this false positive alarm?
Daniel
|
|
|
Server dropping SSL connection while uploading large files, posted by Erkcan Ozcan on Sat Jun 10 07:05:24 2017
|
Hi,
I am having trouble with uploading large (>0.5MB) files to elog. We click on upload and in a couple of seconds, the webbrowser complains that the server has dropped the connection.
Following the suggestions I found on these forums (https://midas.psi.ch/elogs/Forum/66753), I increased the timeout.tv_sec to 30 in three locations in elogd.c, but this did not help.
The problem is present in my old elog installation (from ~2 years ago), as well as the latest git snapshot from bitbucket that I cloned on June 10, 2017.
PS: Upload seems to work for non-secure configuration. It still takes a while to load, but it completes. However we prefer to use secure connections ( SSL = 1 ).
PS: Using nmap I looked at the latency to the relevant port, it can be as high as 0.5sec, but most often it is shorter.
Cheers,
e. |
|
Re: Server dropping SSL connection while uploading large files, posted by Erkcan Ozcan on Wed Jun 28 19:37:10 2017
|
Hi,
Could someone at least suggest how I could debug this problem myself? If I know where to start, perhaps I can fix it myself and contribute to the software.
Best,
e.
| Erkcan Ozcan wrote: |
|
Hi,
I am having trouble with uploading large (>0.5MB) files to elog. We click on upload and in a couple of seconds, the webbrowser complains that the server has dropped the connection.
Following the suggestions I found on these forums (https://midas.psi.ch/elogs/Forum/66753), I increased the timeout.tv_sec to 30 in three locations in elogd.c, but this did not help.
The problem is present in my old elog installation (from ~2 years ago), as well as the latest git snapshot from bitbucket that I cloned on June 10, 2017.
PS: Upload seems to work for non-secure configuration. It still takes a while to load, but it completes. However we prefer to use secure connections ( SSL = 1 ).
PS: Using nmap I looked at the latency to the relevant port, it can be as high as 0.5sec, but most often it is shorter.
Cheers,
e.
|
|
|
Re: Server dropping SSL connection while uploading large files, posted by Andreas Warburton on Wed Jun 28 22:20:38 2017
|
Hi Erkcan,
I observed similar behaviours when attempting to do SSL uploads and mirroring over a WAN (see some of my recent posts). Having not received any responses/help, and no time to try debugging the source myself, I've changed the way I use ELOG such that my attachment uploads are always local (on my Mac laptop, where I do most of my ELOGging) and I have switched off the mirroring, choosing instead to do my own rsync backup to a central linux server on which I have running a read-only ELOG executable. This configuration is both relatively secure and stable, and it matches my use case well. More generally, however, it is unfortunate that this SSL and mirroring functionality isn't truly there for all users, even though the documentation touts it to be so.
Best regards,
Andreas W.
| Erkcan Ozcan wrote: |
|
Hi,
Could someone at least suggest how I could debug this problem myself? If I know where to start, perhaps I can fix it myself and contribute to the software.
Best,
e.
| Erkcan Ozcan wrote: |
|
Hi,
I am having trouble with uploading large (>0.5MB) files to elog. We click on upload and in a couple of seconds, the webbrowser complains that the server has dropped the connection.
Following the suggestions I found on these forums (https://midas.psi.ch/elogs/Forum/66753), I increased the timeout.tv_sec to 30 in three locations in elogd.c, but this did not help.
The problem is present in my old elog installation (from ~2 years ago), as well as the latest git snapshot from bitbucket that I cloned on June 10, 2017.
PS: Upload seems to work for non-secure configuration. It still takes a while to load, but it completes. However we prefer to use secure connections ( SSL = 1 ).
PS: Using nmap I looked at the latency to the relevant port, it can be as high as 0.5sec, but most often it is shorter.
Cheers,
e.
|
|
|
|
Re: Server dropping SSL connection while uploading large files, posted by Stefan Ritt on Thu Jun 29 08:36:03 2017
|
One possibility is to run elog in non-SSL mode and put an Apache server in front of it. The Apache server can then do the SSL communication, and forward all requests to elog in plain text (non-SSL). This has been proven to work with large attachments, actually that's the way I use it.
I didn't find time to debug the SSL problem. If anybody is interested in doing so, the relevant code is in function server_loop() around line 30015 (SSL_read()).
Stefan
| Erkcan Ozcan wrote: |
|
Hi,
Could someone at least suggest how I could debug this problem myself? If I know where to start, perhaps I can fix it myself and contribute to the software.
Best,
e.
| Erkcan Ozcan wrote: |
|
Hi,
I am having trouble with uploading large (>0.5MB) files to elog. We click on upload and in a couple of seconds, the webbrowser complains that the server has dropped the connection.
Following the suggestions I found on these forums (https://midas.psi.ch/elogs/Forum/66753), I increased the timeout.tv_sec to 30 in three locations in elogd.c, but this did not help.
The problem is present in my old elog installation (from ~2 years ago), as well as the latest git snapshot from bitbucket that I cloned on June 10, 2017.
PS: Upload seems to work for non-secure configuration. It still takes a while to load, but it completes. However we prefer to use secure connections ( SSL = 1 ).
PS: Using nmap I looked at the latency to the relevant port, it can be as high as 0.5sec, but most often it is shorter.
Cheers,
e.
|
|
|
|