ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66189
|
Wed Feb 4 18:46:58 2009 |
| Edmundo T Rodriguez | edrodrig@chpnet.org | Request | Linux | 2.7.5 | Re: frequent crashes on SL4 | > ------
>
> 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. |
66188
|
Wed Feb 4 18:08:42 2009 |
| Devin Bougie | dab66@cornell.edu | Request | Linux | 2.7.5 | frequent crashes on SL4 | 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 |
66187
|
Mon Feb 2 10:08:17 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.7.5-2130 | Re: Error Message in HTML or Java Script alert |
Carsten Elftmann wrote: |
Stefan Ritt wrote: |
Carsten Elftmann wrote: |
I have there a problem with the error message at required attributes.
I have two logbooks with identical settings,
in one the errror message appears as Javascript Alert,
in the other one as html-page, and after using the back button the entered text disapear.
Same I have in this forum.
|
Can you describe what you exactly enter in this forum to produce the error so that I can reproduce it?
|
I could not produce this error here again, so I work on that:
There was a attribute with Type = Date, Preset = $Date.
This added following js code
for (var i=0 ; i<document.form1.y0.value.length ; i++) if ((document.form1.y0.value.charAt(i) < "0" || document.form1.y0.value.charAt(i) > "9")) { break }
This cause in following error
Fehler: document.form1.y0 is undefined Quelldatei: http://elog1.bkitech.de/Test-Maengelbericht/?cmd=Neu Zeile: 16
After that error none js will be executed.
After remarking the Type line, all work well.
|
I tried with following minimal configuration file:
Attributes = D, Author, Subject
Type D = Date
Preset D = $Date
and it worked fine. The form contains a field:
Year: <input type="text" size=5 maxlength=5 name="y0">
which contains the name "y0" and therefore produced no error. Can you try with that configuration and see which difference to your configuration causes the error to appear? |
66186
|
Mon Feb 2 09:46:24 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.7.5-2168 | Re: Incrementation of attribute is not functioning, help needed to fix this. |
Guido Böing wrote: |
I appear to be doing something wrong or not..
In my configuration I use an incrementation of a certain attribute (Melding)
For some weird reason it won't increment in this place, while it does in another place...
Below is my configuration (at least the part that gives me headaches..)
[Onderhoud Diversen]
Theme = default
Attributes = Melding, Auteur, Type, Planning, Categorie, Status, Onderwerp
Options Type = Preventief, Regulier, Nav Storing, Overig
Options Categorie = SensorProbes, Overig
Options Status = Wachtend, Gepland, In behandeling, Update, Afgerond
Type Planning = date
Extendable Options = Categorie, Status
Required Attributes = Auteur, Type, Unit-Lokatie, Status
Page Title = ELOG - $onderwerp
Reverse sort = 1
Quick filter = Date, Type, Status
Preset Melding= DIVOH: %d%m%y-####
Subst on edit Auteur = $long_name
List Display = ID, Melding, Datum, Status, Auteur, Type, Planning, Categorie, Onderwerp
Summary lines = 0
Display Email recipients = 0
Email All = aapie@sukkeltje.com
Use Email Subject = $Melding, $Onderwerp - $Status
Style Status In behandeling = background-color:red
Style Status Update = background-color:orange
Style Status Afgerond = background-color:lime
Login user = person1, person2
|
I tried your configuration and got the attribute incrementing correctly:
so I'm a bit at a loss, too. Maybe your browser caches the old page, so try a "Reload" on your browser or clear your cache. Maybe your logbook contains some weird entries which make the incementing break. Try this configuration with an empty logbook. Certainly the configuration options are correct. |
66185
|
Wed Jan 28 18:30:03 2009 |
| Guido Böing | guido.boing@haarlemmermeer.nl | Question | Windows | 2.7.5-2168 | Incrementation of attribute is not functioning, help needed to fix this. |
Hello all,
I appear to be doing something wrong or not..
In my configuration I use an incrementation of a certain attribute (Melding)
For some weird reason it won't increment in this place, while it does in another place...
Below is my configuration (at least the part that gives me headaches..)
[Onderhoud Diversen]
Theme = default
Attributes = Melding, Auteur, Type, Planning, Categorie, Status, Onderwerp
Options Type = Preventief, Regulier, Nav Storing, Overig
Options Categorie = SensorProbes, Overig
Options Status = Wachtend, Gepland, In behandeling, Update, Afgerond
Type Planning = date
Extendable Options = Categorie, Status
Required Attributes = Auteur, Type, Unit-Lokatie, Status
Page Title = ELOG - $onderwerp
Reverse sort = 1
Quick filter = Date, Type, Status
Preset Melding= DIVOH: %d%m%y-####
Subst on edit Auteur = $long_name
List Display = ID, Melding, Datum, Status, Auteur, Type, Planning, Categorie, Onderwerp
Summary lines = 0
Display Email recipients = 0
Email All = aapie@sukkeltje.com
Use Email Subject = $Melding, $Onderwerp - $Status
Style Status In behandeling = background-color:red
Style Status Update = background-color:orange
Style Status Afgerond = background-color:lime
Login user = person1, person2
The goal of this part of the configuration is a way to notify and log maintenance on not specified equipment.
I expect a message-tag with: DIVOH: 280109-0001, where 280109 stands for 28th of January, 2009, the 0001 is the message number of that day.
Now when I enter something in it, submit the message it will display DIV-OH: 280109-0001 as I expect, but...
When I start with a new entry I would expect DIVOH: 280109-0002 as it is the second message.. Well, simply put.. I don't get DIVOH: 280109-0002 but instead I get DIVOH: 280109-0001 again.Below the part that does work correctly:
The following part of my configuration does work..
[Onderhoud Windows]
Theme = default
Attributes = Melding, Auteur, Type, Planning, Categorie, Status, Onderwerp
Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other
Options Categorie = Algemeen, Hardware, Software, Netwerk, Telefonie, Overig
Options Status = Wachtend, Gepland, In behandeling, Update, Opgelost
Type Planning = date
Extendable Options = Categorie, Status
Required Attributes = Auteur, Type, Status
Page Title = ELOG - $onderwerp
Reverse sort = 1
Quick filter = Date, Type, Status
Preset Melding= WSOH: %d%m%y-####
Subst on edit Auteur = $long_name
List Display = ID, Melding, Datum, Status, Auteur, Type, Planning, Categorie, Onderwerp
Summary lines = 0
Style Status In behandeling = background-color:red
Style Status Update = background-color:orange
Style Status Afgerond = background-color:lime
When I copy this one, adjust it to be the same as the first one, but then without the extra things it doesn't work, and with them, well.. it still won't.. :(
I am at a loss here where the mistake is, can someone shed some light on this? I would appreciate that very much.
Best regards,
Guido
|
66184
|
Wed Jan 28 14:39:56 2009 |
| Michael Ambrus | ambrmi09@gmail.com | Bug report | Windows | 2.7.5 | Re: Stack error when email notification is active |
Stefan Ritt wrote: |
Michael Ambrus wrote: |
Michael Ambrus wrote: |
Stefan Ritt wrote: |
Michael Ambrus wrote: |
Stack error is caused when an entry is submitted in a e-mail notification enabled log when a new entry is submitted. This error does not happen on linux (same Elog version, same config file).
Please let me know if there is anything I can do to help.
-----------------------------2916890032591
Content-Disposition: form-data; name="attfile"; filename=""
Content-Type: application/octet-stream
-----------------------------2916890032591--
timezone: 0, offset: 0
6 [main] elogd 2816 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)
Segmentation fault (core dumped)
|
Cygwin is not officially supported. Can you try the Windows binaries?
|
Sorry, I didn't know there were any (I've not used Elog for years and I think Cygwin was the only way back then). Tried them now and they seem to work. At least no stack error is caused. I'm getting some other error, but I think it's the handshake with the SMTP. I'll validate it's OK until tomorrow.
Windows binaries also solved the issue with the "Top grop" in my other bug rapport.
Thanks for the help!
|
Unfortunately can't validate this right now. I'm at a remote network trying to get ELOG on my Windows laptop working with e-mail notifications. Either my normal ISP will not allow the SMTP to accept relaying from external networks, or something else is wrong.
The Windows binary is behaving somewhat differently, it seems to behave like earlier versions. I.e. the error message seen on the browser (Error sending Email via "smtp.xxx.xxx") is very limited. Logging (level 6) will not revile much and -v doesn't output any hints either. Assuming the first possible cause, I registered a account at gmail to try see if their SMTP would allow e-mail relaying. Trying with the Windows binary version I seemingly leads to the same result (i.e. I don't see much and the error seen at the browser is the same). However, when trying to run ELOG on a machine at my home network the message is different:
Error sending Email via "smtp.gmail.com": 5.7.0 Must issue a STARTTLS command first. w40sm7583927ugc.6
The message does not surprise me (from previous experience, TLS was what made made postfix complicated to set up too). But what does surprise me is that the messages differ between the two (ELOG V2.7.5 running on a Linux machine and the Windows binary of the same version). Does Linux/Windows versions differ by conditionals in the code or did I somehow get an older Windows binary?
It would also be helpful knowing if ayone has got ELOG working with smtp.gmail.com.
Regards /Michael
|
The Windows Binaries are not recompiled for each minor modification. You should check the SVN revistion (the number which shows up at the very bottom of the page, which is 2153 in this case). It might well be that the Windows Binaries do not yet contain the modification for extended SMTP error report.
Furthermore, TLS is not supported in elogd, only plain SMTP is possible.
|
Thanks for the info, it saves me some time know this on beforehand.
You're right about the Windows binary, it's a lower SVN revision (2140).
|
66183
|
Wed Jan 28 14:38:52 2009 |
| Michael Ambrus | ambrmi09@gmail.com | Bug report | Windows | 2.7.5 | Re: Stack error when email notification is active |
Stefan Ritt wrote: |
Michael Ambrus wrote: |
Michael Ambrus wrote: |
Stefan Ritt wrote: |
Michael Ambrus wrote: |
Stack error is caused when an entry is submitted in a e-mail notification enabled log when a new entry is submitted. This error does not happen on linux (same Elog version, same config file).
Please let me know if there is anything I can do to help.
-----------------------------2916890032591
Content-Disposition: form-data; name="attfile"; filename=""
Content-Type: application/octet-stream
-----------------------------2916890032591--
timezone: 0, offset: 0
6 [main] elogd 2816 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)
Segmentation fault (core dumped)
|
Cygwin is not officially supported. Can you try the Windows binaries?
|
Sorry, I didn't know there were any (I've not used Elog for years and I think Cygwin was the only way back then). Tried them now and they seem to work. At least no stack error is caused. I'm getting some other error, but I think it's the handshake with the SMTP. I'll validate it's OK until tomorrow.
Windows binaries also solved the issue with the "Top grop" in my other bug rapport.
Thanks for the help!
|
Unfortunately can't validate this right now. I'm at a remote network trying to get ELOG on my Windows laptop working with e-mail notifications. Either my normal ISP will not allow the SMTP to accept relaying from external networks, or something else is wrong.
The Windows binary is behaving somewhat differently, it seems to behave like earlier versions. I.e. the error message seen on the browser (Error sending Email via "smtp.xxx.xxx") is very limited. Logging (level 6) will not revile much and -v doesn't output any hints either. Assuming the first possible cause, I registered a account at gmail to try see if their SMTP would allow e-mail relaying. Trying with the Windows binary version I seemingly leads to the same result (i.e. I don't see much and the error seen at the browser is the same). However, when trying to run ELOG on a machine at my home network the message is different:
Error sending Email via "smtp.gmail.com": 5.7.0 Must issue a STARTTLS command first. w40sm7583927ugc.6
The message does not surprise me (from previous experience, TLS was what made made postfix complicated to set up too). But what does surprise me is that the messages differ between the two (ELOG V2.7.5 running on a Linux machine and the Windows binary of the same version). Does Linux/Windows versions differ by conditionals in the code or did I somehow get an older Windows binary?
It would also be helpful knowing if ayone has got ELOG working with smtp.gmail.com.
Regards /Michael
|
The Windows Binaries are not recompiled for each minor modification. You should check the SVN revistion (the number which shows up at the very bottom of the page, which is 2153 in this case). It might well be that the Windows Binaries do not yet contain the modification for extended SMTP error report.
Furthermore, TLS is not supported in elogd, only plain SMTP is possible.
|
Thanks for the info, it saves me some time know this on beforehand.
You're right about the Windows binary, it's a lower SVN revision (2140).
|
66182
|
Tue Jan 27 17:29:24 2009 |
| Mike Forster | mike4ster@gmail.com | Question | Linux | 2-7-5 | Re: Last day -- list menu command |
Stefan Ritt wrote: |
Mike Forster wrote: |
Hi folks,
I want to have Last day be a command in the List display, so I added:
List menu commands = New, Find, Import, Login, Logout, Config, Last day, Help
However, when Last day is selected, the command does not change to Last 2 days.
What is the right way to do this?
|
You have to put "Last x" in the menu, not "Last day". Unfortunately by default the label "Last day" does not show up. I fixed this in the current version. But you can yourself start this thing by adding "past1" to the URL, or by making yourself a bookmark in your browser. Like
https://midas.psi.ch/elogs/Forum/past1
then the "Last 2 days" will show up.
|
Thanks very much, Stefan.
I did not know "Last x" was the appropriate menu option.
--Mike |
|