| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
66029
|
Thu Oct 30 11:05:11 2008 |
 | T. Ribbrock | emgaron+elog@ribbrock.org | Question | All | 2.7.5-2130 | Re: (How) can I hide columns in List view? |
| Stefan Ritt wrote: |
|
[...]
The only way I see how you can achieve what you want is to define two separate logbooks, but serve them from the same directory (via the "Data dir" option). Both logbooks should share the same attribute definition, but use different "List display" options.
|
I take it you mean the "Subdir" option (the manual mentions "Data dir" as obsolete)? I tried it with that and it works like a charm - gives me now two logbooks, i.e. two tabs with the same data and two different views - which is precisely what we need. Thanks!
Regards,
Thomas |
|
66034
|
Wed Nov 5 11:52:12 2008 |
 | T. Ribbrock | emgaron+elog@ribbrock.org | Info | Linux | 2.7.5 | Re: Installation problems |
> > 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 |
| Attachment 1: elog
|
#!/bin/sh
# Init script for ELOG.
# Copyright © 2003, 2005 Recai Oktaş <roktas@omu.edu.tr>
#
# Licensed under the GNU General Public License, version 2.
# See the file `http://www.gnu.org/copyleft/gpl.txt'.
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/elogd
NAME=elogd
DESC="ELOG daemon"
test -f $DAEMON || exit 0
set -e
# Admin should be able to lock some options.
if [ -f /etc/default/elog ]; then
. /etc/default/elog
fi
# To be in the safe side, the followings should be always defined.
PIDFILE=${PIDFILE:-/var/run/$NAME.pid}
CONFFILE=${CONFFILE:-/etc/elog.conf}
# Add the options to argument list only if defined previously. Since
# some options may also be present in the conffile, we couldn't preset
# those options which would otherwise overwrite the settings in the
# conffile. Also note that, all have reasonable compiled-in defaults.
ARGS="${PIDFILE+"-f $PIDFILE"} \
${CONFFILE+"-c $CONFFILE"} \
${LOGBOOKDIR+"-d $LOGBOOKDIR"} \
${RESOURCEDIR+"-s $RESOURCEDIR"} \
${PORT+"-p $PORT"} \
${HOST+"-n $HOST"} \
${VERBOSE+"-v"}"
# Always run as a daemon.
ARGS=`echo $ARGS -D`
case "$1" in
start)
echo -n "Starting $DESC: "
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--exec $DAEMON -- $ARGS 2>&1
sleep 1
if [ -f "$PIDFILE" ] && ps h `cat "$PIDFILE"` >/dev/null; then
echo "$NAME."
else
echo "$NAME failed to start; check syslog for diagnostics."
exit 1
fi
;;
stop)
echo -n "Stopping $DESC: $NAME"
start-stop-daemon --oknodo --stop --quiet --pidfile $PIDFILE \
--exec $DAEMON -- $ARGS 2>&1
echo "."
;;
reload)
# Do nothing since ELOG daemon responds to
# the changes in conffile directly.
;;
restart|force-reload)
$0 stop
sleep 1
$0 start
if [ "$?" != "0" ]; then
exit 1
fi
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
exit 1
;;
esac
exit 0
# vim:ai:sts=8:sw=8:
|
|
66087
|
Thu Nov 27 11:36:53 2008 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Bug report | Linux | 2.7.5-2130 | Re: Select -> Edit wipes dates |
| Stefan Ritt wrote: |
|
This problem has been fixed in revision 2.7.5-2143. Please upgrade.
|
Yup, this works now - thanks a mil! |
|
66088
|
Thu Nov 27 11:47:34 2008 |
 | T. Ribbrock | emgaron+elog@ribbrock.org | Info | Linux | 2.7.5 | Re: Installation problems |
> The problem is not putting this into the "conrib" area, but supporting it. Since I don't have a Debian system,
> may I suggest that you put it yourself into the elog:Contributions/ logbook. If people then get problems in the
> future, they can contact you directly ;-)
I finally got round to do so. I've also included the changes suggested by Yoshio Imai (reload functionality).
Hopefully, it is useful for someone... |
|
66455
|
Wed Jul 22 12:12:37 2009 |
 | T. Ribbrock | emgaron+elog@ribbrock.org | Bug report | Linux | 2.7.6r2233 | Crashes when editing entries |
For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.
I've been running elogd like this (to get more info)
elogd -v > elog-2233-2.log 2>&1
The last entry I get in the log when elogd crashes is:
Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"
I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.
Any additional information you need: Just let me know.
Regards,
Thomas |
|
66456
|
Wed Jul 22 12:15:56 2009 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Bug report | Linux | 2.7.6r2233 | Re: Crashes when editing entries |
| T. Ribbrock wrote: |
|
For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.
I've been running elogd like this (to get more info)
elogd -v > elog-2233-2.log 2>&1
The last entry I get in the log when elogd crashes is:
Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"
I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.
Any additional information you need: Just let me know.
Regards,
Thomas
|
Forgot to mention: I've also seen error messages like this upon a crash:
*** glibc detected *** corrupted double-linked list: 0x0911bbc0 ***
Regards,
Thomas |
|
66458
|
Wed Jul 22 15:35:57 2009 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Bug report | Linux | 2.7.6r2233 | Re: Crashes when editing entries |
| Stefan Ritt wrote: |
|
well, I need to reproduce your problem in order to fix it. The failed assertation you get is due to some internal writing beyond array boundaries, but I have no clue which part of the code makes this. It might be related to the fact that you use the same index (via Subdir=...) for two logbooks. In this scenario, you are only allowed to modify/add entries to one logbook, not the other. The other one may only be used for reading. And even then it's not guaranteed that new entries show up in the second logbook immediately, you might have to restart the server in order to re-index the logbooks. Internally, the daemon does not know that two logbooks are "the same" and one instance will not realize if the other instance modifies the data "below its feet". Can you try to give up the double logbooks and see if the problem goes away?
|
Hm... I have implemented this set-up originally based on this: https://midas.psi.ch/elogs/Forum/66024. The "double logbook" is a machine log with a "software" (OS installations etc.) and a "hardware" (CPU, RAM, etc.) view. The "hardware" view has the "Subdir=" statement. Thinking about it, the "software" view is used most - I have several automatic scripts running which update the contents whenever a machine gets updated, re-installed and so on. The hardware part does not see much editing - until this week, when we decided to start an inventory... So, it's quite possible that we never noticed that this was iffy. For the rest of our goals, this set-up has worked fantastically - never noticed any problem with one view not updating, actually. Also, I do not remember any crashes with the other, single logbooks.
What I've done for now is to ask all team members to use only the software part (the one without the Subdir statement) to actually change content (the entry masks are the same in both versions) and use the hardware part just for viewing. I'll report back as soon as I get some feedback.
Nonetheless, given that this set-up has been a great help for us - if you ever get the chance to make this work (even) better, I'd be most grateful.
Regards,
Thomas |
|
66460
|
Wed Jul 22 16:52:13 2009 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Bug report | Linux | 2.7.6r2233 | Re: Crashes when editing entries |
| Stefan Ritt wrote: |
|
| T. Ribbrock wrote: |
|
Nonetheless, given that this set-up has been a great help for us - if you ever get the chance to make this work (even) better, I'd be most grateful.
|
Well, for that I have to reproduce the problem. So best would be if you strip it down to the bare minimum in order to reproduce this reliably. Then you zip everything and send it to me. Then tell me what I have to edit and submit in order to stimulate the crash. Once this is successful, I can fix it.
|
Thank you - I shall look into that, though it'll probably take a while to prepare it. |