| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
67070
|
Mon May 30 12:28:53 2011 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 2.9.0-2414 | elogd crashes when running mirror cron with SSL and KRB5 | When I run a mirror server and both logbooks using SSL/KRB5 then the cron job causes a segmentation fault.
I haven't tried to check it with a simple configuration yet.
My set-up: two elogd on same server, one running "german" on port 444, the other "english" on port 445.
Both are behind an apache webserver configured reverse proxy, to hide the ports for external access.
I'll try to reproduce the fault with a "minimal configuration" soon and report again.
Debug output from GDB:
run -x -c /usr/local/elog/elogd_en.cfg
Starting program: /opt/elog-2.9.0/elog/elogd -x -c /usr/local/elog/elogd_en.cfg
elogd 2.9.0 built May 30 2011, 11:14:32 revision 2414
File "/var/run/elogd.pid" exists, using "/var/run/elogd.pid.445" instead.
Falling back to default group "elog"
Falling back to default user "elog"
User "elog" not found
Falling back to default user "nobody"
FCKedit detected
Falling back to default group "elog"
Falling back to default user "elog"
User "elog" not found
Falling back to default user "nobody"
ImageMagick detected
Indexing logbooks ... done
SSLServer listening on port 445 ...
Program received signal SIGSEGV, Segmentation fault.
0x0030b7b5 in SSL_write () from /lib/libssl.so.6 |
|
67069
|
Fri May 20 22:45:00 2011 |
 | John M O'Donnell | odonnell@lanl.gov | Bug fix | Linux | svn 2414 | my_shell (OS_UNIX) uses /tmp/elog_shell - conflict when more than one elogd runs at the same time | all instances of elogd use the same file name in /tmp when calling my_shell. This can cause some inconsistent behavior when two or more copies of elogd are runnnig at the same time. (eg. one might detect ImageMagik is installed, and the other not,)
The propsed solution is to have the parent read from a pipe to the child rather from a file. A patch is attached. |
| Attachment 1: elogd.c.patch_shellPipe
|
--- elogd.c.orig 2011-05-20 13:28:48.000000000 -0600
+++ elogd.c 2011-05-20 14:16:12.000000000 -0600
@@ -866,25 +866,27 @@
#ifdef OS_UNIX
pid_t child_pid;
- int fh, status, i;
+ int fd[2], status, i;
char str[256];
+ /* create pipe for parent<->child communication */
+ if (pipe(fd) < 0)
+ return 0;
+
if ((child_pid = fork()) < 0)
return 0;
else if (child_pid > 0) {
- /* parent process waits for child */
- waitpid(child_pid, &status, 0);
+
+ /* parent does not write to child */
+ close(fd[1]);
/* read back result */
memset(result, 0, size);
- fh = open("/tmp/elog-shell", O_RDONLY);
- if (fh > 0) {
- i = read(fh, result, size);
- close(fh);
- }
+ i = read(fd[0], result, size);
+ close(fd[0]);
- /* remove temporary file */
- remove("/tmp/elog-shell");
+ /* parent process waits for child */
+ waitpid(child_pid, &status, 0);
/* strip trailing CR/LF */
while (strlen(result) > 0 && (result[strlen(result) - 1] == '\r' || result[strlen(result) - 1] == '\n'))
@@ -926,8 +928,7 @@
eprintf("Falling back to user \"%s\"\n", str);
}
- /* execute shell with redirection to /tmp/elog-shell */
- sprintf(str, "/bin/sh -c \"%s\" > /tmp/elog-shell 2>&1", cmd);
+ /* execute command with redirection to pipe to parent */
if (is_verbose()) {
efputs("Going to execute: ");
@@ -935,7 +936,17 @@
efputs("\n");
}
- system(str);
+ /* redirect stdout/stderr to pipe for parent to read */
+ close(STDOUT_FILENO); dup2(fd[1], STDOUT_FILENO);
+ close(STDERR_FILENO); dup2(fd[1], STDERR_FILENO);
+ /* child does not read the pipe */
+ close(fd[0]);
+ /* child nolonger uses fd[1] - use stderr or stdout instead */
+ close(fd[1]);
+
+ if (system(cmd) == -1) {
+ fprintf(stderr, "unable to execute command: %s\n", cmd);
+ }
_exit(0);
}
|
|
67068
|
Tue May 17 17:00:03 2011 |
 | Olivier Callot | Olivier.Callot@cern.ch | Bug report | All | 2.9.0 | Re: Self Register = 3 doesn't work any longer |
| Stefan Ritt wrote: |
|
| Olivier Callot wrote: |
|
Dear Stefan, after a long time I managed to get a test setup. The line that creates the misbehaviour is
Guest Menu Commands = List, Find, Login, Help
which seems inocuous! But with this line a user with inactive account can login without validation. Without this line I get also the proper web page indicating that the account has to be activated when I register as new user.
Another little annoyance: When a user is prevented from login ("The account is currently deactivated") there is NO WAY to login, as any action with Elog tries to use the (non activated) username and password. I can't get back the login page!
Thanks
|
Great. This this description I could reproduce the error and fix it. The fix is in SVN revision 2414.
Cheers, Stefan.
|
If you could also obtain the display of the message "Your request has been forwarded to the administrator.You will be notified by email upon activation of your new account." when a new user apply in the presence of the Guest Menu commands, that would be perfect. Cheers |
|
67067
|
Tue May 17 16:37:42 2011 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.9.0 | Re: Self Register = 3 doesn't work any longer |
| Olivier Callot wrote: |
|
Dear Stefan, after a long time I managed to get a test setup. The line that creates the misbehaviour is
Guest Menu Commands = List, Find, Login, Help
which seems inocuous! But with this line a user with inactive account can login without validation. Without this line I get also the proper web page indicating that the account has to be activated when I register as new user.
Another little annoyance: When a user is prevented from login ("The account is currently deactivated") there is NO WAY to login, as any action with Elog tries to use the (non activated) username and password. I can't get back the login page!
Thanks
|
Great. This this description I could reproduce the error and fix it. The fix is in SVN revision 2414.
Cheers, Stefan. |
|
67066
|
Tue May 17 13:19:03 2011 |
| Olivier Callot | Olivier.Callot@cern.ch | Bug report | All | 2.9.0 | Re: Self Register = 3 doesn't work any longer |
| Stefan Ritt wrote: |
|
| Olivier Callot wrote: |
|
I tried again and confirm the version number. I never got this pannel saying that my request will be processed by an adminstrator. Maybe the installation was incomplete? Is this pannel outside the standard src files? I receive the mail as administrator, but the accout is already valid BEFORE I validate it.
This was working in previous versions, i.e. the entry was not created at all. And login wasn't possible.
We went back to 2.8.0 as the server is regularly crashing with 2.9.0 and we have to keep it alive for our running experiment. We are trying to isolate and reproduce the problem...
|
Try to use the simple config file, and see what happens there. Maybe it's a config option you use differently in the experiment. If you identify the config option which triggers the problem, I can probably reproduce it and fix it. Concerning crashes of 2.9.0: We have it running stably for our experiments, that's why I released it. But there are major changes since 2.8.0, mainly the Kerberos authentification (actually people from CERN asked for that). So it could be that in your case there are problems I don't see. In that case you have to test with which options in the config file the problems start. If elogd crashes, a stack dump would maybe also be helpful for me.
|
Dear Stefan, after a long time I managed to get a test setup. The line that creates the misbehaviour is
Guest Menu Commands = List, Find, Login, Help
which seems inocuous! But with this line a user with inactive account can login without validation. Without this line I get also the proper web page indicating that the account has to be activated when I register as new user.
Another little annoyance: When a user is prevented from login ("The account is currently deactivated") there is NO WAY to login, as any action with Elog tries to use the (non activated) username and password. I can't get back the login page!
Thanks |
|
67065
|
Sun May 8 22:33:15 2011 |
| Ryan | ryan.hoitt@intelsat.com | Bug report | Linux | 2.9.0 | Re: elog 2.8.0 as daemon crashes when editing selected threaded list |
| Mark Bergman wrote: |
|
| Mark Bergman wrote: |
|
I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".
Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.
However, if eLog is run with "-v" in place of "-D", it does not crash.
Environment:
CentOS 5.4
eLog 2.8.0 built Aug 5 2010, 12:24:11
|
I'm now running eLog 2.9.0 and seeing the same crashes. However, I've got some more information that may be helpful.
The crash seems to be directly related to the order of replies in the thread. For example, in this thread I am replying to the original entry. The original entry has 2 children (the entries are siblings) and no grandchildren.
In our installation, eLog crashes consistently under the following conditions:
go to the "list" display
set it to "threaded"
"select" a thread that has siblings at any generation of replies
choose "edit"
If the selected thread only has one entry at any generation, eLog does not crash.
Here's a horrible attempt at a display of two message threads. Note that in the first example, there are 2 replies at the same generation (siblings)--both the person who responded and the original submitter replied to the initial submission. After that, all replies were to successive generations.
-------------- Causes eLog to Crash ------------------
! Full Name (submitter) module failure
=> Full Name (submitter) Re: module failure
=> Full Name (replier) Re: module failure
=> Full Name (submitter) Re: Re: module failure
&nb sp; => Full Name (submitter) Re: Re: Re: module failue
------------------------------------------------------
-------------- No eLog Problem ------------------
! Full Name (submitter) Labwide failure of mcc
=> Full Name (replier) Re: Labwide failure of mcc
=> Full Name (submitter) Re: Re: Labwide failure of mcc
&nb sp; => Full Name (replier) Re: Re: Re: Labwide failure of mcc
------------------------------------------------------
|
I am also experiencing the same exact problem as explained above. It only seems to happen when a part of the title has changed. I will include my config for an example. Make a few entries, then change the "Customer" paramater. Then try and edit an entry in the thread.
Enable attachments = 1
Attributes = Employee, Customer, XXX-ID, XXXX Number, SCD, Type, Status, Folder Created, XXXX Received, Equipment Installed, XXX Carrier Up, Customer Carrier Up, QA Completed
Thread display = $Customer - $SLR-ID - $Type - $Status - SCD: $SCD - XXXX: $XXXX Number
Propagate attributes = Status
Locked Attributes = Employee
Options Type = Activation, Termination, Change
Options Folder Created = Yes, No, N/A
Options XXXX Received = Yes, No, N/A
Options Equipment Installed = Yes, No, N/A
Options XXX Carrier Up = Yes, No, N/A
Options Customer Carrier Up = Yes, No, N/A
Options QA Completed = Yes, No
Entries per page = 100
Preset Text = $short_name @ $utcdate -
Append on reply = $short_name @ $utcdate -
Locked Attributes = Employee
Preset Employee = $long_name
Options Status = Open, Closed
Quick Filter = Status, Type
Type SCD = datetime
Summary lines = 0
Enable Attachments = 0
Suppress default = 2
Entries per page = 10
Suppress Email to users = 1
Display mode = threaded
Collapse to last = 1
Expand default = 0
Subst on reply Employee = $long_name
Faulting application elogd.exe, version 0.0.0.0, faulting module elogd.exe, version 0.0.0.0, fault address 0x000646c7. |
|
67064
|
Tue May 3 20:05:29 2011 |
 | Andreas Warburton | andreas.warburton@gmail.com | Question | Linux | Mac OSX | 2.9.0-2396 | Unwanted faux DST date shifts to time stamps in mirror transactions | Hi,
I have a MacOSX 10.6.7 laptop that periodically synchronizes my logbook with that on a Debian linux web server. Both instances of ELOG are 2.9.0-2396.
When I create a new entry on the laptop, the indicated time stamp is correct. When I click Synchronize on the laptop, the entry that gets mirrored to the Debian server has a time stamp exactly one hour earlier (in the past) on the Debian side.
Likewise, when I create a new entry on the Debian server, the indicated time stamp is correct. When I click Synchronize on the laptop, the entry that gets mirrored from the Debian machine to the laptop has a time stamp that is exactly one hour in the future on the laptop.
This appears to be due to an incorrect handling of times with regard to "summer" (daylight savings) and "standard" time when mirroring between these two different machines.
Is there a straightforward workaround to immunize against this sensitivity?
Thanks!
Andreas
|
|
67063
|
Tue May 3 17:35:57 2011 |
| Soren Poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.9.0-2413 | Re: ELOG deamon stuck in find_thread_head() |
| soren poulsen wrote: |
|
ELOG seems to enter a loop when you do certain opeations on certain messages: I moved a message to a different logbook and the deamon just gets stuck.
If I restart the daemon, the message was in fact moved: I can move it back to its original destination without problems.
I started in GDB and break with ctrl-C when the process gets stuck, to be told :
Program received signal SIGINT, Interrupt.
0x000000000040a968 in find_thread_head ()
I then made a core dump.
I put the files here: http://cern.ch/poulsen2/elog-error-report-110430.zip (they are too big to upload).
I get into the same problem in other circumstances such as when opening some threads (maybe because they contain "Reply-to" references to non-existing messages, but I have problems reproducing this on the test installation.
I should maybe also submit the incriminating thread.
Soren
|
1. It appears that some times find_thread_head is called with message references that do not exist. That is not good.
I put in a little check like this before seeing if the message has an "in_reply_to" reference:
The line:
if (lbs->el_index[i].in_reply_to)
becomes:
if (i < *lbs->n_el_index && lbs->el_index[i].in_reply_to)
2. The trouble started when I deleted a message in the middle of a thread, which left the thread badly "connected" (references to a deleted message).
3. Also, when a thread is badly connected, it is a problem moving messages to a different logbook. ELOG complains that it cannot access the message (with the invalid reference). But ELOG should ignore it, since the message was deleted.
Soren |
|