> > Stefan told me that the change was because some users were having thousands of yymmdda.log files
> > in the logbook directories
> 
> I am one of those users. The elog for the ALPHA experiment at CERN goes back to 2006 or so,
> with large volume of messages and huge number of attachments. The MIDAS forum elog goes back to 2003.
> The TRIUMF DAQ internal elog goes back to 2001.
> 
> I think the new organization is an improvement.
> 
> K.O.
Hi Konstantin,

I've used elog as my main reference/logbook since 2005.  I had looked at it in its version 1 incarnation, but
didn't get on with that so well.  

My biggest problem in the past was running elog on two physically separated linux boxes, and for complex reasons
all the logbooks were on a memory stick (plus the vital backup)!  Hence my previously mentioned memory issues - in
my case the size of the available memory sticks.
David.

I had no intention of causing any offence with my lazy archiving comment - hope I didn't, sorry if I did.

Personally, I would have found it useful to put the attachments into a separate directory - or at least to allow

the possibility. Elog as it stands sometimes can, and sometimes cannot cope with that functionality - and even to try means messing around directly with the

yymmdda.log files. For me it would have saved me having duplicates of the same large attachment in two or three different logbooks, if I could always reference

the same Master copy of the attachment. This was at the time I was severely memory constrained, and in part forced me to change how I had operated elog, so for

me that need isn't as great as it once was.

David.

You can put a reference to the attachment of the other entry in your logbook: elog:67896/1

> > elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> > in the release announcement and in the release and migration notes. K.O.
> 
> But yes, the release documentation by bitbucket is not really that useful: 
> it is difficult for me too, to find out what changed with new releases. 

I did know that I've read it summarized somewhere!
The changes with the different releases are documented here:
http://midas.psi.ch/elog/download/ChangeLog

It is actually not so difficult to find: 
it is linked on the "Download" section http://midas.psi.ch/elog/download.html

"News for each version can be seen in the changelog (->http://midas.psi.ch/elog/download/ChangeLog)"

And for version 3.0.0 it states:
- Create one logbook subdirectory pear year

I admit that version 3.0 has never been announced and the changelog is not mentioned in the announcement of version 3.1.0
Maybe we'll do better in the future ;-)

> 
> "News for each version can be seen in the changelog (->http://midas.psi.ch/elog/download/ChangeLog)"
> 
> And for version 3.0.0 it states:
> - Create one logbook subdirectory pear year
> 

The text should read:

the first time you run the new elogd against old elog data,
all existing entries will be moved into by-year subdirectories
and the old elogd will not work anymore.

K.O.

First, I can only fix problems which are reproducible. Can we do another power outage at PSI again?

But seriously, I guess what happened is that elog sees an empty directory when the AFS server
goes down. If this happens, it rebuilds its internal (RAM based) indes, and sees no entries there.
So the next entry will be ID 1. That should be independent of the ELOG version. I guess if PSI
would have a power outage a year ago, you could have had the same problem.

I had problem some long time a go with AFS, where the network access blocked the program
for several minutes. I decided then to ONLY use local filesystems for elog servers, and do the
backup via rsync to an AFS account. Since then I never had problems.

Now it is hard for me to develop code which avoids the mentioned problem. I could maybe
check if there are many entries, and all over sudden there are no entries any more, the server
just stops with some detailed error message. But it is hard for me to mimic the AFS server 
outage. I can try to manually delete elog files and see what happens, but this only partially
mimics network problems.

/Stefan

> I'm running ELOG since several years with rather heavy usage.
> Last week I've upgrades from 3.0.0 to 3.1.0 and this week I had twice the same problem:
> elogd lost the index for old entries and showed empty logbooks, without having restarted.
> The logbooks appeared to be empty; new entries started with index "1".
> The first time the origin of the problem were network troubles;
> the second time it had been caused by a severe problem of our AFS file system service.
> I never experienced this consequence for ELOG in the past when we had AFS problems.
> 
> Since the logbooks are used for the operation log of a user facility they continued to do new entries.
> The next day I had to re-number the new entries and restart elogd and everything was fine.
> 
> I could understand if elogd crashes when the filesystem of the logbook goes away.
> And when it restarts with an (temporarily) empty filesystem, that would explain what happened.
> But it did not restart and the log file does not contain any information about any problem, 
> just that suddenly all new entries in each logbook started with ID "1" again.
> 
> Stefan, any idea?
> Anyone else ever experienced that with the new ELOG version (or older ones)?

 I need more information about that. Please have a look at Faq #19.

 I found my mistake:It must be

Date format = %Y-%m-%d

Steve

I have to figure out where elog hangs. I guess it must be some kind of endless loop, triggered by some corrupt data in one of the elog entries. Under linux this is fairly simple (just run elogd under the gdb debugger, wait until it hangs, then press ctrl-c and enter "where" to see a full stack dump where elogd is currently executing). Under Windows this is more difficult, since you need Visual C++ from Microsoft to do the debugging. One thing you can do however without VC is to check if the CPU time is consumed to 100% by elogd, indicating an endless loop.

Stefan