Re: elogd does not exit on SIGTERM, posted by Heiko Scheit on Fri Aug 27 00:49:27 2004
|
> Noee. Here it works immediately.
>
> Can you try with a fresh server from the distribution, with the example
> elogd.cfg, to see if there is any difference?
>
> The killing is handled in the funciton ctrlc_handler(), which sets _abort =
> TRUE. This is checked in line 16195, just after the select(), and the main
> loop is exited. The select finishes after one second, although I believe
> that the kill signal also terminates the select prematurely. The kill
> command and a Ctrl-C keystroke should work the same way, they both generate
> a SIGTERM or SIGINT signal.
elogd does not exit if there is an 'unprocessed' HUP. So when you do
kill -HUP <pid>
kill <pid>
elogd will only exit after it was accessed. |
ELOG-Server crashes after date entry, posted by Ulrich Trüssel on Fri Dec 3 08:43:49 2004
|
God really STRANGE and problematic effect on 2.5.5-1 (can't remember it this
was with 2.5.5 or 2.5.4-X but i'm nearly sure it worked well):
Entering a date (Formate Bithday = date) may crash down the server:
Value is 22.2.2004: Everything is well
Value is 22.2.1962: Server crashes emmediatly (menas restarzing several
times, always the same problem)
I do not have time to check true all the years for finding out where the
problem may beginn, sorry. Also I was not able to check on other systems
right now. My system: Win XP Pro SP 1, IE 6 as well as Mozilla Calssic 1.7.3.
Didn't check it under Linux right know in case of a lot work.
Clould you this fix please Stefan??? THANK'X!!! |
Re: images attached shown as inline , posted by Emiliano Gabrielli on Wed Feb 16 08:58:47 2005
|
> > the following should do the job:
> >
> > <div style="width: 200px">
> > <img src="IMG_3133.jpg" style="width: 100%" />
> > </div>
> >
> > the configurable parameter should be with obviously :-)
>
> Unfortunately not. Please find attached the screen dump from such a try, together with the HTML code.
> As you can see, the little elog icon is stretched to the same width as the upper (large) picture.
you are right ;-( I used a different code in my test and sent you and old test code, *but* also the last
one does not works on every browser ... the following code would do the job, but it seems to work only
in gecko-based browsers such as mozilla, firefox and safari ...
<div style="width: 200px">
<img src="IMG_3133.jpg" style="max-width: 200" />
</div>
other browsers do not scale the vertical dimention :-( |
Crash with Protect Selection page = 1, posted by Stephen A. Wood on Thu Mar 24 10:31:01 2005
|
Using 2.5.8, if I set "Protect Selection page" to 1, then elogd seg faults
as soon as it is accessed.
Under 2.5.7, a login page will come up, and the logbook will work, but only
if a valid username/password is given. If an invalid login is given, then
elogd crashes. We have a cron job that periodically restarts elogd if it is
has crashed.
Steve
[global]
logbook tabs = 0
port = 8080
Protect Selection page = 1
Password file = user.info
Admin user = saw
|
Re: wrong handling of attachment names, posted by Emiliano Gabrielli on Thu Mar 24 13:40:27 2005
|
> When an attached image name contains a space in its filename and attachment
> display is enabled elog builds a wrong url to the image:
>
> http://arcolog.roma2.infn.it:8080/ARCO/050309_170709/peeling+002.jpg
>
> instead of the correct one:
>
> http://arcolog.roma2.infn.it:8080/ARCO/050309_170709_peeling+002.jpg
>
> The more annoing thing is that elogs hangs on this. a strace shows a select
> on fd n°3 and 5 that loops forever (returning a timeout error):
>
> send(4, "<141>Mar 23 11:36:25 elogd[22189"..., 35, 0) = 35
> rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
> select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
> select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
>
>
> May be the better solution is, after fixing the bug for backward
> compatibility with already uploaded images, to implement a forced characters
> substitution at upload time, replacing spaces and every character not in a
> "allowed chars" list with an underscore
donno if the following is correlated, otherwise there is another problem I
guess :-)
I attached a strace of elog, hope you'll find it useful.
- Irestarted the daemon
- attached strace to it
- requested the list for a testin logbook, few entries some quite big images
(two thumbnails, the other are old images get resized my the browser)
- repeted previous point a couple of times
- press F5 (mozilla-firefox) the browser hangs 4ever
- stop the load
- repeat point 3, all right
- F5 => hangs
- F5 => hangs
there should be some problem, may be in the socket ? |
Preset text Dont work more!, posted by Alex H on Fri Mar 25 16:00:55 2005
|
Hi,
I'am using Elog V2.5.8-1 and the "Preset Text" option don't work more since
I've updated Elog. could you fix it?
Thanks.
Alex |
Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction, posted by Chris Green on Fri Aug 5 02:27:15 2005
|
Hi,
Just as our ELOG went into production, I tripped over a couple of related (I think) bugs.
First, the easy one: line 21368 of src/elogd.c has a compile warning which looks non-benign. I fixed it in my local copy with:
Index: elogd.c
===================================================================
RCS file: /usr/local/cvsroot/elog/src/elogd.c,v
retrieving revision 1.739
diff -r1.739 elogd.c
21368,21369c21368
< sprintf(str, "?fail=1", user);
< redirect(lbs, str);
---
> redirect(lbs, "?fail=1");
Regardless (ie if I use the original CVS code or the patched version), a hard-to trace problem occurs with my configuration whereby users are denied access after password entry at the logbook selection page (even when details are verifiably correct), and users are dropped through to the next (non-protected) Top Group page. This problem goes away if "Protect Selection Page" is turned off.
A kind of "shadow" of this problem occurs if you create a new logbook from the Change Config File page, whereby after creating the new logbook one is dropped through to the next Top Group's selection page after saving the configuration (and the url has ?fail=1 added to it, althoguh line 21368 above is hardly the only place where this could have occurred).
I think all these things are linked. I'd be grateful if you could review this section of this code for possible causes of these problems. While we can operate for now with non-logged-in users able to see our list of logbooks, that is not something we want for the long term.
Thanks for your help,
Chris. |
Post appearing twice, posted by Dan Chitwood on Fri Sep 23 19:23:26 2005
|
We are having trouble on our logbook with posts appearing twice. Both posts contain the same ID number, time, etc. This most often occurs when the e-log entry is being written for an extended period of time (ie. more than 30 minutes), but I don't know if that is the root cause of the problem. It may also be related to posts that are edited after an initial posting. Could this be due to an improper setting in our config file? |
|