The server is crached because the author field was accidentally filled with a long string due to an automated (remote) script:

“
Author: The ion getter pump has successfully recovered and appears to be operating steadily once more. Consequently, I proceeded with sputtering to obtain an XPS survey scan of the Au sample.  Initially, the stability of the X-ray function was compromised, leading to multiple interruptions. Subsequently, an unexplained issue arose regarding the collection of counts on the channeltron detector. Additionally, the emission current exhibited fluctuations. Fortunately, it seems that we have addressed and resolved the previous issues.  In the image below, two XPS survey spectra are presented. The spectrum highlighted with a red line corresponds to the AlKa source, which was selected using the AlKa button. Conversely, the spectrum with a black line represents the MgKa source. In both cases, the energy configuration was set to 1486.7 eV. It's worth noting that the 1050 eV peak in both spectra corresponds to the Au4f state, with an energy displacement of 961.7 eV due to X-ray ghost lines caused by O contamination (84+961.7). It has come to my attention that the Mg source appears to have oxidized, a phenomenon we've observed before.  Moreover, it's important to highlight that the difference between the peaks in the low binding energy region is approximately 100 eV, not the expected 233 eV (considering the energy difference between magnesium and aluminum). This observation holds true for both cases where the same energy setting was used. Additionally, the energy of the Au4f peakSotirios Tsatso
“

Instead of just "Sotirios Tsatso". 

So it had nothing to do with the cookies etc.. But when the item created in this way was called up, the system crashed:

[248459.853246] elogd_misc[8407]: segfault at 561725164a4e ip 00007f8210c02854 sp 00007ffdcb92b338 error 4 in libc-2.31.so[7f8210a99000+178000]
[248459.853251] Code: 7f 07 c5 fe 7f 4f 20 c5 fe 7f 54 17 e0 c5 fe 7f 5c 17 c0 c5 f8 77 c3 48 39 f7 0f 87 ab 00 00 00 0f 84 e5 fe ff ff c5 fe 6f 26 <c5> fe 6f 6c 16 e0 c5 fe 6f 74 16 c0 c5 fe 6f 7c 16 a0 c5 7e 6f 44

> Hello,
> I am running Elog V2.1.3 on Solaris 8 and I was very pleased about this 
> tool.But now I have a problem: Sometimes it takes a lot of time submitting 
> an entry into a logbook, up to 3 minutes. This behaviour does only occur 
> sometimes. Did anyone of You experience something like this?

I have seen that behaviour only with certain versions of Netscape, running on 
the same machine than the elogd server. Since I did not observe this with IE 
or Opera, I attributed this to a Netscape flaw. Have you tried different 
versions of Mozilla?

- Stefan

We had the same problem here. What worked in our case was:

Traffic to port 113 (identd) was blocked. Because the server didn't give any
response at all there was a time-out to which we were waiting.  Opening up
the 113 port significantly speeded things up. Even when no ident-deamon was
running on the system. (it now gets an immediate no deamon running msg, and
can go on with it's processing instead of having to wait for a time-out)

Since there's no answer to that.
I am the only one with the problem? Did I just configure something wrong?
Thanks Heinz

There are two ways:

1) Use different password files for different logbooks. Each password file contains only those users which have access to that logbook.

2) Use "Login user = <usr list>" to restrict access to certain users in that list.

Stefan

Thanks for the answer. The real problem is that you can overwrite existing entries even if you have set an entry to "read only", i.e. you have forbidden further editing.

Heinz

There is no "read only" flag. Please describe what you exactly did. Probably you want "Restrict edit time" for that.

Stefan

Sorry, 

I meant "read only" by using "Restrict edit time" settings. e.g.

Restrict edit time = 24

I understand this to mean that an entry should not be able to be modified after 24 hours.

Heinz