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: 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: Server derived time, posted by Stefan Ritt on Thu Oct 30 03:30:59 2008
|
| Grant Jeffcote wrote: |
|
Hi Stefan,
Is it possible to derive the time in a 'date/time' attribute from the Elog server?
We would like all our entries in GMT/UTC time and unfortunately as the time is currently derived from the client machines there are often entry descrepancies if the regional settings are not set correctly.
The '$entry time' variable can be used but seems to put a 1970 date in the field so bears no relevancy to an 'Event' time?
I'm also having issues with conditional entries in the Find page. If a conditional statement is used to hide attributes or change displayed attributes in the entry page then the attribute that is used in the conditional statement is not permanently selectable in the 'Find' page. It is available as a choice but as soon as selected the conditional action removes it? Is it possible to make conditional options/actions in the 'Find' page optional?
Hope that makes a little sense?
Many thanks
|
There are several methods to get the server time:
Via presets of attributes
Attributes = Author, Event time, ...
Preset Event time = $utcdate
which gives you actually the UTC time.
Via the editor
The editor toolbar contains a little clock. If you click on it, you insert the current server time (but localized, not UTC).
Hope one of the two methods work for you.
The problem with the conditional attributes in the find page is I believe fixed in the current version. |
Re: Server derived time, posted by Grant Jeffcote on Thu Oct 30 08:39:34 2008
|
| Stefan Ritt wrote: |
|
| Grant Jeffcote wrote: |
|
Hi Stefan,
Is it possible to derive the time in a 'date/time' attribute from the Elog server?
We would like all our entries in GMT/UTC time and unfortunately as the time is currently derived from the client machines there are often entry descrepancies if the regional settings are not set correctly.
The '$entry time' variable can be used but seems to put a 1970 date in the field so bears no relevancy to an 'Event' time?
I'm also having issues with conditional entries in the Find page. If a conditional statement is used to hide attributes or change displayed attributes in the entry page then the attribute that is used in the conditional statement is not permanently selectable in the 'Find' page. It is available as a choice but as soon as selected the conditional action removes it? Is it possible to make conditional options/actions in the 'Find' page optional?
Hope that makes a little sense?
Many thanks
|
There are several methods to get the server time:
Via presets of attributes
Attributes = Author, Event time, ...
Preset Event time = $utcdate
which gives you actually the UTC time.
Via the editor
The editor toolbar contains a little clock. If you click on it, you insert the current server time (but localized, not UTC).
Hope one of the two methods work for you.
The problem with the conditional attributes in the find page is I believe fixed in the current version.
|
Thanks Stefan, the preset UTC date works well. RTFM on my part perhaps. 
I'm running version 2.7.5.2127 and am still having the issue with conditional attributes in the find area as mentioned above though.
Is it the latest SVN **.2135 that addresses this?
Many thanks |
|
Re: Server derived time, posted by Stefan Ritt on Mon Nov 3 13:15:52 2008
|
| Grant Jeffcote wrote: |
|
I'm also having issues with conditional entries in the Find page. If a conditional statement is used to hide attributes or change displayed attributes in the entry page then the attribute that is used in the conditional statement is not permanently selectable in the 'Find' page. It is available as a choice but as soon as selected the conditional action removes it? Is it possible to make conditional options/actions in the 'Find' page optional?
Hope that makes a little sense?
Many thanks
|
Many people want conditional attributes on the find page, so I cannot remove it. Before adding another parameter to disable this optionally, I would like to ask you to first try the "Show attributes edit = ..." option, which is not evaluated in the "find" page. Maybe you can achieve what you want with this option. |
|
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. |
Re: Installation problems, posted by T. Ribbrock on Wed Nov 5 11:52:12 2008 
|
> > 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.
I'm actually using elog on Debian and have been rolling my own ".deb" for a while now (starting with the old Debian
one and working my way up till 2.7.5). Maybe you could add the Debian /etc/init.d/elog script to the "contrib"
directory, with a suitable note in the README or something like that? That script has not changed in a long time and
is still functional - and doing so would make it easier for people who would like to install elog on a Debian (or
Debian-based, e.g. Ubuntu) system. I'll attach the script.
Regards,
Thomas |