| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68794
|
Sat May 5 11:22:50 2018 |
 | Chris Rasmussen | chris.rasmussen@cern.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
| Attachment 1: sequencer_event_100098.PNG
|
|
| Attachment 2: sequencer_event_10009X.PNG
|
|
|
68795
|
Sat May 5 20:55:23 2018 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | Well, in my example the ID link worked just fine.
There could be a string length limitation, but it could be as well the way you are creating the ID that is the source of the problem: I would need the part of your elogd.cfg that defines how you format your ID in order to try to reproduce your problem.
Cheers, Andreas
| Chris Rasmussen wrote: |
|
Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
|
68796
|
Mon May 7 14:24:18 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | As Andreas said we have to reproduce the problem. What is special in your case is the elog:SequencerEvents/XXXXX. This is non-standard and must be created through your configuration of elog or by an external script. I just guess that you have something like
Preset ID = elog:SequencerEvents/#####
which causes elog to preset the ID with the above string. Can it be that you just put five hashmarks in the preset?
Stefan
| Chris Rasmussen wrote: |
|
Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
|
68797
|
Mon May 7 18:10:20 2018 |
| Chris Rasmussen | chris.rasmussen@cern.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | ah yes, that was a helpful clue. Our elogd.cfg file led me to a .js file which redefines the ID to the elog:SequencerEvents/XXXXX format and it indeed had a silly hard coded length of that string.
Since I am pretty sure this is our code, I think it is safe to say that this is not a bug in the elog
| Andreas Luedeke wrote: |
|
Well, in my example the ID link worked just fine.
There could be a string length limitation, but it could be as well the way you are creating the ID that is the source of the problem: I would need the part of your elogd.cfg that defines how you format your ID in order to try to reproduce your problem.
Cheers, Andreas
| Chris Rasmussen wrote: |
|
Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
|
|
68798
|
Tue May 8 16:17:28 2018 |
 | Joseph McKenna | joseph.mckenna@cern.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | Thank you all for your kind responses. Please consider this thread resolved: no bug in elog
| Chris Rasmussen wrote: |
|
ah yes, that was a helpful clue. Our elogd.cfg file led me to a .js file which redefines the ID to the elog:SequencerEvents/XXXXX format and it indeed had a silly hard coded length of that string.
Since I am pretty sure this is our code, I think it is safe to say that this is not a bug in the elog
| Andreas Luedeke wrote: |
|
Well, in my example the ID link worked just fine.
There could be a string length limitation, but it could be as well the way you are creating the ID that is the source of the problem: I would need the part of your elogd.cfg that defines how you format your ID in order to try to reproduce your problem.
Cheers, Andreas
| Chris Rasmussen wrote: |
|
Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
|
|
|
66450
|
Mon Jul 20 10:30:44 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | 2.7.6 | Re: Elog Crashes |
| lance wrote: |
|
Stefan,
Our log is crashing on a regular basis and I have been unable to identify the reason. Now the if the log crashes that is not a major problem however when you try to stop the daemon from the services it fails to stop. This means that the daemon cannot be restarted. The only way then is to start killing processes. This is not something I want none experienced guys to do.
Looking at the processes is look like the elogd.exe is still running and doesn’t die when you try to stop the daemon service.
I checked the times it was crashing with events in the elog logfiles but there was nothing actually happening at these times. It seems something is causing it to just hang.
I have attached the eventlog files for you if you have any ideas I would appreciate them.
I have not run the log in verbose mode as I have thus far been unable to redirect the output of the screen in order to see what is happening. If you have any tips on how to redirect the output I would save the file for off line analysis. Our log is used 24/7 therefore it is critical that it be kept running so if I was to run it with the –v option the guys would have to restart it and I would lose the data.
Any help is much appreciated
Regards,
Lance
|
Using the Windows event log won't help much. I guess in your case elogd is driven into some kind of endless loop (does the CPU go to 100%???). There are only two possibilities to tackle this:
1) You find a way to reliably reproduce this problem, tell me how to do this. When I can reproduce it here, I can fix it easily.
2) You do debugging yourself. Under Linux this is simple, since you have debuggers on most systems. Under Windows however, you first have to install the Visual C++ development environment. I believe there is a free version (Express?) which you can use. You then run elogd under the debugger, and when it hangs you investigate where. This needs some basic knowledge about C++ development and I'm not sure if you have this, but maybe you can find someone around you who does. |
|
67049
|
Fri Apr 15 08:49:26 2011 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.9.0 | Re: Elog 2.9.0 buffer overflow crash bug ubuntu linux | > When running openvas (a nessus fork) against elog 2.9.0 I provoked the following crash:
>
> Apr 9 17:32:06 unixland elogd[1300]: POST / HTTP/1.0#015#012Host: unixland.home
> #015#012Content-Length: -800#015#012#015#012XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Apr 9 17:32:06 unixland kernel: [664894.491242] elogd[1300]: segfault at b7713d
> 2e ip 080b6956 sp bf8d5ea0 error 4 in elogd[8048000+96000]
>
> openvas reports that it was testing for CVE-2002-1212 when the crash occurred.
>
> Startup info:
>
> Apr 9 19:35:54 unixland elogd[21584]: elogd 2.9.0 built Apr 9 2011, 17:49:08
> Apr 9 19:35:54 unixland elogd[21584]: revision 2411
>
> -- rouilj
I haven't tried openvas, but added a check for the negative content-length you have in the request
above in SVN revision 2413. Can you try if it still crashes?
- Stefan |
|
254
|
Thu Mar 20 21:07:09 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | | | Re: Elog 2.3.3, problems of 2.3.2 only partly solved | > After upgrading from 2.3.1 to 2.3.3, elog is not able to load any resources
> as stylesheets, images or passwordfiles.
>
> Cannot open file /usr/local/elogdata/logbooks/djeks/password!
If you installed from the RPM, elogd runs under the user "elog". If you have
installed a previous version under a different user, it might be that elogd
does not have read or write access to it. A
"chown -R elog.elog /usr/local/elogdata"
might help.
- Stefan |
|