When trying to stop elogd processes with the kill command
elogd exits only after access to the logbook.

It should exit immediately, maybe after some cleanup.

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.

> 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.

> 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.

Can you please tell me how to reproduce this problem?

Even if I do a

kill -HUP <pid>; kill <pid>

it works immediately when I start elogd manually in interactive mode (not as daemon).

> > 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.
> 
> Can you please tell me how to reproduce this problem?
> 
> Even if I do a
> 
> kill -HUP <pid>; kill <pid>
> 
> it works immediately when I start elogd manually in interactive mode (not as daemon).

Even though I can't test this right now, I assume you have to wait a little
so that elogd jumps out of the 'select()' statement between the kill
commands.  Try: 

kill -HUP <pid>; sleep 2; kill <pid>

(I think the 'select()' timeout was 1 second.?)

> kill -HUP <pid>; sleep 2; kill <pid>

Thanks, I could reproduce the problem. It had to do that a SIGHUP aborts the select()
command, which some listen socket marked, so that elogd goes into an accept() call, waiting
there indefinitely (or until a new browser request arrives). I fixed that. New version
under CVS.

Under 2.5.4-2 build1.460, when I edit the demo elogd.cfg the following happens:

- I start with
URL = http://cde-tx32-sds01.subdom.dom.com:8080/

- When I go to edit the global section of the config file, the *display* of
the string is changed to:
URL = <a
href="http://cde-tx32-sds01.subdom.dom.com:8080/">http://cde-tx32-sds01.subdom.dom.com:8080/</a>

- Saving this results in an error in that the rendered url is invalid.

Our current running version is 2.5.4-build1.413 and this behavior is not
evident.  I've looked through the diffs but could not identify the genesis
of this new behavior.

Thanks

This problem has been fixed in revision 1.462

> This problem has been fixed in revision 1.462

Thank you!

At some point, in the last week or so, I upgraded the debian-unstable
version (r1459-1) of elog.  Now, PostScript files (as attachments) are
displayed (shown in ascii text, instead of just showing the link).  

Is there an option in the elog.cfg to only display certain files (like .gif
or .jpg).

> At some point, in the last week or so, I upgraded the debian-unstable
> version (r1459-1) of elog.  Now, PostScript files (as attachments) are
> displayed (shown in ascii text, instead of just showing the link).  
> 
> Is there an option in the elog.cfg to only display certain files (like .gif
> or .jpg).

See elog:691 . In the latest CVS version, postscript files are not displayed
any more inline, but the next debian release will take some time, maybe you can
compile from source...

I have a question about ELOG. Let's say after the user finishes his shift 
and passess on to the next user on duty. A staff member would want to look 
through the entries and vet them. The staff could lock the entries to 
maintain integrity of the information. How can that be done with ELOG? Can 
you enlighten me. Thank u.

One possibility is to use the option "Restrict edit time = <hours>". This way
an entry can only be edited let's say 8 hours after it has been created.

Another way is to maintain two logbooks, a "scratch" logbook and an "archive"
logbook. Users would put their entries into the scratch logbook, the staff
would examine it and move them to the archive logbook, where all users only
have read access to. To move entries between logbooks, you have to put the
"Move to" command in the configuration file like:

Menu commands = Back, New, Edit, Delete, Reply, Find, Move to, Config, Help

Hi,

I have an ELOG installation on a RedHat linux server, called myserver. I 
can connect to this server with the following entries in the elogd.cfg file:
   [global]
   URL=http://myserver:8080
This works fine. I can log in, select logbooks, edit/create entries etc. 
etc.

However, I want this connection to be encrypted. So I activate stunnel (v4) 
in such a way that stunnel listens to port 8081 and forwards to the 
("remote") port 8080, which is the "original" elog port. I change the URL= 
entry in de elogd.cfg file to URL=https://myserver:8081 in order to use the 
SSL encrypted connection.

At this time, when I connect to https://myserver:8081 I get the 
welcome/login screen, but when I enter the (correct) username and password, 
the elog program does not show the contents of the logbook buts shows the 
loginscreen again. If I enter a wrong username/password, I do get a correct 
error-screen. So it seems that the connection is correct, but there is some 
sort of problem in ELOG. Anyone who can give me a hand here?

That bug has been fixed recently, please update to the newest version.

Newly installed elog gives this response when I try to submit a new record:

New entry cannot be written to directory "./logbooks/Linux/" 
Please check that it exists and elogd has write access

I started the daemon.  I've not yet assigned passwords -- just checking
things out.  How can I create this access to my own directory?

> Newly installed elog gives this response when I try to submit a new record:
> 
> New entry cannot be written to directory "./logbooks/Linux/" 
> Please check that it exists and elogd has write access
> 
> I started the daemon.  I've not yet assigned passwords -- just checking
> things out.  How can I create this access to my own directory?

First, find out under which account the daemon is running. It you account if
you start it interactively, if you installed from the RPM, an account "elog" is
created. Then make sure that the account under which elogd is running has write
access to the ./logbooks/Linux/ directory. One common problem is that people
start the daemon the first time under their account, which causes elogd to
create the logbook directory under the user name. If elogd is later started
under the account "elog" this one of course does not have access to the
directory. A

chown -R elog.elog /usr/local/elog/

issued as root could help in that case. Please replace /usr/local/elog with the
directory where elog is installed.

The upgrade was done by just replacing elogd from 2.5.2 to 2.5.4 from the rpm.

Somehow elogd 2.5.4 treat all users as normal user. When clicking on
"config". All admin users has no "change elogd.cfg" button. Revert back to
2.5.2 OK.

Is there anything I need to change to upgrade other than replaceing elogd?
Clearing the cookies didn't help.

Thanks,
.nait.

> Somehow elogd 2.5.4 treat all users as normal user. When clicking on
> "config". All admin users has no "change elogd.cfg" button. Revert back to
> 2.5.2 OK.
> 
> Is there anything I need to change to upgrade other than replaceing elogd?
> Clearing the cookies didn't help.

The button name has been changed from "change elogd.cfg" to "change config file"
since the file name is now variable (can be changed during compile time). But I
guess this is not your problem.

Can you try with the demo logbook (contained in the distribution). Just add
"password file = ..." and "admin user = ..." to the sample elogd.cfg. If I do that
here, everything works fine. You also can send me your elogd.cfg so I can have a look.

The help text on the website says the following:

"The command Select can be used to select multiple messages for deletion of
moving to other logbooks."

This is not clear but was the intent to indicate that SELECT can be used to
either select multiple log entries for deletion OR for moving to another
logbook?  If the latter, then this does not work if one adds the MOVE TO
menu item to the list.  If the former then the helptext is a little misleading.

Thanks!

> The help text on the website says the following:
> 
> "The command Select can be used to select multiple messages for deletion of
> moving to other logbooks."
> 
> This is not clear but was the intent to indicate that SELECT can be used to
> either select multiple log entries for deletion OR for moving to another
> logbook?  If the latter, then this does not work if one adds the MOVE TO
> menu item to the list.  If the former then the helptext is a little misleading.

SELECT can be used for deletion OR moving OR copying. To enable the copy and move
commands, they have to be present in the "Menu commands" list, like

Menu commands = Back, New, Edit, Delete, Reply, Find, Config, Logout, Move to, Copy
to, Help

I added an appropriate note to the documentation, sorry for the misleading descriptoin.

> > The help text on the website says the following:
> > 
> > "The command Select can be used to select multiple messages for deletion of
> > moving to other logbooks."
> > 
> > This is not clear but was the intent to indicate that SELECT can be used to
> > either select multiple log entries for deletion OR for moving to another
> > logbook?  If the latter, then this does not work if one adds the MOVE TO
> > menu item to the list.  If the former then the helptext is a little misleading.
> 
> SELECT can be used for deletion OR moving OR copying. To enable the copy and move
> commands, they have to be present in the "Menu commands" list, like
> 
> Menu commands = Back, New, Edit, Delete, Reply, Find, Config, Logout, Move to, Copy
> to, Help
> 
> I added an appropriate note to the documentation, sorry for the misleading descriptoin.

Thank you.  I had added the "Move To" and this works at the log entry level (i.e., "Move
To <name>) but in the threaded view one does not get the enumerated list of logbooks.

I'll play around with it a little more before re-posting.  When it didn't work as I
expected I read the docs and ran across the confusing text - so I stopped and asked!

Thanks again.

> Thank you.  I had added the "Move To" and this works at the log entry
level (i.e., "Move
> To <name>) but in the threaded view one does not get the enumerated list
of logbooks.

You get the "Move To" button only after pressing "Select", otherwise it does
not make sense. See attached screendump and config example.

> > Thank you.  I had added the "Move To" and this works at the log entry
> level (i.e., "Move
> > To <name>) but in the threaded view one does not get the enumerated list
> of logbooks.
> 
> You get the "Move To" button only after pressing "Select", otherwise it does
> not make sense. See attached screendump and config example.

Hmmm.  I like the little buttons with the pull-downs for selections. 
Unfortunately, I don't get that.  With a config of:

Find Menu commands = New, Find, Select, Config, Change password, Logout, Help, Admin
Menu commands = Back, New, Edit, Delete, Reply, Find, Move To, Copy To, Config, Help

my screen only shows the "toggle" and "delete" buttons.  Was there a recent rev
that allowed this to happen (I didn't see a comment on this).  

BTW, on a log entry screen, is the appropriate behavior for the "Move To" option
to show multiple "Move To" links (one for each logbook) or should there also be
pulldowns?  

Thanks

> Hmmm.  I like the little buttons with the pull-downs for selections. 
> Unfortunately, I don't get that.  With a config of:
> 
> Find Menu commands = New, Find, Select, Config, Change password, Logout, Help, Admin
> Menu commands = Back, New, Edit, Delete, Reply, Find, Move To, Copy To, Config, Help

Unfortunately menu commands are case sensitive, so you need a "Move to" instead a "Move
To". I changed this in the code so future versions will not be case sensitive any more.

> BTW, on a log entry screen, is the appropriate behavior for the "Move To" option
> to show multiple "Move To" links (one for each logbook) or should there also be
> pulldowns?  

On the log entry screen, only menu links are possible for internal reasons, that's why I
have chosen that display mode. I agree that it can look clumsy if you have many
logbooks, but there is the "move to = <logbook list>" option to restrict the number of
target logbooks.