Hi Frank,

Good bit of detective work.  To me it suggests that something as yet undetermined occurs, that, when the 57th reply happens, causes the issue.  If that "something" hasn't happened, all is well.  Apart from Heinz varieties (not true, in fact), 57 isn't an obvious number; nor did it leap out at me at a quick look at the parameters in the coding.  My example of deleting more than 40 entries causing elog to crash was at least consistent, it happened every time.

I'm trying to think what this something might be.  With my (admittedly largeish) database of elog entries, starting elog from a cold start will take minutes of indexing before it will display home page or whatever.   Presumably it must count the number of entries in each thread (as otherwise why always 57?), yet if you stop and restart, it doesn't necessarily need to do the full indexing again - time between restarts I guess, the authors not considering the evil deeds I perform on yymmdda.log entries.

Bare me out on this, I once had software that ran a system, and every Thursday, without fail, it always did a full recalibration on every start up.  Since updates were issued on Fridays, I commented that it was just adding to our pressure, "as if it knew the day of the week"; it really was (and turned out to be) a day-of-the-week bug.  So, I've been right on more than one occasion.  Anything in common with the threads with cross indexing, such as day of the week, day of the month, time, especially if crossing midnight before the 57th reply? 

Another line would be to view the yymmdda.log files while you are making a normal reply.  In my v2.9.2 version, nothing is written until the Submit button is pressed, then either one or two files are modified or one modified and one new one created.  Is that still true with your version?  I ask because clearly one or two entry numbers have somehow already been "reserved" as if opened, but where?  That Autosave =0 looks to be a useful test to do.

Sorry I cannot be more help.  I'm not one of the development team, though I do have experience of (ab)using elog, and I'm a pretty rubbish coder as well.  but I do have some experience in bug finding!

David.

Our setup uses "Authentication=Webserver" + no automatic user registration. Thus, logbook admins should add a user by clicking "Config"  and then "New user". However, no matter what they fill in in the "new user " dialog, as soon as they hit "Save" an error pops up saying that their username (the admin one, not the new one) already exists. I found the following code:

int save_user_config(LOGBOOK * lbs, char *user, BOOL new_user)
{
   char file_name[256], str[256], *pl, user_enc[256], new_pwd[80], new_pwd2[80], smtp_host[256],
       email_addr[256], mail_from[256], mail_from_name[256], subject[256], mail_text[2000], str2[256],
       admin_user[80], url[256], error[2000], sid[32];
   int i, self_register, code, first_user;
   PMXML_NODE node, subnode, npwd; 

   /* if we outsourced the authentication, use external username */
   getcfg(lbs->name, "Authentication", str, sizeof(str));
   if (stristr(str, "Webserver")) {
      /* do not allow HTML in user name */
      strencode2(user_enc, http_user, sizeof(user_enc));
   } else {
      strencode2(user_enc, user, sizeof(user_enc));
   }
 

which seems to be the culprit:  the admin user is logged using his/her Webserver (http_user) credentials and this overrides anything that he/she might fill in.  If I remove the "Authentication" check then I can create a new user without problems.  So, how to fix this? should the "Authentication=Webserver" check be extended with a self/auto registration check?

Hello.

I installed the latest elog (3.1.4-2) in CentOS 7, and it is working well without SSL.
When I enalbled SSL option (SSL = 1) in the "elogd.cfg", and tried to start the elogd, the message below was shown and failed to run.

SSL support not compiled into elogd

If I switched the elog to older one (3.1.4-1), I could successeed to run the elogd with SSL option.
Is there any other option required in the latest elog to run with SSL? Or is this bug in the latest version?

Thank you,
Hisataka YOSHIDA

When you compile elog from the soruces, you need the OpenSSL library to be installed. The CMake build process will then find it and include it in the compile process. When you use the "make" build process, you have to make sure that SSL is enabled there:

USE_SSL = 1

To install the OpenSSL library, you can do on most systems something like "sudo yum install openssl-dev" or "sudo apt-get install openssl-dev"

/Stefan

Hi,

I have set up my elog for testing and setup postfix to be able to send email notification for register of new user but whatever i try elog cannot set email. I try to sent test email in my bash and this is working without problem to my gmail account.

I have tried several configuration for my smtp client on my centos 7 but nothing is working in elog for the email. I also tried with several other email but no change either.

Is there a problem with the automatic sending of email ? 

Best

Pierre

Why don't you start elogd interactively with the "-v" flag (verbose) and watch the communication between elog and postfix. Maybe you see a specific error there.

Stefan

Hi Stefan, I did run in verbose mode but only got this output with the 587 SMTP port from gmail

Email from <ELog@localhost.localdomain> to XXXX@gmail.com, SMTP host smtp.gmail.com:
220 smtp.gmail.com ESMTP n1sm6153685pfd.156 - gsmtp
EHLO localhost.localdomain
250-smtp.gmail.com at your service, [134.160.38.27]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
AUTH LOGIN
530 5.7.0 Must issue a STARTTLS command first. n1sm6153685pfd.156 - gsmtp

However the mail command in my bash is working juste fine

Pierre

STARTTLS is not supported natively by elog. You have to disable this in your SMTP server.

Stefan