Hi Stefan, thanks! Does the Date field need to be the first field in each entry? I can see adding a "termpory" field called "Orig Date", upload the old entries, then edit the file(s), delete the Date field, and rename Orig Date to Date. Will that work?

Hi Stefan, thanks! Does the Date field need to be the first field in each entry? I can see adding a "termpory" field called "Orig Date", upload the old entries, then edit the file(s), delete the Date field, and rename Orig Date to Date. Will that work?

You could transform your entries into the ELOG file format (either XML or CSV) and then use the import function. That would upload the correct dates from your entries.

If you use the "Orig Date" trick you've proposed, you'll see that datetime fields are stored as seconds of the epoch (since 1.1.1970). Not so easy to copy and paste them, but you can convert them with a script.

Cheers, Andreas

Hi Andreas,

Thanks for your input! After a little testing, it appears that if I make "Orig Date" the first field, it will fall under the Date field in the logbook file. I can then do a global delete of Date:, and replace Orig Date: with Date:, leaving it as the first field in the entry. Then I can delete the Orig Date field.

Hi David,
correct. And in addition you will need to convert "Orig Date" from seconds-of-the-epoch into a properly formated date string (see example below from Stefan) ...

Andreas

For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.

I've been running elogd like this (to get more info)

elogd -v > elog-2233-2.log 2>&1

The last entry I get in the log when elogd crashes is:

  Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"

I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.

Any additional information you need: Just let me know.

Regards,

Thomas

For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.

I've been running elogd like this (to get more info)

elogd -v > elog-2233-2.log 2>&1

The last entry I get in the log when elogd crashes is:

  Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"

I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.

Any additional information you need: Just let me know.

well, I need to reproduce your problem in order to fix it. The failed assertation you get is due to some internal writing beyond array boundaries, but I have no clue which part of the code makes this. It might be related to the fact that you use the same index (via Subdir=...) for two logbooks. In this scenario, you are only allowed to modify/add entries to one logbook, not the other. The other one may only be used for reading. And even then it's not guaranteed that new entries show up in the second logbook immediately, you might have to restart the server in order to re-index the logbooks. Internally, the daemon does not know that two logbooks are "the same" and one instance will not realize if the other instance modifies the data "below its feet". Can you try to give up the double logbooks and see if the problem goes away?