I am receiving a segfault whenever I attempt to upload a file.   Please see attached .txt for valgrind output.   This occurs in version elog-3.1.5-1.   I reverted back to version elog-3.1.4-3 and the segfault does not occur.

Segfault occurs in Elog version: elog-3.1.5-1

System:

Virtualization: kvm
Operating System: Ubuntu 24.04.1 LTS
Kernel: Linux 6.8.0-49-generic
Architecture: x86-64
Hardware Vendor: QEMU
Hardware Model: Standard PC _Q35 + ICH9, 2009_
Firmware Version: 1.15.0-1
Firmware Date: Tue 2014-04-01
Firmware Age: 10y 8month 1w 5d
 

Valgrind command:   valgrind -v --leak-check=full --track-origins=yes ./elogd  -s /usr/local/elog -c /var/www/elog/he6/elogd.cfg -f /var/run/elog/he6.pid

Steps to reproduce:

1. Login elog

2. Create new logbook entry

3. Attachement 1:  Select Browse

4.  Select any file.

5.  Select Upload

Looks like duplicate report to https://elog.psi.ch/elogs/Forum/69826

A statement like "core dumped" does not help much. Same with valgrind memory leaks. I need a full strack trace with all parameters when the segment violation occurs. The easiest is when you run elogd vom inside gdb, and once you get the signal, do a "where" to see th full stack trace.

As you can see from this forum, there is absolutely no crash when you upload any file, so it must have to do with your config file or anything whcih is special in yoru environment. We have to find what this is so that I can reproduce it here.

Stefan

Thanks for further instructions here is full stack trace:

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
warning: 44     ./nptl/pthread_kill.c: No such file or directory
(gdb) where
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff764526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff76288ff in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff76297b6 in __libc_message_impl (fmt=fmt@entry=0x7ffff77ce765 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:132
#6  0x00007ffff7736c19 in __GI___fortify_fail (msg=msg@entry=0x7ffff77ce74c "buffer overflow detected") at ./debug/fortify_fail.c:24
#7  0x00007ffff77365d4 in __GI___chk_fail () at ./debug/chk_fail.c:28
#8  0x00007ffff7738019 in __strlcpy_chk (s1=<optimized out>, s2=<optimized out>, n=<optimized out>, s1len=<optimized out>) at ./debug/strlcpy_chk.c:28
#9  0x000055555557ac8a in strlcpy (__n=356, __src=0x89ab3c42edf52f00 <error: Cannot access memory at address 0x89ab3c42edf52f00>, __dest=0x7ffffffd5370 "agarcia") at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:156
#10 el_submit_attachment (lbs=lbs@entry=0x5555566873d8, afilename=afilename@entry=0x7ffffffd57e0 "pfSense-UDP4-1194-yuhaosun-config.ovpn",
    buffer=buffer@entry=0x5555566bba67 "dev tun\npersist-tun\npersist-key\ndata-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC\ndata-ciphers-fallback AES-256-CBC\nauth SHA256\ntls-client\nclient\nresolv-retry infinite\nremote pfsense."...,
    buffer_size=buffer_size@entry=5265, full_name=full_name@entry=0x7ffffffd58e0 "") at src/elogd.cxx:4547
#11 0x00005555555f91ea in decode_post (logbook=logbook@entry=0x7fffffffbff0 "He6", lbs=lbs@entry=0x5555566873d8, string=<optimized out>,
    string@entry=0x5555566bb1c9 '-' <repeats 29 times>, "16417726823211458101306576170\r\nContent-Disposition: form-data; name=\"unm\"\r\n\r\ngholman\r\n", '-' <repeats 29 times>, "16417726823211458101306576170\r\nContent-Disposition: form"...,
    boundary=boundary@entry=0x7fffffffbef0 '-' <repeats 27 times>, "16417726823211458101306576170", length=length@entry=7649) at src/elogd.cxx:28662
#12 0x00005555555fb5cc in process_http_request (
    crequest=crequest@entry=0x555556656658 "POST /He6/ HTTP/1.0\r\nHost: xxx.xxx.xxx.xxx\r\nX-Real-IP: 192.168.101.2\r\nX-Forwarded-For: 192.168.101.2\r\nConnection: close\r\nContent-Length: 7649\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win6"...,
    i_conn=i_conn@entry=0) at src/elogd.cxx:29317
#13 0x00005555555ffc68 in server_loop () at src/elogd.cxx:30302
#14 0x000055555555b1b9 in main (argc=<optimized out>, argv=<optimized out>) at src/elogd.cxx:31327
(gdb)
 

Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:

  https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0

Alternatively, you can compile from sources. Give it a try.

Stefan

Thanks Stefen!

I built from source (ELOG V3.1.5-3a5f2f00) and I confirmed as fixed.
 

When will the new source be in the standard download area ? I'm on ubuntu .

It is in the usual download area which is referenced at https://elog.psi.ch/elog/download.html

Stefan

So this never made it into the download area ?  elog-latest.tar is elog-3.1.5-1 and contains no files from 2024 or 2025 .

Thanks
 

I stopped making tar files, since most people building elog from sources just pull it from the bitbucket repository:

$ git clone https://bitbucket.org/ritt/elog --recursive
$ cd elog
$ mkdir build; cd build;
$ cmake ..; make

Hello. We are using explicity subdir names on our elog server to manage a large number of "Top groups" and sub "groups". When we create a new logbook from a template in the same group, it would be beneficial to automatically give a new subdir based on the previous one. At the very least, it should not reuse the same parameter as the template (see below).

At the moment, it copies the subdir parameter from the template logbook, which results in the new logbook writing to the same location as the template. That is very confusing and has the potential to be harmful as people can (and recently did) decide to delete these "duplicate" entries. But they are not duplicates, they are the exact same entries as the template logbook and deleting them removes them forever!

The way around this at the moment is to manually update the subdir after copying, but then the logbooks need to be re-indexed before the new logbook will display correctly. That requires a manual restart of the elogd process, which is less than ideal. 

Dear ELOG users,

starting with SVN revision 2328, custom input forms are implemented. This allows application specific formats for check lists etc. In our specific case we had to implement a shift check list, which was quite long. Furthermore the check list should be optimized for an iPad, which we take in the field and record various checks and readings (in our case some gas pressure gauges at the PSI particle accelerator). Since the standard ELOG interface was too inflexible, a completely hand-written form was needed. The form can be activated by the new configuration options Custom New Form, Custom Edit Form and Custom Display Form, one for a new entry, an entry to edit and and entry to display. In our case we used the same form for all three cases. This is how the shift check list looks under the Safari Browser on a PC:

And here is how it looks on the iPad:

Each section can be collapsed and expanded (blue arrows at the left), and various internal checks are made before the check list can be submitted.

Implementing such forms is however more something for the advanced user, since you have to hand-write HTML with CSS and JavaScript code. It can then however be a powerful method for check lists. Please find in the attachments the elogd.cfg configuration for that logbook and the shiftcheck.html source code file. It is a bit complicated since the page is a static page, elogd just serves it from the file. This requires all the dynamic functions to be implemented inside the HTML file with JavaScript. To display an entry for example, the JavaScript loads the raw data with the "?cmd=Download" command and the populates the form fields. The collapsing and expanding is done by using CSS properties. The integrated style sheet was optimized for the rendering on an iPad. Rather large fonts were chosen so that the items can be checked easily with your finger tips. Various parameters are sent between the browser and the elogd program via hidden fields and cookies. So only something for experts! But if you go through the effort and hand-write the form, it can be very handy. Note that you have to upgrade to SVN revision 2328 for the three new options.

Hello Stefan,

I created a custom form with the example you provided. When I enter the Data and Submit the Form I get the error message "Datei passwordfile.xml kann nicht geöffnet werden: No such file or directory".  Posting stuff works in all other logbooks.  Only in the "logbook with the form" there seems to be an error. (or misconfiguration on my side)

sections from my conf. File:

I tried copying the password file to the forms directory, the logbook directory, the ShiftCheck logbook directory and the elog root folder.  I always get the same error.  I tried entering the absolute path, there was no difference in the result.

When I disable the password file I am able to post without any problems.  Can you help me out? 

Jonathan

Dear all, 

is there an instruction document how to exacly host the ELOG on a server for example a raspberry pi?

Wishes, 

M

Just read the manual: https://elog.psi.ch/elog/adminguide.html

> is there an instruction document how to exacly host the ELOG on a server for example a raspberry pi?

would be same as on any other linux machine, in the nutshell:

- install generic raspbian (R-12 is current version)
- setup the network
- setup apache2 https with automatic https certificate renewal using certbot
- setup apache2 redirect to elogd port 8080
- setup elogd on port localhost:8080

some of this is written up here:
https://daq00.triumf.ca/DaqWiki/index.php/Ubuntu#Install_apache_httpd_proxy_for_midas_and_elog

in theory you can run elogd without apache https proxy, but I find computer security
people are quite happy when I tell them that I run apache https with SSLlabs score "A+".

also I believe elogd does not support automatic https certificate renewal, running
it behind apache https solves that.

another consideration, specifically for RaspberryPi, they use SD flash for storage,
and unlike SATA and NVMe SSDs, SD flash does not have SMART to report flash read,
write and wear-out problems. So you may run into unexpected SD flash failures. We do.

do daily/hourly rsync to backup/archive storage to avoid total data loss if this happens.

also be aware that SD flash is very slow, compared to normal PC SSDs. read speed is not too
bad, but write speed is quite abysmal.

as solution to this, RPi5 can have a PCIe/NVMe dongle, you can try that instead of SD flash.

K.O.

Not sure if this is a bug or not; if it is not, kindly reclassify the category.

Following is a small example of what I will dub a 3-level, conditional logbook:

This example is hardly complete, but it is sufficient to demonstrate the issue I am running into.  This works until I select from the 2nd level (manufacturer); it won't display the dropdown for the model (I think my show attribute edit is supposed to display that).  Is there a restriction on how many levels of conditional I can have?  If there is, it would be disappointing because I am trying to do something similar to this example.

I hope there is something very simple I can do to correct this, or perhaps a completely different approach that accomplishes the same thing.  I'd like to stick with the multi-level selection process as I have done here.

I am running elog 3.1.5 on Devuan Chimaera (approx. Debian Bullseye, sans systemd) in a Virtualbox VM.

If

1. Elog is configured to use webserver authentication, and
2. the user reported by the webserver does not exist in the password file, and
3. the "Guest Menu commands" configuration is set in "elogd.cfg", and
4. a logbook is accessed,

then Elog returns with a redirect (302) to the logbook itself, causing the loop.

The fix here is to remove the "Guest Menu commands" configuration from "elogd.cfg".

Source code location: https://bitbucket.org/ritt/elog/src/30ada1df634529c8011c27275c52a05b01b7b3d6/src/elogd.cxx#lines-27599

Hi!

I am not sure if this is a know issue: it seems that the equation editor does not work anymore. Is there any fix or alternative method to type latex formula in the log? 

Thank you!

We have observed the same issue. Did the CodeCogs api change? 

Thanks for the help.

is there any update on this bug? Has anyone else observed the same problem?

Apparently Codecogs have changed their URL. I tried the update from 

  https://editor.codecogs.com/depr/CK_Editor_v4x.php

but it did not help. The CK Editor v5 is quite different from v4 (like they require node.js to install it), so putting it into elog would be some major work. 

Stefan

Hello, I have installed ELOG in an Ubuntu 22.04 machine and is working great, but I have found a small bug with Author names.

I have the config set like this for the Author attribute:

Preset Author = $long_name
Locked Attributes = Author

For context, my name is Víctor, which includes the accented "í". When creating a new entry and submitting immediately seems to work well. However, if I create a new entry, save it as draft, go back to the list, and then go to the draft entry, the accented "í" has transformed into "Ã". If I repeat the process, it turns into "ÃÂ", and so on. As I have configured the Author to not be editable, the user cannot fix this manually.

I found a way around this bug by setting

Subst Author = $long_name

Which is okay for us, but might not be for everyone.

In fact I saved this entry as a draft and then on another tab tried to edit it and it wouldn't let me edit because the author name now did not match.