Display edit time, posted by Devrim Esenturk on Wed Nov 24 08:12:17 2021
|
Hi
I have a large logbook to keep office demo equipments listed. So editing entries are very often, I would like to see last editing time on my entry as entry time shown as each entry. Is there any way to do this? I checked all attributes and commands but couldn't find any.
King regard
Devrim |
Re: Display edit time, posted by Stefan Ritt on Wed Nov 24 08:38:33 2021
|
Creat an attribute "last edit" and set it to the last edit time. Something like this:
Attributes = ...., Last edit
Preset Last edit = $date
Preset on edit Last edit = $date
Locked attributes = Last edit
Devrim Esenturk wrote: |
Hi
I have a large logbook to keep office demo equipments listed. So editing entries are very often, I would like to see last editing time on my entry as entry time shown as each entry. Is there any way to do this? I checked all attributes and commands but couldn't find any.
King regard
Devrim
|
|
Body of new messages not getting saved when submitted, posted by Harry Martin on Sun Nov 21 23:20:15 2021
|
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
bind9-host:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
ckeditor:amd64 (4.5.7+dfsg-2, 4.5.7+dfsg-2+deb9u1)
cron:amd64 (3.0pl1-128+deb9u1, 3.0pl1-128+deb9u2)
dnsutils:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
firefox-esr:amd64 (78.14.0esr-1~deb9u1, 78.15.0esr-1~deb9u1)
libapache2-mod-php7.0:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
libavcodec57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavfilter6:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavformat57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavresample3:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavutil55:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libbind9-140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libcups2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
libcupsimage2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
libdns162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libdns-export162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libdw1:amd64 (0.168-1, 0.168-1+deb9u1)
libelf1:amd64 (0.168-1, 0.168-1+deb9u1)
libfaad2:amd64 (2.8.0~cvs20161113-1+deb9u2, 2.8.0~cvs20161113-1+deb9u3)
libicu57:amd64 (57.1-6+deb9u4, 57.1-6+deb9u5)
libisc160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisccc140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisccfg140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisc-export160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libjbig2dec0:amd64 (0.13-4.1, 0.13-4.1+deb9u1)
liblwres141:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libnghttp2-14:amd64 (1.18.1-1+deb9u1, 1.18.1-1+deb9u2)
libntfs-3g871:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
libopencv-core2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
libopencv-imgproc2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
libpostproc54:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libpython3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libpython3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libpython3.5-stdlib:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
libsdl1.2debian:amd64 (1.2.15+dfsg1-4, 1.2.15+dfsg1-4+deb9u1)
libswresample2:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libswscale4:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
ntfs-3g:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
php7.0-cli:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-common:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-curl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-intl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-json:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-mbstring:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-opcache:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-readline:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-xml:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
python3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
python3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
ruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
tzdata:amd64 (2021a-0+deb9u1, 2021a-0+deb9u2)
This is a devuan ascii server only for clients on a local area network. |
Re: Body of new messages not getting saved when submitted, posted by Sebastian Schenk on Sun Nov 21 23:49:42 2021
|
Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 00:44:21 2021
|
Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 19:28:28 2021
|
(disregard my recent post here about missing package -- that wasn't the elog server!)
I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog. It was apparently a security update, so I am not sure it is sensible to downgrade. OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue. But please disabuse me of my ignorance if need be.
Harry Martin wrote: |
Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
|
Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 19:45:08 2021
|
After downgrading ckeditor, my elog installation is working again. Thanks for your help.
Harry Martin wrote: |
(disregard my recent post here about missing package -- that wasn't the elog server!)
I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog. It was apparently a security update, so I am not sure it is sensible to downgrade. OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue. But please disabuse me of my ignorance if need be.
Harry Martin wrote: |
Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
|
|
Restrict edit time = 0 behavior intended?, posted by Chris Körner on Mon Nov 15 11:35:55 2021
|
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately. |
Re: Restrict edit time = 0 behavior intended?, posted by Chris Körner on Mon Nov 15 11:48:25 2021
|
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
Chris Körner wrote: |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
Re: Restrict edit time = 0 behavior intended?, posted by Sebastian Schenk on Mon Nov 15 14:02:42 2021
|
Hi Chris,
my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c
As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.
Best wishes,
Sebastian
Chris Körner wrote: |
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
Chris Körner wrote: |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
|
Re: Restrict edit time = 0 behavior intended?, posted by Chris Körner on Tue Nov 16 15:14:42 2021
|
Hi Sebastian,
thanks for the reply. It is just a bit confusing that these similar settings behave so differently. For me it is no big deal to set the time for every logbook independently instead of [global], but it leaves more room for configuration errors.
Best,
Chris
Sebastian Schenk wrote: |
Hi Chris,
my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c
As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.
Best wishes,
Sebastian
Chris Körner wrote: |
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
Chris Körner wrote: |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
|
|
Shared logbook and elog.cfg file across multiple installations, posted by Anthony on Mon Nov 15 15:41:04 2021
|
Hi,
I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog. Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally. I've tried this using symlinks and shortcuts on windows with no luck. I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.
Any ideas or thoughts on how I can do this (if I can actually do this)? |
Re: Shared logbook and elog.cfg file across multiple installations, posted by Sebastian Schenk on Mon Nov 15 17:40:08 2021
|
Hi Anthony,
the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html
Best wishes,
Sebastian
Anthony wrote: |
Hi,
I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog. Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally. I've tried this using symlinks and shortcuts on windows with no luck. I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.
Any ideas or thoughts on how I can do this (if I can actually do this)?
|
|
Re: Shared logbook and elog.cfg file across multiple installations, posted by Anthony on Tue Nov 16 13:05:05 2021
|
Thank you Sebastian!
I admittidely haven't looked through the page in a while, so I completely missed this feature. This should solve the problem, although in a slightly different implementation than what I was trying for.
Sebastian Schenk wrote: |
Hi Anthony,
the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html
Best wishes,
Sebastian
Anthony wrote: |
Hi,
I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog. Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally. I've tried this using symlinks and shortcuts on windows with no luck. I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.
Any ideas or thoughts on how I can do this (if I can actually do this)?
|
|
|
results of security scan, posted by David Stops on Mon Nov 1 12:52:23 2021
|
Recently central IT scanned our elog server and reported the following "vulnerabilities"
- 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
- 51192 (1) - SSL Certificate Cannot Be Trusted
- 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
- 85582 (1) - Web Application Potentially Vulnerable to Clickjacking
Is there any easy way of preventing these
Thanks and Best Wishes
David |
Re: results of security scan, posted by Stefan Ritt on Tue Nov 2 12:07:46 2021
|
The elgod.c progarm itself is rather weak in SSL, since I just don't have time to catch up with the latest SSL enhancements. The safest you can do is to put an industry-strenth web server like Apache in front of elogd and let that server handle the SSL layer.
Stefan
David Stops wrote: |
Recently central IT scanned our elog server and reported the following "vulnerabilities"
- 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
- 51192 (1) - SSL Certificate Cannot Be Trusted
- 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
- 85582 (1) - Web Application Potentially Vulnerable to Clickjacking
Is there any easy way of preventing these
Thanks and Best Wishes
David
|
|
Re: results of security scan, posted by David Stops on Thu Nov 4 13:48:00 2021
|
Thanks, I'll try that and see what happens
David
Stefan Ritt wrote: |
The elgod.c progarm itself is rather weak in SSL, since I just don't have time to catch up with the latest SSL enhancements. The safest you can do is to put an industry-strenth web server like Apache in front of elogd and let that server handle the SSL layer.
Stefan
David Stops wrote: |
Recently central IT scanned our elog server and reported the following "vulnerabilities"
- 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
- 51192 (1) - SSL Certificate Cannot Be Trusted
- 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
- 85582 (1) - Web Application Potentially Vulnerable to Clickjacking
Is there any easy way of preventing these
Thanks and Best Wishes
David
|
|
|
While mirroring, data fields not preserved, posted by Rob Calkins on Tue Oct 26 01:21:01 2021
|
While running two e-log books that were mirrored, I ended up with the situation of two entries with the same number/id. The mirroring did what it said it would, increment the local logbook entry and grab the entry from the remote logbook. However, when it did, it did not preserve the fields in the log book that are specified in the config file such as "Author", "Priority", "Subject" ect. I ended up with a very minimal log:
|
Too many open files - issue?, posted by Rob Calkins on Fri Oct 15 23:57:38 2021
|
Has anyone had issues with having too many files open? I'll setup my server and let it go but after a while, I end up with a lot of "cannot create socket: Too many open files" errors being reported. I have a sync to another e-log going which I suspect is part of the cause since that e-log server hasn't had this issue. I suspect that there are files being opened, going into some return loop code and then never getting closed. I'm not a C programmer but I see lines like :
fh = open(tmp_filename, O_RDONLY);
if (fh > 0) {
read(fh, result, size - 1);
close(fh);
}
/* remove temporary file */
remove(tmp_filename);
This looks like it opens the file but unless the remove function closes the file, it will remain open even through the file has been deleted. Maybe this isn't the correct behaviour of 'remove' and I am mistaken?
There are also parts like :
fh = open(textfile, O_RDONLY | O_BINARY);
if (fh < 0) {
printf("Message file \"%s\" does not exist.\n", textfile);
return 1;
}
size = (INT) lseek(fh, 0, SEEK_END);
lseek(fh, 0, SEEK_SET);
if (size > (INT) (sizeof(text) - 1)) {
printf("Message file \"%s\" is too long (%zd bytes max).\n", textfile, sizeof(text));
return 1;
}
This looks like for the second error, it will complain that the file is too long, return an error message but not close the file and would leave it open. Is this a reasonable avenue to pursue or am I mis-reading the code? Thanks.
|
Re: Too many open files - issue?, posted by Stefan Ritt on Mon Oct 25 13:34:06 2021
|
The code segements you show are from the command line tool elog.c, not the server elogd.c. The tool is called to submit a new message from the command line. Even if there would be a file not properly closed, it will be closed by the operating system once the program finishes. So no problem of too many open files there.
Rob Calkins wrote: |
Has anyone had issues with having too many files open? I'll setup my server and let it go but after a while, I end up with a lot of "cannot create socket: Too many open files" errors being reported. I have a sync to another e-log going which I suspect is part of the cause since that e-log server hasn't had this issue. I suspect that there are files being opened, going into some return loop code and then never getting closed. I'm not a C programmer but I see lines like :
fh = open(tmp_filename, O_RDONLY);
if (fh > 0) {
read(fh, result, size - 1);
close(fh);
}
/* remove temporary file */
remove(tmp_filename);
This looks like it opens the file but unless the remove function closes the file, it will remain open even through the file has been deleted. Maybe this isn't the correct behaviour of 'remove' and I am mistaken?
There are also parts like :
fh = open(textfile, O_RDONLY | O_BINARY);
if (fh < 0) {
printf("Message file \"%s\" does not exist.\n", textfile);
return 1;
}
size = (INT) lseek(fh, 0, SEEK_END);
lseek(fh, 0, SEEK_SET);
if (size > (INT) (sizeof(text) - 1)) {
printf("Message file \"%s\" is too long (%zd bytes max).\n", textfile, sizeof(text));
return 1;
}
This looks like for the second error, it will complain that the file is too long, return an error message but not close the file and would leave it open. Is this a reasonable avenue to pursue or am I mis-reading the code? Thanks.
|
|
Display last page by default, posted by Yoshio Imai on Fri Oct 28 12:15:33 2005
|
Hi again!
I have one question concerning the logbook configuration. Normally, clicking on "List" takes me to the first page of the list view. Is it possible to configure the logbook so that "List" takes me to the last page instead?
Yoshio |
Re: Display last page by default, posted by Stefan Ritt on Fri Oct 28 12:16:38 2005
|
Yoshio Imai wrote: | Is it possible to configure the logbook so that "List" takes me to the last page instead? |
Reverse sort = 1 |
Re: Display last page by default, posted by Yoshio Imai on Fri Oct 28 12:39:44 2005
|
Stefan Ritt wrote: |
Reverse sort = 1 |
Thanks for the quick reply. Unfortunately, this is not exactly what we need. We would like to see the entries in normal order, but the last of the pages as "start page". Is it possible to configure this?
Yoshio |
Re: Display last page by default, posted by Stefan Ritt on Fri Oct 28 13:05:26 2005
|
Yoshio Imai wrote: | We would like to see the entries in normal order, but the last of the pages as "start page". Is it possible to configure this? |
Start page = 0?cmd=last
Well, I guess this is not what you want either, correct? You would like to see the listing page with ~20 entries. The first one you can access easily via "<logbook>/page1", but the number of the last page varies over time. I would have to add a new functionality like "<lobook>/page_last", which automatically gets converted into the correct page number. I will put this on my wishlist. |
Re: Display last page by default, posted by Yoshio Imai on Fri Oct 28 13:12:46 2005
|
Thanks!
For the moment, I could satisfy the users by setting the start page to the "All" view, but if it can be implemented in a future version, this would come very handy.
Yoshio |
Re: Display last page by default, posted by Stefan Ritt on Fri Oct 28 13:14:19 2005
|
Yoshio Imai wrote: | We would like to see the entries in normal order, but the last of the pages as "start page". Is it possible to configure this? |
What about
Start page = last10
This shows always the last 10 entries. If you want to see more, you can click on the new menu entry "Last 20 entries" etc. |
Re: Display last page by default, posted by Yoshio Imai on Fri Oct 28 13:24:27 2005
|
Stefan Ritt wrote: |
What about
Start page = last10
|
In principle this would be a good starting point, however, we would like to use the "Previous" and "Next" page selectors to browse (and these don't appear when using the "lastNN" statement for the start page). |
Re: Display last page by default, posted by Stefan Ritt on Fri Oct 28 20:36:55 2005
|
Ok, I implemented the last page display per default in revision 1538. If "reverse sort = 0" the last page is shown and if "reverse sort = 1" the first page is shown by default. This way one always sees the page with the latest entries. I hope this accomodates everybody. If not, please complain and I could make it a switch (yet another option ). |
Re: Display last page by default, posted by Yoshio Imai on Mon Oct 31 01:39:52 2005
|
I have installed the new version, and it works just fine. It is also MUCH faster than my intermediate solution.
Quote: |
For the moment, I could satisfy the users by setting the start page to the "All" view
|
Thanks for the work! |
|