Hello,

I have just installed elog onto an ubuntu focal server using <sudo make install> and I am unable to create new entries.

When I access the log via a windows PC connected to the local network, I can see the demo logbook with the 1 test post, but I cannot create or edit anything.

Attempting to post throws the error:

New entry cannot be written to directory "/usr/local/elog/logbooks/demo/"

Please check that it exists and elogd has write access and disk is not full.

Please point me in the right direction to correctly set permissions and create aditional log books.

Thanks,

Dan

Hi all,

I have the same problem on Ubuntu 22.04. I have compiled from the latest tarball and copied all our logbooks from our old Ubuntu 18.04 server to a new Ubuntu 22.04. The logbooks does however not appear when I log in, so I assume ELOG doesn't have read access either?
Any hints on how to set the permissions correctly would be greatly appreciated.

Thanks,
Mikkel

Permissions are handled by the operating system and have nothing to do with elog. Make sure you run elog under an account which has write access to the desired directories. Consult Ubuntu documentation how to do that. Sometimes it's helpful to start elog interactively with the -v flag to see some verbose output. Maybe you can spot something there.

Stefan

Sometimes this can also be an SELinux issue, if you have that service running. Try "journalctl | grep denied" to see denied resources and consult the SELinux documentation on how to fix that.

I used "chown" to pass permissions from root to my deafult user, then restarted the service and now I can make posts. Thank you!

For the last couple of months we are getting a random elogd crash once in a while we are getting something like the following in the middle of the night

> Sep 29 20:45:07 elog kernel: server_name686835]: segfault at 7ffd7f5a0000 ip 00007fceaeabbf06 sp 00007ffd7f577348 error 6 in libc-2.28.so[7fceaea8a000+1bc000]

I'm going to try and see if it will leave a coredump file, just thought I would ask if anyone else had seen this before?

Thanks,
Matt

Most likely these are some currupt logbook files. If you get a coredump (or stack trace) you can maybe figure out which file it was. These are plain ASCII files (YYMMDDa.log) and you can see with an editor if someting there is not in order.

Stefan

Thanks for the info!