Sorry I forgot to include the elogd.plist file in the distribution. I attached it to this entry, so just copy it into the elog root directory and run again "make install".

/Stefan

Thanks! now install works fine - but I cannot find how to open and start writing- I do

/usr/local/sbin/elogd
elogd 3.0.0 built Feb 13 2015, 16:42:32 revision 21dc563
CKeditor detected
ImageMagick detected
Indexing logbooks ... done
Server listening on port 8080 ...

but nothing pops up...I mean it is not possible to run "offline" ie locally on my mac ?

Point your browser to http://localhost:8080 as written in the documentation

Hi,

It´s not possible to install the last version V3.0.0-72a8401 over XP SP3, the previous version works well.  For Windows Vista Home Basic SP2 work fine the last version. 

I´m not sure if this the correct site to post this.

Regards

Pedro Acosta

Maybe, nobody uses XP SP3 but i get Win32 invalid aplication error.  Not work!

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

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

We recently tried upgrading the ND280 elog instance to elog 3.1.0. [1] We seem to have some problems with this 'auto-save' functionality.  Specifically, it doesn't seem to play nice with the fact that we prefer to disable user's ability to edit old messages.  So we have (up to now), had the following set of commands specified in elogd.ccfg

Menu commands = List, New, Reply, Delete, Duplicate, Copy to, Move to, Find, Help

The problem is that we now get auto-saved messages, but no ability for the user to actually go back and finish the draft message.  You can see an example of this state in this test elog

http://neut17.triumf.ca:8080/demo/

Clicking on the draft message you can see that it can't be editted.  If you try to click 'new' then edit the draft, you get the message 'Error: Command "Edit" not allowed'.  So we had zombie draft messages, until we added the edit command back; but that defeats our preference that users not mess up old messages.

In general this auto-saving seems like a useful feature.  So the ideal solution for me would be to have some mode where users could edit/finish draft messages, but where we could still disable users from editting completed/finished messages.  Ie, where we can omit 'Edit' from the menu command, but still get auto-save.

A less ideal, but perhaps simpler solution would be that if an elog has omitted 'Edit' from the menu commands, then this auto-save/save functionality is disabled so that we don't get uneditable draft messages.

[1] https://midas.psi.ch/elogs/Forum/67855