Hi Stefano.

This may or may not have anything to do with your specific problem but I notice you have the single word "date" as part of your attribute name and Date is actually a reserved word in Elog. Although your attribute is not exclusively called "date" I have found that even using "date" as an isolated word within an attribute name (eg: Record date vs Record_date) can cause some issues. In my case, it caused a problem with the elog client when trying to update records which was only resolved when I changed the name of the attribute to Date/Time Received from Date and Time Received. Long story short, I avoid using any reserved words as part of attribute names.

Alan.

I haven't found any reporterd issues in the forum similar yet, but it appears there is a bug in Elog when logging into logbooks. If I leave Username and Password null and click Submit the daemon crashes. We've been having this problem off and on and after some verbose logging level 3 I was drawn to these recurring lines in the log:

16-Dec-2016 18:20:22 [172.23.113.4] {SER Reports} LOGIN user "" (attempt)
16-Dec-2016 23:15:52 [] Server listening on port 8080 ..
16-Dec-2016 23:18:05 [172.23.113.4] {Daily Request Log} LOGIN user "dmorrison" (attempt)

Thanks for the speedy fix.

FYI, our other Elog instances which are running ealrier versions do not exhibit this problem, as I confirmed that entering null ID/password returns "Invalid Username or password" as expected. This may be why it wasn't mentioned by anyone else before. Maybe something got inadvertently dropped in the newer version.

Periodically (rarely) on manually adding a record into Elog it generates a duplicate record with its own incremented ID and I don't know why. I just delete the duplicate in the meantime but would like to know if anyone else has seen this and whether their is a answer/fix for it. Thanks.

Are you using the current git revision Xuan?

I'm aware there is the "Show Last Default" setting for the Find page but is there (or can there PLEASE be) a similar setting for the Period filter on the List page? Our users routinely use the Quick Filters instead and it bogs down the system because we have lots of logbooks. Many thanks.

I have a very long standing problem with elog over the last few versions where almost daily the service will hang. Cannot even Restart elogd, that just hangs. Clients experience Page not Found. I can only get the service reinitialized by rebooting the VM machine. I have Elog verbose logging On plus a number of external triage monitors running but nothing is yielding clues beyond the precise time the hang occurs. Aside from providing the Config and log files what else can I provide for you to assist, and what other triage measures can you suggest I try? FYI, there can be up to 20 users at one time doing searches (not updates), and I've trimmed the depth of log files that can be searched so that the CPU/service doesn't bog down but that hasn't helped either. Inserts happen in the background using the elog client app (about 2 or 3 inserts per batch at sporadic times).

I could begin debugging with C++. In the interim, if you think it will help, I can also provide you with my Config and log files, and the section of redacted data encompassing the time of the hang - just let me know. Regarding CPU usage, I have noted that in the past and have never seen very high CPU usage during an Elog hang. The VM itself remains responsive.