Select -> Edit wipes dates, posted by T. Ribbrock on Mon Oct 27 12:42:47 2008
|
I just ran into the following bug:
I have a logbook where entries have several attributes, among which several dates. All of these are set to "Type <attr> = date". If I use the "Select" action, tag several entries and subsequently chose "Edit", the values of all date attributes are wiped. All other attributes are kept at their original values, unless changed explicitly. For the date entries, the date choosers are shown (as when editing a single entry), but all set to blank.
Editing single entries works fine. |
Installation problems, posted by George B. on Mon Oct 27 13:05:13 2008
|
Hello,
I just upgraded to elog 2.7.5 from 2.6.4 on my Debian system. Here is some feedback:
1) "make" fails if libssl-dev package is not installed. Documentation does not mention SSL library requirements.
2) /etc/init.d/elogd: line 10: /etc/rc.d/init.d/functions: No such file or directory (I fixed this by commenting
out that line).
3) Starting elogd: /etc/init.d/elogd: line 34: echo_success: command not found (Fixed by search/replace "echo_"
to "echo ").
Hope this helps.
George. |
Re: Maximum number of mail recipients, posted by Stefan Ritt on Wed Oct 29 05:25:12 2008
|
| Steve Nahn wrote: |
|
Just wondering if there is still a maximum number of mail recipients? I saw a number of 112 floating around in old forum entries, and I need more, like currently 300. When I try it, the elogd hangs, not much output to speak of, but won't reply to Apache on its port. Any quick fix (like changing a def'd variable somewhere?)
|
No quick fix, sorry. It is also limited by a fixed number of characters per line in the configuration file and many more. I will try to increase it, but it will take time. Can you maybe set-up a mailing list at your email server? This way you send only email to one destination and it gets distributed to many people. |
|
Re: Installation problems, posted by Stefan Ritt on Wed Oct 29 05:53:39 2008
|
> 1) "make" fails if libssl-dev package is not installed. Documentation does not mention SSL library requirements.
I added a note to the documentation, thank you.
> 2) /etc/init.d/elogd: line 10: /etc/rc.d/init.d/functions: No such file or directory (I fixed this by commenting
> out that line).
>
> 3) Starting elogd: /etc/init.d/elogd: line 34: echo_success: command not found (Fixed by search/replace "echo_"
> to "echo ").
The elogd (or elogd.init in the distribution) is written for RedHat based systems where echo_success gives the
typical output with a green [OK] at the end of the line. For Debian, there is (was) in principle a Debian package
which has it's own startup script. Since the package maintainer is not active any more (I guess), the Debian
updates are heavily old. Once elog gets managed inside Debian again, that should get better again, but until then
one has to follow 2) and 3) from above. If I would remove it, the Scientific Linux users would complain. |
|
Re: Elogd crashes, posted by Stefan Ritt on Wed Oct 29 07:07:47 2008
|
| soren poulsen wrote: |
|
Dear Stefan,
Thanks for your reply.
I started running elog in February and it never failed. Then it started failing regularly towards the end of September. There were no system changes until then, except the daily automatic Yum updates (SLC4). Then I upgraded to the latest version (tar ball of 2.7.5). Then yesterday it crashed again. I saw that it crashed around the time when a user was doing something - inputting new data. I can monitor when it crashes and correlate it with user activity. But it is not easy to reproduce since I don't know exactly what the user is typing.
It would be necessary to record the user input forms and then replay them against a known server state. But that is not so easy.
I will think about doing something else - maybe running inside a debugger as you suggest.
|
Just run it inside gdb. When it crashes, you will see a segment violation and you will end up at the debugger prompt. Then do a "bt" to see the stack dump. From that I can guess where the problem happens.
|
|
Re: elogd crashes when creating new logbook using existing logbook as template, posted by Stefan Ritt on Thu Oct 30 03:10:00 2008
|
> elogd is crashing with a segv when I try to create a new logbook by clicking the "Create new logbook" button
> with an existing logbook selected in the dropdown list as a template. I've attached my config file for
> reference. As a specific example, I'm logged in as the admin user, viewing logbook "1248", which has no entries,
> and I click "Config" -> "Change config file" -> "Create new logbook", Select "1248" from dropdown list, enter
> "1250" for the new logbook name, and click "Create new logbook".
>
> The server crashes, and my web browser has the following as the (incorrect) URL it's trying to load:
> (Incorrect because the "/ATLAS" shouldn't be there.)
>
> https://localhost:8080/ATLAS/1250/?cmd=Config
>
> Nevertheless, the config file and logbook directory are properly modified for the new logbook, and on restarting
> the server, everything is fine.
>
> Oh, just noticed that if I manually enter the URL:
>
> https://localhost:8080/ATLAS/1250/
>
> or actually, any text in place of the "1250", it also crashes the elogd process. So, perhaps there are two bugs?
>
> (1) Incorrect URL being given to the web client after logbook creation
> (2) Requesting any incorrect URL of this form crashes elogd
This problems have been fixed in SVN revision 2135. |
|
Re: Error Message During Uploads, posted by Stefan Ritt on Thu Oct 30 04:33:43 2008
|
| Kevin O'Sullivan wrote: |
|
We've been having toruble with uploads not working and I notice that every time someone uploads to our elog the same error message appears in /var/log/syslog:
Cannot restore original GID/UID.
How can I fix thsi error? Or, perhaps more importantly, could it cause elog to "lock up" (note, it doesn't crash)?
I'm runing elog on Ubuntu kernel version 2.6.24-server.
|
Probably something is wrong with the account under which you run elog. Normally (at least if you install elog from the RPM) you have an account "elog" and group "elog" under which you run elogd. You compile and install elogd under root (so that it can bind to port 80 for example), and then you put
usr = elog
grp = elog
into the configuration file. So when you start elogd, it binds to the server port, then falls down to user "elog" and gives up root privileges. If the elog account for example does not exist, you get the above error message. The only problem I see there is if elog stays as root, it can do more harmful things in case it misbehaves. |
|
Re: Installation problems, posted by George B. on Wed Nov 5 10:32:07 2008
|
> The elogd (or elogd.init in the distribution) is written for RedHat based systems where echo_success gives the
> typical output with a green [OK] at the end of the line. For Debian, there is (was) in principle a Debian package
> which has it's own startup script. Since the package maintainer is not active any more (I guess), the Debian
> updates are heavily old. Once elog gets managed inside Debian again, that should get better again, but until then
> one has to follow 2) and 3) from above. If I would remove it, the Scientific Linux users would complain.
That makes sense. Might be worth adding a short Debian section to the installation instructions page?
FYI, Elog is no longer in Debian as of 2008-05-12.
Thanks,
George. |
|