Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 625 of 807  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Email Categorydown OS ELOG Version Subject
  1353   Thu Jul 28 01:02:00 2005 Warning John Habermannjohn.habermann@wilderness.org.auBug reportLinux 2.5.9+r16problem with list display attribute
I not sure if this has been found and fixed as I did find something to do with the list display attribute in the forums but wasn't sure if it was the same thing.

There seems to be a bug with the List Display attribute in that it drops the last attribute of the list. So in my example if I want to display the Subject in my list I have to add a dummy attribute after it otherwise the Subject will not be displayed. The comma after Subject is not enough, but all you have to do is to add 1 letter and then you will see the subject in List view. If you don't all I see is the Date and Author fields and then the Text field in my Summary view in the log book.

List Display = Date,Author,Subject,t

I am running elog 2.5.9+r1674-1 on Debian sarge.
  1355   Thu Jul 28 04:27:30 2005 Warning PJ Meyerpjm@pjmeyer.orgBug reportWindows2.60b3Response is very slow with beta3
I finally got 2.60 Beta3 running on my server (explicit statements in cfg for most of the defaults)

Now I'm seeing a veerrry slooooow response time - over 3 minutes to open a logbook vs 10 sec in 2.54
Utilization of CPU runs to 60% on elogd.

Tried slimning down elog.cfg, 'emptying' userlog file (actually renamed so Elog created a new one).

Still 2.60b3 is very slow to respond.

When I rolled back to 2.54 speed was fast again.

Any ideas?

this is on a dual processor Win2000 server with 2 gb memory.

attached is the elog.cfg if that helps.

i'm stumped

7/28 Follow-up testing and trials

When I stopped using a password file - speed was quick and responsive (on test book with no password file speed was good which got me thinking about the password file)
When I added back in the 'old' xml password file - slow response
I created new password file with only one user - slow response (took almost 3 minutes to save new account)

I've attached the password file so you can try it out if yo want....

This has me very stumped.
  1358   Thu Jul 28 15:33:21 2005 Question Chris Howec.j.howe@rl.ac.ukBug reportWindows2.6.0Creating logbook by copying an existing one crashes elog
Hi,

Trying to create a new logbook from an existing one causes elog to crash.

output from DrMingw:
elogd.exe caused an Access Violation at location 00448c6e in module elogd.exe
Writing to location 6e206c65.

Registers:
eax=00240798 ebx=00000020 ecx=6e206c61 edx=00250088 esi=00000000 edi=69726500
eip=00448c6e esp=01c1a1d0 ebp=01c1a1f0 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000297

Call stack:
00448C6E elogd.exe:00448C6E
00445F17 elogd.exe:00445F17

as the service restarts elog the browser then displays:

"Cannot open file elog.pwd: No such file or directory
Please use your browser's back button to go back"

If you try and create a new logbook from scratch (i.e. not a copy) then the browser displays:

"Cannot open file elog.pwd: No such file or directory
Please use your browser's back button to go back"

In both cases the new logbook is created.

any ideas?

Chris
  1366   Wed Aug 3 13:01:17 2005 Reply Emiliano GabrielliAlberT@SuperAlberT.itBug reportLinux | Windows2.60b3Re: Response is very slow with beta3

PJ Meyer wrote:
I finally got 2.60 Beta3 running on my server (explicit statements in cfg for most of the defaults)

Now I'm seeing a veerrry slooooow response time - over 3 minutes to open a logbook vs 10 sec in 2.54
Utilization of CPU runs to 60% on elogd.

Tried slimning down elog.cfg, 'emptying' userlog file (actually renamed so Elog created a new one).

Still 2.60b3 is very slow to respond.

When I rolled back to 2.54 speed was fast again.

Any ideas?

this is on a dual processor Win2000 server with 2 gb memory.

attached is the elog.cfg if that helps.

i'm stumped

7/28 Follow-up testing and trials

When I stopped using a password file - speed was quick and responsive (on test book with no password file speed was good which got me thinking about the password file)
When I added back in the 'old' xml password file - slow response
I created new password file with only one user - slow response (took almost 3 minutes to save new account)

I've attached the password file so you can try it out if yo want....

This has me very stumped.



I can confirm .. it's very very slow for me too:

munmap(0xb7db4000, 4096)                = 0
select(1024, [5], NULL, NULL, {6, 0})   = 1 (in [5], left {5, 996000})
recv(5, "GET /calendar_filter/imgs/window"..., 100000, 0) = 485
open("/usr/share/elog/scripts/calendar_filter/imgs/window_close.gif", O_RDONLY) = 6
close(6)                                = 0
open("/usr/share/elog/scripts/calendar_filter/imgs/window_close.gif", O_RDONLY) = 6
lseek(6, 0, SEEK_END)                   = 648
lseek(6, 0, SEEK_CUR)                   = 648
lseek(6, 0, SEEK_SET)                   = 0
time([1123066183])                      = 1123066183
read(6, "GIF89a\20\0\20\0\306`\0\16\26 \r\27!\16\30!\24 .\25 .I"..., 648) = 648
close(6)                                = 0
send(5, "HTTP/1.1 200 Document follows\r\nS"..., 879, 0) = 879
close(5)                                = 0
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 1 (in [3], left {0, 81000})
accept(3, {sa_family=AF_INET, sin_port=htons(57723), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
time(NULL)                              = 1123066193
socket(PF_FILE, SOCK_STREAM, 0)         = 6
connect(6, {sa_family=AF_FILE, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory)
close(6)  
= 0


for every image elog has to serve one can see something similar to the above ... lot of time lost in selects.. then a lot of data (serving an image I suppose), then a lot of time in select again and again ... untill everything is sent, in a couple of minutes or more Crying


Maybe an issue related to the dns search you introduced in order to guess the correct host name ?? ..
  1367   Wed Aug 3 22:44:43 2005 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux | Windows2.60b3Re: Response is very slow with beta3

Emiliano Gabrielli wrote:
for every image elog has to serve one can see something similar to the above ... lot of time lost in selects.. then a lot of data (serving an image I suppose), then a lot of time in select again and again ... untill everything is sent, in a couple of minutes or more Crying


Maybe an issue related to the dns search you introduced in order to guess the correct host name ?? ..


This is strange to me, since I did not change anything which could slow down the server this much. The dns search your mentioned is only evaluated once on startup of elogd, so it cannot be the cause. The select() statements with Timeouts are normal. If there is no HTTP request (elogd is idling), the select should time out after one second, to be able to check a changed config file for example. If a HTTP request arrives, the select() call is immediately terminated and the request served.

There is however some problem with DNS server which I saw on midas.psi.ch. If the DNS host name resolution is slow due to a slow DNS server, this could slow down elogd considerably significantly, but only occasionally. I saw elogd hanging on midas.psi.ch like once or twice a day for ~30 seconds.

I order to address this problem, I imlemented a global flag "resolve host names = 0|1". The default is "0", which means that elogd does not contact the DNS server, and rather save the raw IP address in log files etc.

Can you check the CVS version and see if it makes any difference?
  1368   Thu Aug 4 11:19:53 2005 Reply Emiliano GabrielliAlberT@SuperAlberT.itBug reportLinux | Windows2.60b3Re: Response is very slow with beta3

Stefan Ritt wrote:

Emiliano Gabrielli wrote:
for every image elog has to serve one can see something similar to the above ... lot of time lost in selects.. then a lot of data (serving an image I suppose), then a lot of time in select again and again ... untill everything is sent, in a couple of minutes or more Crying


Maybe an issue related to the dns search you introduced in order to guess the correct host name ?? ..


This is strange to me, since I did not change anything which could slow down the server this much. The dns search your mentioned is only evaluated once on startup of elogd, so it cannot be the cause. The select() statements with Timeouts are normal. If there is no HTTP request (elogd is idling), the select should time out after one second, to be able to check a changed config file for example. If a HTTP request arrives, the select() call is immediately terminated and the request served.

There is however some problem with DNS server which I saw on midas.psi.ch. If the DNS host name resolution is slow due to a slow DNS server, this could slow down elogd considerably significantly, but only occasionally. I saw elogd hanging on midas.psi.ch like once or twice a day for ~30 seconds.

I order to address this problem, I imlemented a global flag "resolve host names = 0|1". The default is "0", which means that elogd does not contact the DNS server, and rather save the raw IP address in log files etc.

Can you check the CVS version and see if it makes any difference?


No, ok it appears to be a very strange problem related to my JS calendar filter ... I'll change it's state to beta in contributions, but the very strange thing is that it works fine when no stunnel is used ...
  1370   Thu Aug 4 20:32:56 2005 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux 2.5.9+r16Re: problem with list display attribute

John Habermann wrote:
I not sure if this has been found and fixed as I did find something to do with the list display attribute in the forums but wasn't sure if it was the same thing.

There seems to be a bug with the List Display attribute in that it drops the last attribute of the list. So in my example if I want to display the Subject in my list I have to add a dummy attribute after it otherwise the Subject will not be displayed. The comma after Subject is not enough, but all you have to do is to add 1 letter and then you will see the subject in List view. If you don't all I see is the Date and Author fields and then the Text field in my Summary view in the log book.

List Display = Date,Author,Subject,t

I am running elog 2.5.9+r1674-1 on Debian sarge.


I tried with the current 2.6.0-beta3 and it worked fine. Can you send me your full elogd.cfg in order to reproduce the problem?
  1372   Thu Aug 4 21:36:21 2005 Reply Stefan Rittstefan.ritt@psi.chBug reportWindows2.6.0Re: Creating logbook by copying an existing one crashes elog

Chris Howe wrote:
Trying to create a new logbook from an existing one causes elog to crash.


I (hopefully) fixed that bug. The fix will be included in 2.6.0-beta4.
ELOG V3.1.5-3fb85fa6