Elogd.exe Crashes When There are too Many Replies to Replies..., posted by Christopher Jones on Sun Oct 12 08:37:00 2003
|
Hi,
We have been using Elog successfully as a shiftlog book for over a month
now, but I recently ran into an annoying bug, I think.
We had a thread that was created and was being replied to over several
days. We first replied to the original thread and then each subsequent
reply was a reply of the previous reply. When the thread reached above 13
of these, the elogd.exe would crash everytime a user attempted to select
the logbook that contained the enormous thread.
I found the only workaround was to manually delete the offending entry
from the log file and to instruct my users to not reply to replies unless
absolutely necessary. I have been able to replicate this error across the
rest of my logbooks as well. If there is any more information you may
need, please feel free to contact me.
Thanks,
Chris Jones |
Elogd synchronisation with remote server, posted by Francois Cloutier on Thu May 14 02:35:15 2015
|
I came accross the admin guide and I was reading / searching for a way to sync logbooks across sites...
elogd mention "-m" and "-M" ... not elog but elogd... with that description :
synchronize logbook(s) with remote server
Does it sync all logbooks ? is there any examples somewhere or advice ?
Thanks :) |
|
Elogd service crashes on "reply" with percent character in subject line, posted by Mike Zuber on Thu Aug 19 15:26:35 2010
|
My logbook kept crashing whenever I tried to reply to an existing entry. I found that the percent sign "%", when used in the subject line, will crash the elogd service when you try to reply to the entry. This appears to only happen with windows installations. I tested this on your Linux logbook and it didn't crash.
Here is the message taken from the Windows event viewer after the crash:
An unhandled win32 exception occurred in elogd.exe [5224].
Thank you for Elog, you have done a good job with it. It is a great logbook.
Mike |
|
Elogd hangs while uploading bmp attachment, posted by David Wallis on Tue Oct 30 22:47:15 2012
|
I'm running elog 2.9.2 on a Red Hat 6.3 server. This installation has been running for some time on a Solaris server, and was recently moved to the RHEL server.
When a user tries to upload a .bmp attachment, the upload never completes, eventually timing out with a proxy error. At that point, the elogd process stops responding to requests and needs to be restarted. Nothing is in the log file other than a "Listening" message when elogd starts up. Png and pdf attachments seem to work fine. I was able to convert an image from .bmp to .png and upload, but that's not practical for my user.
ImageMagick 6.5.4-7 is installed on the server. Everything else seems to be working normally.
Is this a known problem, or have I missed something that needs to be installed on the RHEL server? |
|
Elogd crashes with: *** stack smashing detected ***, posted by Niklas on Fri Nov 21 10:53:09 2008
|
Hi,
elogd sometimes crashes when there are large cookies. Or I'd guess it has something to do with the cookies, elogd crashed over and over again until I cleaned out cookies and authenticated sessions in firefox, then it stopped.
When I run "elogd -v" in gdb, and someone does:
GET / HTTP/1.1
Host: bba.eld.ki.sw.home.se:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; sv-SE; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: urem=0; TWIKISID=ecaa5a39e8446a27ec5a34bcbb9d4bcb; unm=erirone; upwd=c3w5MTg1; ipplanNoAuth=yes; SMSESSION=oKvAAv/J9WoCo6KoVdEJkhxz44G10x7TXigffOaAjLrSf0iOFrRJq97oWl32/UBQMvFslc4BgxN/VCz2K7/IRaKdFgmU4CHq/1UUv2RvdHB2HUbYbph+JgKUpAG+kN6Cc4BTwRWhmemUNhONXMRJUCfa6Tq9/osID2AT1wBFInFNww2xVmJPDSi1oltxtT345RgdGQIZbHzG2HBi1GijpiaD+4FI3WLLRzJOj3Art92BLlVDWSaPxKSdSZgVNfRSw33SupUqwD0Is2pc+ufKn4cg0azyOTLNDFOl0U5RI7K9AVgYM0NBsfDoEyBfK8pYIZTMqFFQsnWAdwYz9M2RLDBKyfMXdfGb3rrnOdPH0zvvkkoT01pZObI7dSqHD7IXLbjN/8Pt0O4eo5/SSQ7uKRGpBip0pKe3mxZYI4hsJejYwVBFegovS4qSUiL8UGDhG+lB20WEmDwIQfTG2ZtpckLC6t1CNfa5eFLWCOm+yESU+3AmP4zdJLJSqbznEl2SQTePP5NzI1R5WTAvBbsgX+N9Ab1g0Yui/i042qWNQPLg3/5c/WCHqzImi45+ov42C4mj9OcjGcAf7kaWBMwfdwfChREWkSpMrC2RRndlw+iVbShSK7lVfoCvIqk4491uQBT3bz3S0e56Vin+Oj8qbmEA/5Hp1x9b80qTRy/8lj7KLgbhV60BBvX7ahOkrIFCSjTi8y87K/u4b3KQHesNZgA7SyWRuT+vY4XCb8ANVl8eIui7vK5NNSiFFqLZ1IoeFaVu+gS/hhDu3m/rmK2t5iR2YW/aKmnGTVQsPPy/POVY/zXWgf7c6ps/sSMwTk9sy5Yr8yGYBSUrtZkn1/gK0wpqlRCcjuG991sfgr/UKbhK1dU0rI9E9PBPhvLQpjUHT49AAHL9A9S3FOs66CAFsoVo00WNqKuZcmLpEgXdpbW+mj43tiNugCT98Ec8+Iq0rZYKhYdqFu9AUOdJVXk2udBx9VkOVcRYteFICtwz3fvR02KCU3Sn3a0HKZ4wWOujUnH4nThZGVlUNyg/Of+9GKXY4mxqv/5ocEkO4q8xmAP/OJHrvgJ42kTAjaVgjlSG3b5iJTcu4jvqfC/yKU88Sw==
*** stack smashing detected ***: /root/elogd_2.7.5_2142 terminated
*** stack smashing detected ***: /root/elogd_2.7.5_2142 terminated
Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7dad875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7daf201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7de4e5c in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0x00000000 in ?? ()
(gdb)
|
|
Elogd crashes when submitting replies, posted by Cliff Shaw on Thu Dec 10 16:05:59 2009
|
Hi Stefan,
I recently installed the latest Elog 2.7.8 revision 2277 after running Elog 2.7.7 revision 2246 for several months without any problems. However once I submit an entry by using the Reply command Elog crashes and Windows XP reports an error message screen. This also stops the elogd service.
I have pinpointed it down to the command "subst on reply Subject = $Subject" by removing my whole configuration file and just added the line "subst on reply Subject = $Subject" to your demo configuration file.
Elog seems to also stops the elogd service with any "subst on reply" command.
Do you have any suggestions?
Thank you,
Regards
Cliff Shaw |
Elogd crashes when closing more than ten entries, posted by Cliff Shaw on Fri Mar 12 08:18:06 2010
|
Hi Stefan,
I have noticed a problem when closing multiple log entries i.e entries which have more than 10 threads. I use Select -> Click the box that appears next to the thread I wish to close -> Edit.
As soon as I click on Edit the elogd service crashes and Windows displays an error message window. The only work around has been opening up all the threads and individually changing the "Status" to Closed.
Forgive me if this issue has been raised before but I have looked throughout the Forum and could not see anyone experiencing the same problem.
Thanks
Cliff |
|
Elogd crashes on search, posted by Laurent Jean-Rigaud on Fri Jan 31 15:17:04 2020
|
OS: CentOS 7 x86_64 up2date with RPM 3.14 x86_64
- Connexion to ELOG
- open one logbook and click search,
- input "test" and click "Search" : BOOM
- Firefox can not connect anymore on ELOG.
The crash is met with several words now ("test", "post", "4.5", are the one i know). We use a mirror server and the problem appears also on it .
NB: the hangs appears on EL6 x86_64 server with customized RPM built by myself. I retry with 3.14 SRPMS avalaible from ELOG site with same results. Idem with last GIT version. So i tested on EL7 with official RPM x86_64 (not suitable for EL6 as it needs GLIBC_2.14) before to open this ticket.
Terminal traces on server side follows.
[root@localhost /]# /usr/local/sbin/elogd -c /usr/local/elog/elogd.cfg 2>&1
elogd 3.1.4 built Sep 26 2018, 13:14:57 revision 966e3dd
File "/var/run/elogd.pid" exists, using "/var/run/elogd.pid.8080" instead.
Falling back to default group "elog"
Falling back to default user "elog"
CKeditor detected
Falling back to default group "elog"
Falling back to default user "elog"
Falling back to default group "elog"
Falling back to default user "elog"
Falling back to default group "elog"
Falling back to default user "elog"
Falling back to default group "elog"
Falling back to default user "elog"
ImageMagick NOT detected. Image scaling will not work.
Indexing logbooks ... done
Server listening on port 8080 ...
*** Error in `/usr/local/sbin/elogd': free(): invalid next size (normal): 0x0000000001c59310 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81679)[0x7f45a898f679]
/usr/local/sbin/elogd[0x45e756]
/usr/local/sbin/elogd[0x4824b0]
/usr/local/sbin/elogd[0x4a69b1]
/usr/local/sbin/elogd[0x4a7023]
/usr/local/sbin/elogd[0x4a954a]
/usr/local/sbin/elogd[0x4ac9d3]
/usr/local/sbin/elogd[0x4035a6]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f45a8930505]
/usr/local/sbin/elogd[0x4044d3]
======= Memory map: ========
00400000-004e3000 r-xp 00000000 fd:00 52822202 /usr/local/sbin/elogd
006e2000-006e3000 r--p 000e2000 fd:00 52822202 /usr/local/sbin/elogd
006e3000-007c4000 rw-p 000e3000 fd:00 52822202 /usr/local/sbin/elogd
007c4000-0173a000 rw-p 00000000 00:00 0
01a66000-01c8f000 rw-p 00000000 00:00 0 [heap]
7f459bdea000-7f459bdff000 r-xp 00000000 fd:00 84 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f459bdff000-7f459bffe000 ---p 00015000 fd:00 84 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f459bffe000-7f459bfff000 r--p 00014000 fd:00 84 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f459bfff000-7f459c000000 rw-p 00015000 fd:00 84 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f459c000000-7f459c021000 rw-p 00000000 00:00 0
7f459c021000-7f45a0000000 ---p 00000000 00:00 0
7f45a010c000-7f45a0114000 r-xp 00000000 fd:00 1598592 /usr/lib64/libnss_sss.so.2
7f45a0114000-7f45a0313000 ---p 00008000 fd:00 1598592 /usr/lib64/libnss_sss.so.2
7f45a0313000-7f45a0314000 r--p 00007000 fd:00 1598592 /usr/lib64/libnss_sss.so.2
7f45a0314000-7f45a0315000 rw-p 00008000 fd:00 1598592 /usr/lib64/libnss_sss.so.2
7f45a0315000-7f45a0321000 r-xp 00000000 fd:00 22487 /usr/lib64/libnss_files-2.17.so
7f45a0321000-7f45a0520000 ---p 0000c000 fd:00 22487 /usr/lib64/libnss_files-2.17.so
7f45a0520000-7f45a0521000 r--p 0000b000 fd:00 22487 /usr/lib64/libnss_files-2.17.so
7f45a0521000-7f45a0522000 rw-p 0000c000 fd:00 22487 /usr/lib64/libnss_files-2.17.so
7f45a0522000-7f45a0528000 rw-p 00000000 00:00 0
7f45a0528000-7f45a6a52000 r--p 00000000 fd:00 50336362 /usr/lib/locale/locale-archive
7f45a6a52000-7f45a6ab2000 r-xp 00000000 fd:00 22554 /usr/lib64/libpcre.so.1.2.0
7f45a6ab2000-7f45a6cb2000 ---p 00060000 fd:00 22554 /usr/lib64/libpcre.so.1.2.0
7f45a6cb2000-7f45a6cb3000 r--p 00060000 fd:00 22554 /usr/lib64/libpcre.so.1.2.0
7f45a6cb3000-7f45a6cb4000 rw-p 00061000 fd:00 22554 /usr/lib64/libpcre.so.1.2.0
7f45a6cb4000-7f45a6cd8000 r-xp 00000000 fd:00 40935 /usr/lib64/libselinux.so.1
7f45a6cd8000-7f45a6ed7000 ---p 00024000 fd:00 40935 /usr/lib64/libselinux.so.1
7f45a6ed7000-7f45a6ed8000 r--p 00023000 fd:00 40935 /usr/lib64/libselinux.so.1
7f45a6ed8000-7f45a6ed9000 rw-p 00024000 fd:00 40935 /usr/lib64/libselinux.so.1
7f45a6ed9000-7f45a6edb000 rw-p 00000000 00:00 0
7f45a6edb000-7f45a6ef2000 r-xp 00000000 fd:00 22495 /usr/lib64/libpthread-2.17.so
7f45a6ef2000-7f45a70f1000 ---p 00017000 fd:00 22495 /usr/lib64/libpthread-2.17.so
7f45a70f1000-7f45a70f2000 r--p 00016000 fd:00 22495 /usr/lib64/libpthread-2.17.so
7f45a70f2000-7f45a70f3000 rw-p 00017000 fd:00 22495 /usr/lib64/libpthread-2.17.so
7f45a70f3000-7f45a70f7000 rw-p 00000000 00:00 0
7f45a70f7000-7f45a710d000 r-xp 00000000 fd:00 22497 /usr/lib64/libresolv-2.17.so
7f45a710d000-7f45a730c000 ---p 00016000 fd:00 22497 /usr/lib64/libresolv-2.17.so
7f45a730c000-7f45a730d000 r--p 00015000 fd:00 22497 /usr/lib64/libresolv-2.17.so
7f45a730d000-7f45a730e000 rw-p 00016000 fd:00 22497 /usr/lib64/libresolv-2.17.so
7f45a730e000-7f45a7310000 rw-p 00000000 00:00 0
7f45a7310000-7f45a7313000 r-xp 00000000 fd:00 62649 /usr/lib64/libkeyutils.so.1.5
7f45a7313000-7f45a7512000 ---p 00003000 fd:00 62649 /usr/lib64/libkeyutils.so.1.5
7f45a7512000-7f45a7513000 r--p 00002000 fd:00 62649 /usr/lib64/libkeyutils.so.1.5
7f45a7513000-7f45a7514000 rw-p 00003000 fd:00 62649 /usr/lib64/libkeyutils.so.1.5
7f45a7514000-7f45a7522000 r-xp 00000000 fd:00 321861 /usr/lib64/libkrb5support.so.0.1
7f45a7522000-7f45a7722000 ---p 0000e000 fd:00 321861 /usr/lib64/libkrb5support.so.0.1
7f45a7722000-7f45a7723000 r--p 0000e000 fd:00 321861 /usr/lib64/libkrb5support.so.0.1
7f45a7723000-7f45a7724000 rw-p 0000f000 fd:00 321861 /usr/lib64/libkrb5support.so.0.1
7f45a7724000-7f45a7739000 r-xp 00000000 fd:00 40937 /usr/lib64/libz.so.1.2.7
7f45a7739000-7f45a7938000 ---p 00015000 fd:00 40937 /usr/lib64/libz.so.1.2.7
7f45a7938000-7f45a7939000 r--p 00014000 fd:00 40937 /usr/lib64/libz.so.1.2.7
7f45a7939000-7f45a793a000 rw-p 00015000 fd:00 40937 /usr/lib64/libz.so.1.2.7
7f45a793a000-7f45a793c000 r-xp 00000000 fd:00 22475 /usr/lib64/libdl-2.17.so
7f45a793c000-7f45a7b3c000 ---p 00002000 fd:00 22475 /usr/lib64/libdl-2.17.so
7f45a7b3c000-7f45a7b3d000 r--p 00002000 fd:00 22475 /usr/lib64/libdl-2.17.so
7f45a7b3d000-7f45a7b3e000 rw-p 00003000 fd:00 22475 /usr/lib64/libdl-2.17.so
7f45a7b3e000-7f45a7d74000 r-xp 00000000 fd:00 303887 /usr/lib64/libcrypto.so.1.0.2k
7f45a7d74000-7f45a7f74000 ---p 00236000 fd:00 303887 /usr/lib64/libcrypto.so.1.0.2k
7f45a7f74000-7f45a7f90000 r--p 00236000 fd:00 303887 /usr/lib64/libcrypto.so.1.0.2k
7f45a7f90000-7f45a7f9d000 rw-p 00252000 fd:00 303887 /usr/lib64/libcrypto.so.1.0.2k
7f45a7f9d000-7f45a7fa1000 rw-p 00000000 00:00 0
7f45a7fa1000-7f45a7fd2000 r-xp 00000000 fd:00 321856 /usr/lib64/libk5crypto.so.3.1
Abandon [sorry, French locale]
Logbook contains 445 entries (shown in ELOG window), 384 files and 4 folders (2017 to 2020).
Thanks for help as i start to be annoying to unuse search function.
|