We run elog on a server to provide a logbook for our laboratory. We noticed that elog is very slow on loading pages: browser pages spend a lot of time in charging (actually one can speed the procedure refreshing the page but it is quite annoying).

I checked the server load with top and it doesn't show any abnormal CPU or memory usage. Then I ran lsof and I noticed that there are more than 200 entries related to the same elog PID and labelled with CLOSE_WAIT.

My questions are: can the slowness of my logbook be due to the presence of all these CLOSE_WAIT entries (which seems if I understood well wait for a response)? If it's the case, how can I solve this issue?

Thanks

Have you tried to restart the elogd server? The CLOSE_WAIT could be dangling network connections, which were not properly closed by the browser.

An experiment's ELOG installation, using the default theme, names logbooks after its subsystem's acronyms.  One subsystem is referred to as KTAG, but when this name (or its lowercase version) is used for a logbook name, the logbook appears unformatted.  Changing the name, even to K-TAG, works fine.  Nothing close to KTAG appears in elog.css.  Does anyone know why this happens and whether it is possible or worth the while to get around the "problem"?

Dear elog users & developers,

the subject line says it all: when using webserver authentication, how is it possible to restict access of users to any given elog? Only using the apche rules? Admin user and Login user do not seem to be doing anything for me. I am using elog as packaged by debian for buster, using an apache ssl proxy. Thank you for providing this software,

Christian

Dear all,

I figured it out. Current global config is (using kerberos instead)

[global]
port = 8081
Default encoding = 0
SSL = 0
Authentication = Kerberos
URL = https://my_url_here/
interface = 127.0.0.1
Password file = global.pwd
SMTP host = my_mail_host
Logfile = /var/log/elog.log
Logging level = 3
User = elog
Grp = elog

Best,

Christian

It seems that the latest Windows binary still predates this fix. Will there be a new installer soon? Thanks for your support.

Hi,

Ten years later...this problem shows up in my installation behind Apache, affecting only drop-down menu searches.  Test installations with elog serving itself do not show the problem, so I presume it has something to do with Apache configuration, re-routing, etc.  Unfortunately, this thread did not provide any details of the solution.

The problem looks like this:

Type:    %255ERoutine%2524
or, in the url:

https://servername/?Type=%25255ERoutine%252524

Removing 2525 from front and back of the url makes everything work.

The only rewrite entries in the configuration file(s) are:

  ## Rewrite rules
  RewriteEngine On

  #redirect non-SSL traffic to SSL site
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Perhaps there's a rewrite rule that could be added to block the 2525?  Something like:

    RewriteCond %{QUERY_STRING} 2525
    RewriteRule .* - [F,L]

I don't have a lot of experience configuring Apache, so any suggestions would be welcome.

Thanks.

Phil

Good day all ,

does Elog has a paid version that is not open soureced 

regards

William Vasio