Re: elogd moves elog entries, posted by David Pilgram on Wed May 20 22:08:31 2015
|
> > Stefan told me that the change was because some users were having thousands of yymmdda.log files
> > in the logbook directories
>
|
Re: elogd moves elog entries, posted by Andreas Luedeke on Thu May 21 10:59:07 2015
|
I had no intention of causing any offence with my lazy archiving comment - hope I didn't, sorry if I did.
No
offence taken :-)
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 |
Re: elogd moves elog entries, posted by Andreas Luedeke on Thu May 21 12:13:21 2015
|
> > 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.
|
Re: elogd moves elog entries, posted by Konstantin Olchanski on Sat May 23 02:53:31 2015
|
>
> "News for each version can be seen in the changelog (->http://midas.psi.ch/elog/download/ChangeLog)"
>
|
Re: elogd lost entry database without restart during file system trouble, posted by Stefan Ritt on Thu Apr 30 13:01:29 2015
|
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
|
Re: elogd keeps crashing, any thoughts?, posted by Stefan Ritt on Fri Dec 4 23:45:56 2009
|
Allen wrote:
We are trying to track down an issue where elogd just stops, and I cannot seem to find a cause. |
Re: elogd hangs when Date format in elogd.cfg, posted by Stefan Kanitz on Thu Jan 8 15:36:28 2009
|
Stefan
Kanitz wrote:
Hi, |
Re: elogd hangs, posted by Stefan Ritt on Fri Aug 18 08:59:08 2017
|
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 |