Date conversion, posted by Martin Neumann on Tue Feb 23 12:12:14 2021
|
Hi,
I am trying to figure out how ELOG works and I have a problem.
I have one datetime attribute, where I want the user to be able to enter the time in ISO8601 format (YYYY-MM-DD HH:MM) instead of the buttons.
How do I manage that this input is converted correctly into the internal format?
I tried adding a hidden locked Attribute called IntDate and use "Subst IntDate = $start" but the result is dates in 1970, even though I have set the Time Format to "%F %H:%M" |
Re: Date conversion, posted by Andreas Luedeke on Tue Feb 23 17:20:39 2021
|
If you define a field as "datetime" then you'll get the standard ELOG input field for datetime. It will be stored as seconds of the epoch (seconds since 1.1.1970).
You can define a field as a default string input, then it is stored as a string. But you can convert that string by a shell scripts into seconds of the epoch. See "subst" command in the documentation of the elog syntax:
Subst <attribute> = <string>
When submitting logbook entries, attribute values can be substituted by some text. This text can contain arbitrary fixed text and following values:
- $<attribute>: The entered value of the attribute itself
- $host: The host name where
elogd is running
- $remote_host: The host name of the host from with the entry was submitted
- $short_name: The login name (if password file is present)
- $long_name: The full name from the password file for the current user
- $user_email: The email address from the password file for the current user
- $logbook: The name of the current logbook
- $date: The current date, formatted via "Date format"
- $utcdate: The current UTC date (GMT) and time, formatted via "Date format"
- $version: The version of the ELOG server in the form x.y.z
- $revision: The Subversion reversion of the ELOG server as an integer number
- $shell(<command>): <command> gets passed to the operating system shell and the result is taken for substitution.
Following example use this feature to add the remote host name to the author:
Subst Author = $author from $remote_host
Following example substitutes an attribute with the contents of a file:
Subst Info = $shell(cat /tmp/filename) (Unix)
Subst Info = $shell(type c:\tmp\filename) (Windows)
A special option are automatically generated tags, which are automatically incremented for each new message. This is achieved by putting #'s into the substitution string, which is used as a placeholder for the incrementing index. Each "#" stands for one digit, thus the statement
Subst Number = XYZ-#####
results in automatically created attributes "Number" of the form
XYZ-00001
XYZ-00002
XYZ-00003
and so on. In addition to the #'s one may specify format specifiers which are passed to the strftime function. This allows to create tags wich contain the current year, month and so on. Once the date part of the attribute changes, the index restarts from one. The statement
Subst Number = XYZ-%Y-%b-###
results in automatically created attributes "Number" of the form
XYZ-2005-Oct-001
XYZ-2005-Oct-002
XYZ-2005-Oct-003
and
XYZ-2005-Nov-001
XYZ-2005-Nov-002
on the next month.
Martin Neumann wrote: |
Hi,
I am trying to figure out how ELOG works and I have a problem.
I have one datetime attribute, where I want the user to be able to enter the time in ISO8601 format (YYYY-MM-DD HH:MM) instead of the buttons.
How do I manage that this input is converted correctly into the internal format?
I tried adding a hidden locked Attribute called IntDate and use "Subst IntDate = $start" but the result is dates in 1970, even though I have set the Time Format to "%F %H:%M"
|
|
Re: Date conversion, posted by Martin Neumann on Wed Feb 24 08:44:42 2021
|
I don't feel comfortable allowing the elog daemon to execute random shell scripts. Is there no other way?
Andreas Luedeke wrote: |
If you define a field as "datetime" then you'll get the standard ELOG input field for datetime. It will be stored as seconds of the epoch (seconds since 1.1.1970).
You can define a field as a default string input, then it is stored as a string. But you can convert that string by a shell scripts into seconds of the epoch. See "subst" command in the documentation of the elog syntax:
|
|
Re: Date conversion, posted by Sebastian Schenk on Tue Mar 2 15:17:56 2021
|
One other way would be to do the conversion on the client-side using javascript.
Overwrite the complete datetime input cell and add an event listener to either onChange of this input or the submit event, to trigger the conversion before submitting, so elog would get the converted time.
In out elog some entries get additional information added in this way.
Martin Neumann wrote: |
I don't feel comfortable allowing the elog daemon to execute random shell scripts. Is there no other way?
Andreas Luedeke wrote: |
If you define a field as "datetime" then you'll get the standard ELOG input field for datetime. It will be stored as seconds of the epoch (seconds since 1.1.1970).
You can define a field as a default string input, then it is stored as a string. But you can convert that string by a shell scripts into seconds of the epoch. See "subst" command in the documentation of the elog syntax:
|
|
|
Re: Date conversion, posted by Stefan Ritt on Wed Mar 10 17:30:23 2021
|
Do you actually need to convert the date into the internal format? Why not keeping simply the full string YYYY-MM-DD HH:MM. If the use is disciplined enough to always use the correct format, there should be no issue. I invented the datetime format to "force" all date/time inputs to have the correct format. If you have a proper YYYY-MM-DD HH:MM format, even sorting (now by string) should work correctly.
Martin Neumann wrote: |
Hi,
I am trying to figure out how ELOG works and I have a problem.
I have one datetime attribute, where I want the user to be able to enter the time in ISO8601 format (YYYY-MM-DD HH:MM) instead of the buttons.
How do I manage that this input is converted correctly into the internal format?
I tried adding a hidden locked Attribute called IntDate and use "Subst IntDate = $start" but the result is dates in 1970, even though I have set the Time Format to "%F %H:%M"
|
|
Last default time bug, posted by Sebastian Schenk on Mon Mar 1 16:02:02 2021
|
Hello all,
I have the issue, that we can't list entries older than 1 year, if "Last default = 31" (or any other number, but they are restricted to 1, 3, 7, 31, 92, 182, 364) is active.
The quick filter displays the option for "-- all entries --" but selecting this only reloads the default time frame (31 days).
A workaroud is to select a different time e.g. 1 day and then modifying the URL to ?last=1000 or so, gives acces to the old entries.
But this is not the intended way to do it.
The Find results are also affected by this. e.g. selecting 1.1.2020 to 1.6.2020 with "Last default = 31" yields 0 results.
The "Show last default" atrtribute for 1, 3, 7, 31, 92, 182, 364 work fine and overwrite the "last default" time in the quick filter.
In the Find page, there will be a "All entries" option at the top of the date selection box, if "Show last default" equals to 1, 3, 7, 31, 92, 182 or 364
(2, Bug: it is empty for "Show last default = 0" and not All entries")
Selecting "All entries" or the empty first value in the Find "show last:" date , will give a Find result with the "Last default" time constraint.
Thus it is not possible to get any entry older then the longst period possible (364 days), if you don't know about the workaround.
Best wishes,
Sebastian
PS: I use a self-compiled version of elog up to the 395e101 commit in the bitbucket repository with pull request #7 (which hasn't been merged for over 1,5 years) and a simple patch for our local LDAP. |
Path disclosure on unfound file, posted by Bruce Bush on Wed May 6 17:35:14 2015
|
Greetings,
Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:
Not Found
The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server
ELOG version 3.1.0
Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?
Thank you,
bb
|
Re: Path disclosure on unfound file, posted by Stefan Ritt on Wed Jun 10 09:12:06 2015
|
What URL did you use? If I try here on this forum I get:

which looks fine to me.
Bruce Bush wrote: |
Greetings,
Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:
Not Found
The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server
ELOG version 3.1.0
Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?
Thank you,
bb
|
|
Re: Path disclosure on unfound file, posted by Travis Unkel on Fri Aug 18 01:02:41 2017
|
I am having the same issue. If you go to midas.psi.ch/elogs/12345.htm you get the path disclosure issue.
Stefan Ritt wrote: |
What URL did you use? If I try here on this forum I get:

which looks fine to me.
Bruce Bush wrote: |
Greetings,
Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:
Not Found
The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server
ELOG version 3.1.0
Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?
Thank you,
bb
|
|
|
Re: Path disclosure on unfound file, posted by prinnydood on Thu Dec 31 18:35:19 2020   
|
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point). |
Re: Path disclosure on unfound file, posted by Stefan Ritt on Fri Jan 8 13:47:14 2021
|
Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a

prinnydood wrote: |
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
Re: Path disclosure on unfound file, posted by Gabriel Lopez on Wed Feb 3 17:28:16 2021
|
Hello, This is coming up as a high vulnerability in our scans. Are there plans to update the rpm for this fix? If so is there an ETA? Any update would be much appreciated. Currently running elog-3.1.4-2
Stefan Ritt wrote: |
Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a

prinnydood wrote: |
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
|
Re: Path disclosure on unfound file, posted by Stefan Ritt on Fri Feb 19 09:59:04 2021
|
I made a new RPM: https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-3.el7.x86_64.rpm
Gabriel Lopez wrote: |
Hello, This is coming up as a high vulnerability in our scans. Are there plans to update the rpm for this fix? If so is there an ETA? Any update would be much appreciated. Currently running elog-3.1.4-2
Stefan Ritt wrote: |
Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a

prinnydood wrote: |
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
|
|
Re: Path disclosure on unfound file, posted by Gabriel Lopez on Fri Feb 19 19:48:11 2021
|
Thank you for your work. Works like a charm!
Stefan Ritt wrote: |
I made a new RPM: https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-3.el7.x86_64.rpm
Gabriel Lopez wrote: |
Hello, This is coming up as a high vulnerability in our scans. Are there plans to update the rpm for this fix? If so is there an ETA? Any update would be much appreciated. Currently running elog-3.1.4-2
Stefan Ritt wrote: |
Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a

prinnydood wrote: |
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
|
|
|
export/archive a logbook, posted by Jacky Li on Thu Feb 18 19:21:57 2021
|
Hi,
I have an elogd server serves many logbooks. May I know what is a good way to export or achive one its logbooks? Thank you.
Jacky |
Re: export/archive a logbook, posted by Stefan Ritt on Fri Feb 19 08:35:53 2021
|
Find -> Export to: CSV (or any other format) -> Search
Jacky Li wrote: |
Hi,
I have an elogd server serves many logbooks. May I know what is a good way to export or achive one its logbooks? Thank you.
Jacky
|
|
elog server go to high CPU and hangs, posted by Stefano Lacaprara on Thu Feb 18 09:14:28 2021
|
Dear expert,
I'm running the latest git version of elog ELOG V3.1.4-395e101a on ubuntu 20.04.2.
I'm experiencing frequent hangs of the elog server: the status is always reported as running, but the web server is not responding.
The only hint I have of something strange is that the elogd process is using a lot of CPU (50-100%), the log do not show anything suspect
as far as I can see.
Has anyone experienced something similar or has any idea how can I start to debug the problem?
Sorry for lack of many information, but I don't know what to look at.
Thanks in advance
Stefano |
Re: elog server go to high CPU and hangs, posted by David Pilgram on Thu Feb 18 12:05:52 2021
|
Dear Stefano,
Try the entry I wrote some time ago elog:68655
David.
> Dear expert,
> I'm running the latest git version of elog ELOG V3.1.4-395e101a on ubuntu 20.04.2.
> I'm experiencing frequent hangs of the elog server: the status is always reported as running, but the web server is not responding.
> The only hint I have of something strange is that the elogd process is using a lot of CPU (50-100%), the log do not show anything suspect
> as far as I can see.
>
> Has anyone experienced something similar or has any idea how can I start to debug the problem?
>
> Sorry for lack of many information, but I don't know what to look at.
>
> Thanks in advance
> Stefano |
Re: elog server go to high CPU and hangs, posted by Stefan Ritt on Thu Feb 18 12:06:12 2021
|
Usually a restart of the elogd server helps. If the problem persists, one of the logbooks might be corrupt. Try to disable one logbook at a time to figure out which one it is. Then
remove that one and set it up freshly.
Stefan |
Different Top Groups or Groups have the same logbook name , posted by MATT TERRON on Tue Feb 2 04:01:21 2021
|
I have built different top groups for different departments. But occasionally these different top groups have the same logbook name, say 'Maintenance Log'. So is there a way I can have the same logbook name under different 'Top Groups', rather than rename these logbooks as 'Department1 Maintenance Log' all the way to 'Department_X Maintenance Log'? |
Re: Different Top Groups or Groups have the same logbook name , posted by Stefan Ritt on Tue Feb 2 07:43:49 2021
|
Unfortunately you have to name these top groups differently, because they are internally used for the database name.
MATT TERRON wrote: |
I have built different top groups for different departments. But occasionally these different top groups have the same logbook name, say 'Maintenance Log'. So is there a way I can have the same logbook name under different 'Top Groups', rather than rename these logbooks as 'Department1 Maintenance Log' all the way to 'Department_X Maintenance Log'?
|
|
Re: Different Top Groups or Groups have the same logbook name , posted by MATT TERRON on Tue Feb 2 08:17:15 2021
|
So both Top Group names and Logbook names should be unique inside one .cfg file, is that correct?
Stefan Ritt wrote: |
Unfortunately you have to name these top groups differently, because they are internally used for the database name.
MATT TERRON wrote: |
I have built different top groups for different departments. But occasionally these different top groups have the same logbook name, say 'Maintenance Log'. So is there a way I can have the same logbook name under different 'Top Groups', rather than rename these logbooks as 'Department1 Maintenance Log' all the way to 'Department_X Maintenance Log'?
|
|
|
Re: Different Top Groups or Groups have the same logbook name , posted by Stefan Ritt on Tue Feb 2 08:25:46 2021
|
That's correct.
Stefan Ritt wrote: |
Unfortunately you have to name these top groups differently, because they are internally used for the database name.
MATT TERRON wrote: |
I have built different top groups for different departments. But occasionally these different top groups have the same logbook name, say 'Maintenance Log'. So is there a way I can have the same logbook name under different 'Top Groups', rather than rename these logbooks as 'Department1 Maintenance Log' all the way to 'Department_X Maintenance Log'?
|
|
|
elog slowness, posted by Giuseppe Cucinotta on Thu Jan 14 11:43:00 2021
|
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 |
Re: elog slowness, posted by Stefan Ritt on Thu Jan 14 14:05:19 2021
|
Have you tried to restart the elogd server? The CLOSE_WAIT could be dangling network connections, which were not properly closed by the browser.
Giuseppe Cucinotta wrote: |
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
|
|
hidden files, posted by Lahreche Abdelmadjid on Sun Jan 10 11:13:31 2021
|
Hello;
Could I make change on program only on the " elogd.cfg" ?
Or is there onother files, because I think there is hidden files ? |
|