Dear colleagues,

I am trying to use the elogd as a service with activated shell-execution. Invoking 'elogd -x' on the command line works fine, as well as 'elogd -install'. The option 'elogd -x -install' does not seem to be implemented, so I followed two ways to get this to work:

1) creating my own service with instsrv/srvany and registry editing: starting 'elogd -x' does not work (error 1053), the -D option has to be added, to start the service without time out. But then shell execution seems to be not working, because no input to the elog is generated, but also no message saying shell execution was not enabled!

2) using 'elogd -install' and modifying the registry entry by adding the -x option to the command line in the 'HKLM\System\CurrentControlSet\Services\elogd\ImagePath': This enables shell execution, but instead of piping the output to the logbook, some DOS boxes pop up executing the shell command and terminate. No entries are generated.

Has anyone an idea?

Best regards

 Robert

I could never get shell execution work when elogd is started as a service. This has probably to do with system permissions or so under Windows. If anybody has a clue, please let me know. Under Linux this works nicely, but this is probably not an option for you...

Hi, All.  Ever since upgrading from an old ELOG release on an aging windows machine to the latest version on Scientific Linux 4 (RHEL4), and 
greatly increasing its use, we have seen frequent crashes of elogd.  This has become very disruptive to operations, and any help would be greatly 
appreciated.  We are using Apache (running on the same machine as elogd) to secure ELOG using https as per the Administrator's Guide.

Anecdotally, the crashes seem to frequently happen when a user is attaching an image.  However, most of the time attachments succeed without 
incident.

I attempted to obtain a stack trace by attaching gdb to the process, but elogd died during the night.  It was urgently needed, so I needed to kill 
the elogd process (ptrace() kept it hanging around) and therefore could not obtain a stack trace.  For what it's worth, here is the output we do see in 
gdb:
------
[root@lnx248 ~]# gdb /usr/local/sbin/elogd 6162
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /usr/local/sbin/elogd, process 6162
Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
0x007ef7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) c
Continuing.
Detaching after fork from child process 17720.
Detaching after fork from child process 17723.
Detaching after fork from child process 17726.
Detaching after fork from child process 17729.
Detaching after fork from child process 17732.
Detaching after fork from child process 17735.
Detaching after fork from child process 17738.
Detaching after fork from child process 17741.
Detaching after fork from child process 17744.
Detaching after fork from child process 17747.
Detaching after fork from child process 17750.
Detaching after fork from child process 17753.
Detaching after fork from child process 17756.
Detaching after fork from child process 17759.
Detaching after fork from child process 17762.
Detaching after fork from child process 17765.
Detaching after fork from child process 17768.
Detaching after fork from child process 17771.
Detaching after fork from child process 17774.
Detaching after fork from child process 17777.
Detaching after fork from child process 17780.
Detaching after fork from child process 17783.
Detaching after fork from child process 17786.
Detaching after fork from child process 17789.
Detaching after fork from child process 17792.
Detaching after fork from child process 17795.
Detaching after fork from child process 17798.
Detaching after fork from child process 17801.
Detaching after fork from child process 17807.
Detaching after fork from child process 17820.
Detaching after fork from child process 17823.
Detaching after fork from child process 17826.
Detaching after fork from child process 17829.
Detaching after fork from child process 17832.
Detaching after fork from child process 17835.
Detaching after fork from child process 17838.
Detaching after fork from child process 17841.
Detaching after fork from child process 17844.
Detaching after fork from child process 17847.
Detaching after fork from child process 17850.
Detaching after fork from child process 17853.
Detaching after fork from child process 17856.
Detaching after fork from child process 17859.
Detaching after fork from child process 17862.
Detaching after fork from child process 17865.
Detaching after fork from child process 17868.
Detaching after fork from child process 17871.
Detaching after fork from child process 25429.
Detaching after fork from child process 25432.
Detaching after fork from child process 25472.
Detaching after fork from child process 25475.
Detaching after fork from child process 25478.
Detaching after fork from child process 25481.
Detaching after fork from child process 25525.
Detaching after fork from child process 25528.
Detaching after fork from child process 25572.
Detaching after fork from child process 25575.
Detaching after fork from child process 25578.
Detaching after fork from child process 25581.
Detaching after fork from child process 32422.
Detaching after fork from child process 32425.
Detaching after fork from child process 32437.
Detaching after fork from child process 32440.
Detaching after fork from child process 32469.
Detaching after fork from child process 32472.
Detaching after fork from child process 32478.
---Type <return> to continue, or q <return> to quit---
Detaching after fork from child process 32481.
ptrace: No such process.
0x007ef7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0  0x007ef7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
Cannot access memory at address 0xbfe43894
------

I plan on letting elogd create a core dump, but so far I haven't managed to change its cwd to a directory elog can write to.

Please let me know if there is any other information I can provide.  Any suggestions would be greatly appreciated.

Many thanks,
Devin 

> ------
> 
> I plan on letting elogd create a core dump, but so far I haven't managed to change its cwd to a directory 
elog can write to.
> 
> Please let me know if there is any other information I can provide.  Any suggestions would be greatly 
appreciated.
> 
> Many thanks,
> Devin 

There are other debugers ...

  Whay don't you give them a try?

  example: Install "strace" (if you don't have it) and do something like ...

           strace   gdb /usr/local/sbin/elogd 6162  -debug 2>debug.out


   Also there is "ltrace", etc.

> Hi, All.  Ever since upgrading from an old ELOG release on an aging windows machine to the latest version on Scientific Linux 4 (RHEL4), and 
> greatly increasing its use, we have seen frequent crashes of elogd.  This has become very disruptive to operations, and any help would be greatly 
> appreciated.  We are using Apache (running on the same machine as elogd) to secure ELOG using https as per the Administrator's Guide.

Just follow

https://midas.psi.ch/elog/faq.html#19

Crashes with attached images are getting reported more and more these days, but so far I was not able to reproduce it. Maybe it's related to ImageMagic 
somehow, in which case disabling this feature might give some insight. To do so, you have to modify elogd.c and recompile. Change

   /* check for ImageMagick */
   my_shell("convert -version", str, sizeof(str));
   image_magick_exist = (strstr(str, "ImageMagick") != NULL);


to

   /* check for ImageMagick */
   image_magick_exist = 0;

Hi Stefan,

> Just follow
> https://midas.psi.ch/elog/faq.html#19

That's what I attempted to do, but the need to restart ELOG before I could get to the gdb console prevented us from obtaining a stack trace.  I am now setting up a test ELOG server where we will continue 
trying to reproduce our crashes and obtain a stack trace.

> Crashes with attached images are getting reported more and more these days, but so far I was not able to reproduce it. Maybe it's related to ImageMagic 
> somehow, in which case disabling this feature might give some insight. To do so, you have to modify elogd.c and recompile. Change
> 
>    /* check for ImageMagick */
>    my_shell("convert -version", str, sizeof(str));
>    image_magick_exist = (strstr(str, "ImageMagick") != NULL);
> 
> 
> to
> 
>    /* check for ImageMagick */
>    image_magick_exist = 0;

This has now been done and installed on our production server.  I will let you know if we have any more crashes with ImageMagick disabled.

Many thanks,
Devin

Hi Stefan,

The bad news is that elogd is still crashing even after disabling Image Magick.  The good news is that this time it was reproducible and I did obtain a
stack trace using gdb.  In this instance, a user was attempting to edit an entry he had just successfully posted.  In the crash shown below, he just Clicked
on "Edit" to edit the entry and then "Submit" without changing any text.  In the previous crash (that I don't have a stack trace for), he did actually try
to update the text of the entry.

Please let me know if there is any more information I can provide.

Many thanks,
Devin

------
[root@lnx248 ~]# gdb /usr/local/sbin/elogd 18720
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /usr/local/sbin/elogd, process 18720
Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
0x007ef7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0087663b in strlen () from /lib/tls/libc.so.6
(gdb) where
#0  0x0087663b in strlen () from /lib/tls/libc.so.6
#1  0x0804a4de in strieq ()
#2  0x636f6c2f in ?? ()
#3  0x00000012 in ?? ()
#4  0x00000003 in ?? ()
#5  0x62676f6c in ?? ()
#6  0x736b6f6f in ?? ()
#7  0xbff0a870 in ?? ()
#8  0x08051ddd in getcfg ()
#9  0xbff87340 in ?? ()
#10 0xbff87340 in ?? ()
#11 0x08051cfc in getcfg ()
#12 0x080c8e3a in __PRETTY_FUNCTION__.2 ()
#13 0xbff84100 in ?? ()
#14 0x00002710 in ?? ()
#15 0x00000000 in ?? ()
(gdb) bt
#0  0x0087663b in strlen () from /lib/tls/libc.so.6
#1  0x0804a4de in strieq ()
#2  0x636f6c2f in ?? ()
#3  0x00000012 in ?? ()
#4  0x00000003 in ?? ()
#5  0x62676f6c in ?? ()
#6  0x736b6f6f in ?? ()
#7  0xbff0a870 in ?? ()
#8  0x08051ddd in getcfg ()
#9  0xbff87340 in ?? ()
#10 0xbff87340 in ?? ()
#11 0x08051cfc in getcfg ()
#12 0x080c8e3a in __PRETTY_FUNCTION__.2 ()
#13 0xbff84100 in ?? ()
#14 0x00002710 in ?? ()
#15 0x00000000 in ?? ()
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/local/sbin/elogd, process 18720

> The bad news is that elogd is still crashing even after disabling Image Magick.  The good news is that this time it was reproducible and I did obtain a
> stack trace using gdb.

The seg fault reported above seems to be related to a specific elog entry combined with sending email notifications.  When trying to submit changes to that entry while sending email notifications, elogd seg faults.  We can edit the entry before it and create and edit a new entry after 
it.  Trying to edit that one entry and send notifications, however, reliably crashes elogd.  If I check "supress email notification", elogd does not seem to crash.  I have replicated this on separate elog servers running both SL4 and on SL5.  To compare with SL4, here is the trace I see on SL5 (Scientific Linux 5).

Once I receive the OK, I will send you the actual file that stores the problematic entry.  Please let me know if there is anything else I can send you.

Many thanks,
Devin

------
[root@lnx767 ~]# gdb /usr/local/sbin/elogd 13328
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

Attaching to program: /usr/local/sbin/elogd, process 13328
Reading symbols from /lib/libssl.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libz.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libkrb5support.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5support.so.0
Reading symbols from /lib/libkeyutils.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libkeyutils.so.1
Reading symbols from /lib/libselinux.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libselinux.so.1
Reading symbols from /lib/libsepol.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libsepol.so.1
Reading symbols from /lib/libnss_files.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1

(no debugging symbols found)
0x008db402 in __kernel_vsyscall ()
(gdb) c
Continuing.
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x0804a125 in strieq ()
(gdb) where
#0  0x0804a125 in strieq ()
#1  0x73207365 in ?? ()
#2  0x00000000 in ?? ()

Hi Stefan,

Just incase it helps, I am attaching the file for an entry in our demo logbook.  If I edit this entry and click on submit (without checking "suppress email notification"), I get the seg fault shown below.

If I delete any single character from the entry, I do not see any problems.  If I re-insert a character anywhere, the problem returns.

I hope this is useful.  

Thanks again,
Devin

------
[root@lnx100 ~]# gdb /usr/local/sbin/elogd 6040
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /usr/local/sbin/elogd, process 6040
Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libz.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
0x008c17a2 in _dl_sysinfo_int80 ()
   from /lib/ld-linux.so.2
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x080ad900 in interprete ()
(gdb) where
#0  0x080ad900 in interprete ()
#1  0x00000031 in ?? ()
#2  0x000005dc in ?? ()
#3  0x00000000 in ?? ()

Hi Stefan,

I hope I'm not bombarding you, but we seem to be seeing crashes in two separate scenarios.  In addition to the crashes I previously reported (editing a problematic entry and sending notifications), we 
have a (seemingly) separate means of crashing elogd.

One of our users connects from home using a satellite network (bursty and high latency).  Any time he attempts to upload an image from this connection, elogd crashes.  He has not yet seen any 
problems when using the same computer on site.  Here are the stack traces I've obtained, first on SL4, then on SL5.  Again, please let me know if there is any other information I can provide.

Thank you very much for your time and effort.

Sincerely,
Devin

------
[root@lnx100 ~]# gdb /usr/local/sbin/elogd 3728
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /usr/local/sbin/elogd, process 3728
Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libz.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
0x008c17a2 in _dl_sysinfo_int80 ()
   from /lib/ld-linux.so.2
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x080af727 in decode_post ()
(gdb) where
#0  0x080af727 in decode_post ()
#1  0x00000000 in ?? ()
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/local/sbin/elogd, process 3728

----

[root@lnx767 ~]# gdb /usr/local/sbin/elogd 13111
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

Attaching to program: /usr/local/sbin/elogd, process 13111
Reading symbols from /lib/libssl.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libcrypto.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libkrb5support.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5support.so.0
Reading symbols from /lib/libkeyutils.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libkeyutils.so.1
Reading symbols from /lib/libselinux.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libselinux.so.1
Reading symbols from /lib/libsepol.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libsepol.so.1
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
(no debugging symbols found)
0x00308402 in __kernel_vsyscall ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x080b2f8a in decode_post ()
(gdb) where
#0  0x080b2f8a in decode_post ()
#1  0x00000100 in ?? ()
#2  0x00000000 in ?? ()

Hi Devin,

first of all, your stack traces are only of limited use for me. This typically happens 
if you attach gdb to a running process, then you get something like

#0  0x080b2f8a in decode_post ()
#1  0x00000100 in ?? ()
#2  0x00000000 in ?? ()

(note the ??). If you run elogd directly from gdb, the stack trace contains much more information:

[meg@megon elog]# gdb elogd
...

(gdb) run
...
Server listening on port 8080 ...

Program received signal SIGINT, Interrupt.
0x0000003cb48c78d3 in __select_nocancel () from /lib64/libc.so.6
(gdb) where
#0  0x0000003cb48c78d3 in __select_nocancel () from /lib64/libc.so.6
#1  0x000000000046ea51 in server_loop () at src/elogd.c:27688
#2  0x0000000000471de8 in main (argc=1, argv=0x7fffe2b9bf18) at src/elogd.c:29018
(gdb) 

including the line numbers, arguments etc. So please try to start elogd from inside gdb 
and then reproduce your crash.

Your first problem seems to be related to some contents of your elogd.cfg, since in 
one stack dump I saw a 

strlen()
...
getcfg()

Here, the getcfg() function is called to retrieve some configuration from elogd.cfg. 
Maybe you have a very long line, or the file is otherwise corrupt. Please check that
carfully and send me your elogd.cfg so that I can have a look myself. Usually it helps
to remove one line after the other and check when the problem disappears.

Your other problem which has the decode_post() in the stack dump seems to be related
to the case when you upload an entry (or attachment), and the TCP link breaks in 
the middle. Probably the error handling in such a case is not correct. I will try
to reproduce this, although I don't have a satellite network.

Best regards,

  Stefan

There was a general problem in submitting entries. If the TCP connection between the browser and elog 
disconnects during the transmission and only part of the request gets transferred, it consistently 
crashed elog. The probability for this is large if you have a slow connection and long attachments. The problem 
has been fixed in SVN revision 2174, so please upgrade and try again.

Indeed, uploading images over a satellite connection does not crash the development ELOG server available from SVN.  Our user was unable to 
crash 
elogd (or upload an image) and reports "The upload window would complain about an "upstream server", but the site was still there."

Thank you very much for your time and help (with both of the issues reported in this thread).

Sincerely,
Devin

Hi, Stefan.  When someone using a satellite connection tries to upload an attachment *or* edit a long entry, it fails and they are presented
with an "Internal Server Error."  This is a huge improvement over the previous behavior of crashing elogd, but we were wondering if there is any
hope of improving this further so that one can edit large entries or upload attachments over a slow (in this case, satellite) connection.  Do
you have any ideas or plans on working on this further?  Apparently ELOG is the "only" service this user has trouble with from  home.

Any information you could provide would be greatly appreciated.

Many thanks,
Devin

> Hi, Stefan.  When someone using a satellite connection tries to upload an attachment *or* edit a long entry, it fails and they are presented
> with an "Internal Server Error."  This is a huge improvement over the previous behavior of crashing elogd, but we were wondering if there is any
> hope of improving this further so that one can edit large entries or upload attachments over a slow (in this case, satellite) connection.  Do
> you have any ideas or plans on working on this further?  Apparently ELOG is the "only" service this user has trouble with from  home.

There was a timeout of 1 sec. in the elogd daemon, which probably is too short for a satellite connection. Unfortunately I have no satellite here 
around to test it, so I "blindly" increased it to 6 seconds in the current SVN version. Please give it a try. You can increase this yourself, its here 
in the code at (Rev. 2291) line 28270:

   FD_ZERO(&readfds);
   FD_SET(_sock, &readfds);
   timeout.tv_sec = 6;            <----
   timeout.tv_usec = 0;
   status = select(FD_SETSIZE, (void *) &readfds, NULL, NULL, (void *) &timeout);

so you can change the 6 to 10 or so. The disadvantage of a large value is the following: Suppose you submit an entry, and in the middle of the 
submission your browser dies (or the user closes it). If you have a timeout of n seconds, the elogd server will wait that time until it closes the 
connection. During this waiting time is cannot respond to other request, so it might look dead. That's why we should not make it too long.

- Stefan

Hi Stefan,

> There was a timeout of 1 sec. in the elogd daemon, which probably is too short for a satellite connection. Unfortunately I have no satellite here 
> around to test it, so I "blindly" increased it to 6 seconds in the current SVN version. Please give it a try.

The latest release (2.8.0-2313) does fix this problem.  Our user is now able to modify entries and upload attachments using their satellite connection.

Thank you very much for your time and help.  I am sorry I didn't receive this in time to help test the old SVN version.

Sincerely,
Devin

Hello

Using windows7 and the elogd 2.7.7 built Jul 31 2009, 13:01:20 revision 2246.  I noticed a bug in the tables created with fckeditor. When on winxp there is no problem. So it seems windows7 related. 
Don't know if I should post here or somewhere else. When i Click the table icon i get : 
When I want to continue ( Pressing Yes) i get

So the OK button is removed, and i can only cancel. So it's impossible to create a new table in elog. ( yes , create it by hand, but that is not so nice )
Download the latest version of elog : elogd 2.8.0 built Aug  2 2010, 12:16:05 revision 2312 . Just to see if this helps. The result is the same.
Is there some solution/workaround for this ?

Thanks for elog : it's great.

Answer : Problem solved. It is not window7 related. When I did a fresh install ( not installing over the old directory ) everything is working as expected. So I did something wrong with installing over the old elog directory.

Thanks for you're time and the inconvenience.

Attributes = subject, ... 
Options <name> = test{1}, ...  

Subst myvar = $shell(dir) 
{1} Preset subject = Test 
{1} Preset text = $myvar 

Attributes = subject, ... 
Options <name> = test{1}, ...  
Subst myvar = $shell(dir) 
{1} Preset subject = Test 
{1} Preset text = $myvar 

{1} Preset text = $shell(dir)

We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it?

Details

We have two elog servers set up with identical elogd.cfg and password files, except that one server has "Mirror server" pointing to the other host. There are three logbooks defined.  (Their names are DoubleChooz, BigBrotherTable, and FlushingTable.)  When the mirror synchronization happens, whether by "Mirror cron" or by an administrator hitting the "Synchronize all logbooks" link, it often happens that entries requiring synchronization are corrupted on both servers (not just the one to which the entry was copied). This is particularly likely to happen if entries have been made on both servers since the previous sync.

Looking at the logbook files themselves, we see that the corrupted entries will have attributes from the wrong logbooks. E.g., we'll see an empty "Barometer: " line in a DoubleChooz logbook file, where "Barometer" is an attribute that is only in the FlushingTable logbook, or we will see there are unexpected DoubleChooz logbook attributes in the FlushingTable files.

Strangely, the entries will not be identical on the two machines after syncing, and they stay non-identical on further syncs.

Most disturbingly, data is lost from entries that were perfectly valid before the sync, on both servers.

This was happening with elogd 2.7.8, and continued to happen after upgrading to 2.8.0. Both servers are running Linux. One is a 32-bit machine and another 64-bit, in case that might matter (but read on).

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized.  This suggests it isn't specific to Linux architecture, 64-bit or otherwise.

We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.

Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?

Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-)

 I have been using the mirror mechanism for one year for the online T2K /ND280 (neutrino oscillation experiment at J-PARC, Japan).  It has been a savior to allow access to all collaborators to the Elog.  The experiment online computers are all behind a double firewall that allow only communication through ssh and http in one direction: from the inside to the outside. The master Elog is located in Canada and accessible remotely to all collaborators.  The mirror Elog is located inside the firewall on one of the online machines in Japan and synchronization is setup to run automatically every 5 minutes. There are 10 logbooks defined for each of the sub-detector groups.

At first I encountered a big problem when messages were added on both sides.  It turned out that Elog mirroring does not work when the two instances are running on different time zones. After I set the machine in Canada to run on Japan time (JST), no further problems have happened. Postings are routinely entered on either of the Elogs and synchronization works well.  This feature is essential to having a workable Elog for the T2K experiment. 

I had reported the problem of timezones to Stefan last year. He was going to put it on his wish list.

 Since we updated to 2.7.8 we've found a problem.

Previously, when we used 

Subst on reply subject = Re: $subject

Sorry, that appears to be an undocumented bug fix :-)

The desired behaviour should be created by

Preset on reply subject = Re: $subject

The command "Subst" is supposed to overwrite the field after it is submitted.

From the documentation you will even find a nicer possibility:

Preset on first reply Subject = Re: $Subject

The prevent replies to build a long chain of "Re: Re: Re: ...."

Cheers Andreas

I just typed a long text into this elog, clicked "submit" and it bombed with "you must select an Icon", returned me to the editor with all my text gone gone gone. I do not want to select icons, I just want to report a problem with elog. Well, 2 problems, now.

K.O.

Well, first RTFM: "Fields marked with a * are required" on top of the elog entry page. Then, use a reasonable browser on a reasonable OS  

On Google Chrome the text is still there (actually I just tried it with this entry). No idea what Safari under OSX does. Under Windows, Safari keeps the text. Actually this is controlled by the FCKEditor inside elog which is written by someone else. So complain there! Funny: We have about 1000+ entries in this forum, and you are the first one complaining about this.

Hi, I rsync an elog database from CERN to TRIUMF every few months and I notice that rsync keeps copying preview files (xxx.png.png, xxx.gif.png, etc) from very old entries. I guess that elogd creates these files from scratch each time they are needed, overwriting any previously existing preview files. This creates extra rsync network traffic and rsync takes longer to complete. Is there any way to avoid this? K.O.

Actually the thumbnail files are only created if they are not there. This is done in the function crate_thumbnail():

   i = get_thumb_name(file_name, str, sizeof(str), 0);

   if (i)

      return i;

So if these files are recreated always, something must be wrong there. Or you sysadmin runs a cron job which deletes them every evening