;liste des attributs
Attributes =CR,Serial,EDA,Experience,Lieu,Type,Gain,G1,G2,G3,G4,G5,G6,G7,G8,Intensité,Seuil bas, Seuil haut

; Combine attributes into singles lines
Format G1 = 1,attribgainname,attribvalue,10,10
Format G2 = 1,attribgainname,attribvalue,10,10
Format G3 = 1,attribgainname,attribvalue,10,10
Format G4 = 1,attribgainname,attribvalue,10,10
Format G5 = 1,attribgainname,attribvalue,10,10
Format G6 = 1,attribgainname,attribvalue,10,10
Format G7 = 1,attribgainname,attribvalue,10,10
Format G8 = 1,attribgainname,attribvalue,10,10

.attribgainname {
  width:25px;
  background-color:lime;
  border:1px solid #0000FF;
  border-top:1px solid white;
  border-left:1px solid white;
  padding:3px;
}

I just submitted a reply to elog:847 (the reply is elog:853).
Normally the thead containing the reply should now be listed as
the top thread.  Instead only the original message of the thread
(elog:820) is listed but the remaining messages in the thread are not 
listed.  It seems the problem is that for elog:820 the 'reply to this'
header is missing.  And elog:820 and elog:824 are the same messages
except that for elog:824 the subject is missing.  Actually ALL attributes
for elog:824 are missing.

I guess you could fix things up if you:
- add 'reply to this: 823' to elog:820
- remove entry elog:824

In the Config Examples logbook you mentioned a forum.css.  Do you have a 
link to that css and others?

Thanks

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 

Just compiled 1.410 and have run into an issue that *may* have been
introduced in 1.393.

Config file directives such as "Welcome title" could be very long strings. 
After compiling 1.410, our "Welcome title" is truncated and, while I haven't
counted the actual chars, I suspect that the truncation happens at 1024
characters.  The procedure 'getcfg' has a declared passed paramater "int
vsize". 

I haven't looked to see if this effects any other large configuration
strings that are managed by "getcfg" but this procedure is perhaps the most
popular one by far in elog.

I write my lab journal with pen and though of getting a linux supported tablet. Has anybody ever used ELOG and did input using a tablet?

I am trying to add additional information to the subject of new entries:

Subst subject = $subject [INCIDENT $message id]
Subst on reply subject = Re: $subject
Fixed Attributes Reply = Subject

However, the new entry subject looks like:

this is my subject [INCIDENT this is my subject [INCIDENT $message id]

I'm not sure if there's a problem with the substitution or if this is just not allowed (I'm having LISP flashbacks).

By the way, if I use "Subst on reply subject" I get the behavior I would like but the original entry in the thread doesn't contain the appended data:

Subst on reply subject = Re: $subject [INCIDENT $message id]

Any help would be appreciated.

Alex

Hello;

Could I make change on program only on the " elogd.cfg" ?

Or is there onother files, because I think there is hidden files ?