That's strange. Normal pages are set to "pre-expire" (expiration date 1983...) which forces the browser to always load them from the server. This is necessary since someone else could have modified that page and you would look at an old page in your browser's cache. But using this, I never saw a "page expired" message. The browser simply reloads the page. Maybe if the internet connection got lost in between and the browser cannot load the page from the server, you have a problem. Attached pictures have a expiration date of +1 day. So even if you span different time zones, that should be fine. Can they try to access https://midas.psi.ch/elogs/Linux+Demo/14 and see if they get the same problem there? This is my demo setup and resides in Switzerland.

The only way to get two entries is if you submit your entries twice. The same problem exists on some credit card payment sites, which explicitly state "please be patient, don't press submit twice, don't press back". The same applies for elog. 

No, this is not implemented right now. But if nothing else helps, I can add a new option.

 Stefan,

Thanks for writing back so fast. I'll have the folks in India check that link and see if the problem exists there.
I couldn't duplicate the problem here on my end. I'm beginning to think that it's a connection problem. They
tell me that the elog site (our site) is slow for them. It's only capable of 118kb/sec which, coupled with
the distance from USA to India might make things slow. In the USA I found the site to be usable and not that
slow. I'll let you know what they say about the test link.

Mike

I talked to my associate from India. He tried that link you provided and claims that even on your

site the "page expired" message occurs. Weird eh? Any ideas?

Not much. Since they are the only ones reporting this problem, I'm tempted to attribute this to their local configuration (browser, proxy, etc.). Have they tried different browsers on different machines?

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