Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 516 of 808  Not logged in ELOG logo
icon5.gif   Anonymous vs user posts, posted by Chris Warner on Fri Mar 31 22:14:38 2006 
If I have a logbook that will let both registered users Anonymous users post. I would like the author attribute to default to the value in $long_name but if the post is Anonymous display a default text string "Anonymous". Is it possible to do this?
    icon2.gif   Re: Anonymous vs user posts, posted by Stefan Ritt on Sat Apr 1 15:30:32 2006 

Chris Warner wrote:
If I have a logbook that will let both registered users Anonymous users post. I would like the author attribute to default to the value in $long_name but if the post is Anonymous display a default text string "Anonymous". Is it possible to do this?


I added that functionality into the intermediate release 2.6.1-4 which you can download from the ELOG site.
icon4.gif   Response is very slow with beta3, posted by PJ Meyer on Thu Jul 28 04:27:30 2005 
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.
    icon2.gif   Re: Response is very slow with beta3, posted by Emiliano Gabrielli on Wed Aug 3 13:01:17 2005 

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 ?? ..
    icon2.gif   Re: Response is very slow with beta3, posted by Stefan Ritt on Wed Aug 3 22:44:43 2005 

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?
    icon2.gif   Re: Response is very slow with beta3, posted by Emiliano Gabrielli on Thu Aug 4 11:19:53 2005 

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 ...
icon5.gif   Display Attribute no longer works in Beta 5?, posted by Ulrich Trüssel on Fri Oct 7 08:53:00 2005 Display_Attribute_with_260-b2.jpgDisplay_Attribute_with_260-b5.jpgelogd.cfg
Just changed from Beta 2 to Beta 5:

I'm using Display Attribut = [elog:$logbook/$message id] as a reference link for other entries (ex.: Display Referenz = [elog:$logbook/$message id]). also see the attached elogd.cfg file.

With Beta 2 (not testet with Beta 3 or 4!) this worked very well -> see attached Display Attribute with 260-b2.jpg file.

With Beta 5 is seems no longer to work -> see attached Display Attribute with 260-b5.jpg file.

ANy ideee what's wrong in my elogd.cfg??? Thanks!
    icon2.gif   Re: Display Attribute no longer works in Beta 5?, posted by Stefan Ritt on Mon Oct 10 13:57:20 2005 

Ulrich Trüssel wrote:
I'm using Display Attribut = [elog:$logbook/$message id] as a reference link for other entries (ex.: Display Referenz = [elog:$logbook/$message id]). also see the attached elogd.cfg file.


This option has been changed on July 25th from "Display <attribute>" to "Change <attribute>" which is a more appropriate expression. The documentation has also been updated.
ELOG V3.1.5-3fb85fa6