Hi,

when I try to edit an entry of my ELOG, the display shows the editor window blank, without all the previous content of the entry, and it is not possibile to write in it. It worked since yesterday, when ELOG tried to save a new entry but the disk was full. ELOG was srewed up. I deleted the buggy entry and now I can display all the previuos entries, but I cannot edit anymore... Please help!

Sara

 I've a little experience of digging myself out of (in my case, self-induced) problems using ELOG.   I'm also aware that I may be the least experienced/qualified user..

First:  Archive your work directories.  Then at least whatever you do from here, you've got the status quo to fall back on.  Also, record anything you can remember (ID number, thread, etc) of the deleted entry/entries.

I've found that ELOG can hang in an infinite loop if it tries to find an entry that is no longer there - and that depends upon how you approach the point where the missing entry would be.  ELOG's own delete works fine in normal circumstances.  I'm talking about abnormal circumstances, for example when idiots (me) are playing around with the yymmdda.log files, or *possibly* if the disk is full, and you then try deleting the entry that caused the full disk problem.  Whether that is what you are seeing, I cannot say at present. 

However, to progress this:  When you are stuck, unable to edit anything, in a[nother] terminal, try the process report

ps -A

two or three times, with a short interval between commands.  (Or other switches if you know how to select to view the elogd process on your system).   If elogd is using seconds of CPU time between each ps command, it's probably in an infinite loop.  If you need to be sure, wait a minute and check again.  If so, you'll have to stop the daemon, possibly requiring a computer reboot.  In my experience, ELOG does not get stuck in an infinite loop when just indexing the pages when the daemon starts, but experts may well know better.

This may at least diagnose whether you cannot edit because ELOG is stuck in an infinite loop, or has some other cause.

If it is the infinite loop, the trick is to find which entry causes the loop without getting stuck in that loop next time around. 

David Pilgram.

 Hi David,

you have been very helpful indeed. The problem was the one you spot, I've deleted the  buggy entry removing the ***.log file, and this caused disaster..... now it is working again, thanks a lot, I have all my PhD thesis in ELOG....

Sara

Don't get too excited yet!

When you reply to an entry in ELOG, then some additional data is added to that original entry. 

So, if you reply today (say 02/06/11) to an entry made yesterday, then you will find that the file 110602a.log has a large change (the new entry in full, plus elog extra codes), *and* an additional line added into 110601a.log.  Deleting 110602a.log will not remove the line in 110601a.log, and that could still cause problems, that is, wandering into an infinite loop.

To save a lot of effort, I'll suggest that you (a) keep the back-ups up to date, and keep two (the latest and the one before that); (b) proceed carefully at least to start with.  If you fall into the infinite loop again, then flag it up and I (or someone else) will be able to give further pointers.

David Pilgram.

So unless you are sure that

PS: maybe this dump could give a clue..... what's the directory of  size

12288

.

created on Jun  1 14:08  ... ? has it screwed up elog?

Sara

[vanini@nbvanini ~]$ ls -latr /usr/local/elog/logbooks/work/

-rw-r--r-- 1 elog elog   3443 May 30 12:31 110530a.log
-rw-r--r-- 1 elog elog  38956 May 30 14:17 110322a.log
-rw-r--r-- 1 elog elog  48804 May 31 10:05 110302a.log
-rw-r--r-- 1 elog elog  75644 May 31 17:09 110427a.log
-rw-r--r-- 1 elog elog   4079 May 31 18:58 110531a.log
-rw-r--r-- 1 elog elog  77316 Jun  1 10:43 110113a.log
drwxr-xr-x 2 elog elog  12288 Jun  1 14:08 .
-rw-r--r-- 1 elog elog   2904 Jun  1 14:20 110601a.log
 

Since you used the -a switch for ls, the current directory '.' i.e. work/ is included in the list. I have the same kind of output. No worries.

Are you experiencing problems with ELOG?

 Hi Stefan,

First : Compliments with your fine application !

The issue : A user wants to search the database. He selects one of the quick filters (e.g. "Show Last / Month"). Next he fills in the form and as long as text boxes are used there is no problem. But when he chooses a value from a populated drop-down list, the quick filter disappears. Other way round (first drop-down list and then the quick filter) no problem.

Kind regards,

Peter de Mol

all instances of elogd use the same file name in /tmp when calling my_shell.  This can cause some inconsistent behavior when two or more copies of elogd are runnnig at the same time.  (eg. one might detect ImageMagik is installed, and the other not,)

The propsed solution is to have the parent read from a pipe to the child rather from a file.  A patch is attached.

With the recent Elog 2.9.0 rev 2412 the Self Register = 3 option doesn't work as expected: The user is immediately allowed to login. This is not what this option was doing, which is to wait for an approval by the administrator. Can this behaviour be restored, or should I change the value of the Self Register flag? Thanks

Are you sure about that (maybe used an older revision of elogd where this indeed was a problem?). The current V2.9.0-2412 gives me this:

If I then log in as the admin user, I see the configuration of the new user, but the account is not activated:

So the user cannot log in. The config file is:

[global]
port = 8080
password file = passwd
smtp host = mail.psi.ch
Self register = 3
Admin user = stefan

[demo1]
Attributes = Project, Category

Can you double check?
 

[global]
port = 8080
password file = passwd
smtp host = mail.psi.ch
Self register = 3
Admin user = stefan

[demo1]
Attributes = Project, Category

 HI Stefan,

I tried again and confirm the version number. I never got this pannel saying that my request will be processed by an adminstrator. Maybe the installation was incomplete? Is this pannel outside the standard src files?  I receive the mail as administrator, but the accout is already valid BEFORE I validate it.

This was working in previous versions, i.e. the entry was not created at all. And login wasn't possible.

We went back to 2.8.0 as the server is regularly crashing with 2.9.0 and we have to keep it alive for our running experiment. We are trying to isolate and reproduce the problem...

Try to use the simple config file, and see what happens there. Maybe it's a config option you use differently in the experiment. If you identify the config option which triggers the problem, I can probably reproduce it and fix it. Concerning crashes of 2.9.0: We have it running stably for our experiments, that's why I released it. But there are major changes since 2.8.0, mainly the Kerberos authentification (actually people from CERN asked for that). So it could be that in your case there are problems I don't see. In that case you have to test with which options in the config file the problems start. If elogd crashes, a stack dump would maybe also be helpful for me.

 Dear Stefan, after a long time I managed to get a test setup. The line that creates the misbehaviour is

Guest Menu Commands      = List, Find, Login, Help

which seems inocuous! But with this line a user with inactive account can login without validation. Without this line I get also the proper web page indicating that the account has to be activated when I register as new user.

Another little annoyance: When a user is prevented from login ("The account is currently deactivated") there is NO WAY to login, as any action with Elog tries to use the (non activated) username and password. I can't get back the login page!

Thanks

Great. This this description I could reproduce the error and fix it. The fix is in SVN revision 2414.

Cheers, Stefan. 

 If you could also obtain the display of the message "Your request has been forwarded to the administrator.You will be notified by email upon activation of your new account." when a new user apply in the presence of the Guest Menu commands, that would be perfect. Cheers

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?

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 
------------------------------------------------------

 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.

 Hi,

I have a MacOSX 10.6.7 laptop that periodically synchronizes my logbook with that on a Debian linux web server.  Both instances of ELOG are 2.9.0-2396.

When I create a new entry on the laptop, the indicated time stamp is correct.  When I click Synchronize on the laptop, the entry that gets mirrored to the Debian server has a time stamp exactly one hour earlier (in the past) on the Debian side.

Likewise, when I create a new entry on the Debian server, the indicated time stamp is correct.  When I click Synchronize on the laptop, the entry that gets mirrored from the Debian machine to the laptop has a time stamp that is exactly one hour in the future on the laptop.

This appears to be due to an incorrect handling of times with regard to "summer" (daylight savings) and "standard" time when mirroring between these two different machines.

Is there a straightforward workaround to immunize against this sensitivity?

Thanks!

Andreas

I am in the process of upgrading from 2.6.0 to 2.9.0.  I am installing it on a windows 2008 r2 server which is 64 bit.  I am having a few issues and am just wondering if Windows 2008 R2 is support with version 2.9.0.  Is there anything I need to know about the installation other than just run the exe file?  So far I have run the exe file and installed the software, the service is running, however I cannot get into the application.  I do not have IIS installed, it does mention it in the installation documentation, is this a requirement?  Any hints or ideas at this point would be appreciated.  I am close I just need that last tweek.  Thanks

 Hi Maureen,

You write "Upgrading from 2.6.0" Is that version working on the same computer?
If so then its strange. Else try with one of the demo config files and see what happens, try different ports etc.

If the service is running it should work the rest too. I'm running it on a Win7 64 bit so 64 bit is not the problem....

Best

Per