Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 208 of 801  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  1653   Mon Feb 6 12:58:26 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.6.1Re: elog allows me to create user "blahblah "

Dimitrios Tsirigkas wrote:
I noticed that when I register a username that contains whitespaces (eg "boing "), elog allows me to create the user of that name and updates the password file accordingly. It doesn't log me in, but it gives me no error message either. I also found that if I repeat the process it adds yet another entry in the password file, by the same name "boing ". Is that a bug or is there something wrong with my configuration?


Well, I tell you what is wrong: The form says explicitly (name may not contain blanks) and you did not listen Tongue

I can add a simple check if the name contains blanks, but then some people will come up with other strange characters (@#$%), and I'm not sure which of those gives problems. If you test this carefully and tell me which characters to make forbidden, I will happyly add a simple check.
  1654   Mon Feb 6 16:27:45 2006 Reply Dimitrios Tsirigkasdimitrios.tsirigkas@cern.chRequestLinux2.6.1Re: elog allows me to create user "blahblah "

Stefan Ritt wrote:

Dimitrios Tsirigkas wrote:
By the way, it is also possible to create a user that doesn't have a password! Shouldn't that be forbidden?


Well, some people want that!


Ok, fair enough. But maybe there could be an optional flag in the configuration that disables blank passwords... I wouldn't want some imposter to start entering stuff under the username of another user, so it would be nice if I could have some way of forcing them to have a password, even if it's a one-letter password.

Thanks,

Dimitris
  1657   Mon Feb 6 16:53:41 2006 Reply Stefan Rittstefan.ritt@psi.chRequestLinux2.6.1Re: elog allows me to create user "blahblah "

Dimitrios Tsirigkas wrote:
I wouldn't want some imposter to start entering stuff under the username of another user, so it would be nice if I could have some way of forcing them to have a password, even if it's a one-letter password.


Ok, I added an empty password check. If too many people will complain, I will make it a flag.
  66912   Wed Sep 22 14:21:50 2010 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux2.8.0Re: elog 2.8.0 as daemon crashes when editing selected threaded list

Mark Bergman wrote:

I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".

Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.

However, if eLog is run with "-v" in place of "-D", it does not crash.

 

Environment:

        CentOS 5.4

        eLog 2.8.0 built Aug  5 2010, 12:24:11

 

I tried to reproduce your problem with following simple configuration file:

[Bergman]
Attributes = Author, Status
Options Status = open, closed
Preset Author = $long_name

 

The result was that it worked fine (see attachments). Maybe there is another setting in your configuration file which causes the problem. Can you try the simple configuration and see if it still crashes?

Attachment 1: open.png
open.png
Attachment 2: closed.png
closed.png
  67052   Thu Apr 21 21:06:20 2011 Warning Mark Bergmanmark.bergman@uphs.upenn.eduBug reportLinux2.9.0Re: elog 2.8.0 as daemon crashes when editing selected threaded list

Mark Bergman wrote:

I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".

Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.

However, if eLog is run with "-v" in place of "-D", it does not crash.

 

Environment:

        CentOS 5.4

        eLog 2.8.0 built Aug  5 2010, 12:24:11

 

 

I'm now running eLog  2.9.0 and seeing the same crashes. However, I've got some more information that may be helpful.


The crash seems to be directly related to the order of replies in the thread. For example, in this thread I am replying to the original entry. The original entry has 2 children (the entries are siblings) and no grandchildren.

In our installation, eLog crashes consistently under the following conditions:

       go to the "list" display

       set it to "threaded"

       "select" a thread that has siblings at any generation of replies

       choose "edit"

If the selected thread only has one entry at any generation, eLog does not crash.

 

Here's a horrible attempt at a display of two message threads. Note that in the first example, there are 2 replies at the same generation (siblings)--both the person who responded and the original submitter replied to the initial submission. After that, all replies were to successive generations.

 

-------------- Causes eLog to Crash ------------------
!   Full Name (submitter) module failure 
    =>   Full Name (submitter) Re: module failure 
    =>   Full Name (replier) Re: module failure 
               =>   Full Name (submitter) Re: Re: module failure 
                         =>   Full Name (submitter) Re: Re: Re: module failue

------------------------------------------------------



-------------- No eLog Problem  ------------------
!   Full Name (submitter) Labwide failure of mcc 
    =>   Full Name (replier) Re: Labwide failure of mcc 
           =>   Full Name (submitter) Re: Re: Labwide failure of mcc 
                     =>   Full Name (replier) Re: Re: Re: Labwide failure of mcc 
------------------------------------------------------

  67065   Sun May 8 22:33:15 2011 Reply Ryanryan.hoitt@intelsat.comBug reportLinux2.9.0Re: elog 2.8.0 as daemon crashes when editing selected threaded list

Mark Bergman wrote:

Mark Bergman wrote:

I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".

Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.

However, if eLog is run with "-v" in place of "-D", it does not crash.

 

Environment:

        CentOS 5.4

        eLog 2.8.0 built Aug  5 2010, 12:24:11

 

 

I'm now running eLog  2.9.0 and seeing the same crashes. However, I've got some more information that may be helpful.


The crash seems to be directly related to the order of replies in the thread. For example, in this thread I am replying to the original entry. The original entry has 2 children (the entries are siblings) and no grandchildren.

In our installation, eLog crashes consistently under the following conditions:

       go to the "list" display

       set it to "threaded"

       "select" a thread that has siblings at any generation of replies

       choose "edit"

If the selected thread only has one entry at any generation, eLog does not crash.

 

Here's a horrible attempt at a display of two message threads. Note that in the first example, there are 2 replies at the same generation (siblings)--both the person who responded and the original submitter replied to the initial submission. After that, all replies were to successive generations.

 

-------------- Causes eLog to Crash ------------------
!   Full Name (submitter) module failure 
    =>   Full Name (submitter) Re: module failure 
    =>   Full Name (replier) Re: module failure 
               =>   Full Name (submitter) Re: Re: module failure 
                  &nb sp;      =>   Full Name (submitter) Re: Re: Re: module failue

------------------------------------------------------



-------------- No eLog Problem  ------------------
!   Full Name (submitter) Labwide failure of mcc 
    =>   Full Name (replier) Re: Labwide failure of mcc 
           =>   Full Name (submitter) Re: Re: Labwide failure of mcc 
                  &nb sp;  =>   Full Name (replier) Re: Re: Re: Labwide failure of mcc 
------------------------------------------------------

 

 I am also experiencing the same exact problem as explained above. It only seems to happen when a part of the title has changed. I will include my config for an example. Make a few entries, then change the "Customer" paramater. Then try and edit an entry in the thread.

 

 

 Enable attachments = 1

Attributes = Employee, Customer, XXX-ID, XXXX Number, SCD, Type, Status, Folder Created, XXXX Received, Equipment Installed, XXX Carrier Up, Customer Carrier Up, QA Completed


Thread display = $Customer  -  $SLR-ID  -  $Type  -  $Status  -  SCD: $SCD  - XXXX: $XXXX Number

Propagate attributes = Status

Locked Attributes = Employee
Options Type = Activation, Termination, Change
Options Folder Created = Yes, No, N/A
Options XXXX Received = Yes, No, N/A
Options Equipment Installed = Yes, No, N/A
Options XXX Carrier Up = Yes, No, N/A
Options Customer Carrier Up = Yes, No, N/A
Options QA Completed = Yes, No

Entries per page = 100

Preset Text = $short_name @ $utcdate -
Append on reply = $short_name @ $utcdate -

Locked Attributes = Employee

Preset Employee = $long_name

Options Status = Open, Closed

Quick Filter = Status, Type

Type SCD = datetime

Summary lines = 0
Enable Attachments = 0
Suppress default = 2
Entries per page = 10

Suppress Email to users = 1

Display mode = threaded
Collapse to last = 1
Expand default = 0
Subst on reply Employee = $long_name 

Faulting application elogd.exe, version 0.0.0.0, faulting module elogd.exe, version 0.0.0.0, fault address 0x000646c7.

  474   Fri Feb 13 21:59:44 2004 Reply Stefan Rittstefan.ritt@psi.ch Linux2.5.0Re: elog (not elogd) submit does not work anymore
Oops! I 're-used' the '-s' flag for email suppression, so it was actually 
double used. I changed the email supprssion flag to '-p', so '-s' should 
work again for specifying subdirectories.
  2097   Tue Nov 28 10:34:54 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.6.1+r164Re: elog (2.6.1+r1642 ubuntu/debian) regularly becomes non-responsive (w/o crashing)

Peter Kovac wrote:
First, the problem. Fairly regularly (at least once a week, perhaps more), our elog daemon seems to quietly die. The process is still running but anyone attempting to access the server gets "connection refused." The elog log doesn't show anything and the apache logs just show "proxy: Error reading from remote server returned by [path]". Calling a daemon restart doesn't seem to kill the daemon -- I get a "could not bind to port" error. Using kill and then starting the daemon again fixes the problem for a few days and then we start over.

The particulars:
We are running elog on an Ubuntu (6.06 Dapper Drake LTS) web server.
It's currently version 2.6.1+r1642 pulled via apt-get from the Debian repositories.
elog is hiding behind an apache2+SSL proxy.

Any thoughts? Has anyone else seen this behavior? My next step is probably to compile 2.6.2 and remove the packaged flavor but I wanted to see if this was a known bug...


There are three reasons why an elog server can go into an infinite loop:

  • A bug which has been fixed in meantime. If you can give a try to 2.6.2-1750 or so that could help. I'm not sure if this version is already in the Debian distribution since I'm not the maintainer there.
  • A corrupted log file. If one of the YYMMDDa.log file get some garbage (maybe due to hard disk problems etc.) the elogd server can run into an infinite loop. In that case examine all log files to see if there is anything wrong. If so, edit it manually and restart elogd.
  • Some not yet found bug. One never can exclude this of course, but at this forum I have elogd running under similar conditions like you, and it runs for months without problems.
ELOG V3.1.5-3fb85fa6