Hello

I have the following in elog.cfg :

Attributes = Author, Author Email, Category, Customer, server, Subject ,  Change Window Begin , Change Window End
List display = ID,Author, Author Email, Category, Customer, server,  Subject ,  Change Window Begin , Change Window End

Type Change Window Begin = datetime
Type Change Window End = datetime

So I want to be able to give a start and end date to the user.  However : If I open a find/Search I see this :

There are for each  Change Window <item>   we get  Start: and End: time entries. Was expecting only one date entrie .

Why is this ? Seems to be a feature of datetime  or am i missing something.

Right, that's a feature. Many people want to specify a range when doing a query on a date. Like Change Window Begin after Jan 1st, 2009 and before Jan 5th, 2009. If you just want a single date, set both Start: and End: to the same date, or actually the End: to Start+1 Day to cover all 24 hours of the Start: date. Otherwise when you have data + time, you would have to match the exact second to retrieve a certain entry. So having a range there is more powerful.

I need some guidedance on how to access the logbook from another computer. I installed the logbook on a Windows server machine and started the logbook using port 81.

I can connect to the logbook on the same machine, but I can not access it from another machine on the same network.

I already confirm that the windows firewall is not enable.

Are your sure about the firewall, because this is the usual reason for that problem. Can you "ping" your server machine from the other machine (like "ping <server>"), maybe you have some network problems.

I need some guidedance on how to access the logbook from another computer. I installed the logbook on a Windows server machine and started the logbook using port 81.

I can connect to the logbook on the same machine, but I can not access it from another machine on the same network.

I already confirm that the windows firewall is not enable.

Here's the issue. We use elog to develope products we need to be able to see all the thumbnail images in a

particular logbook. Our default view is to use the threaded view fully expanded in order to have all the thumbnails

be displayed for each product. This works fine but when we move one message to another logbook the thumbnails

end up getting broken and won't be displayed. The only way to fix this is to remove the image and re-upload the

picture after the message is moved. This is not a good option because we have hundrends of items that are

constantly being moved around from logbook to logbook. Any ideas?

Regards,

Mike

EDIT:

On further inspection it seems that when you are moving messages to another log book the image date filename

is re-written which of course breaks the html link to the image.  Is there anyway to supress this so that the filename

stays in tact when it's moved from one book to another. I don't see why the name of an attachment has to get changed

just because something is moved around.

I fixed this in revision #2204. The attachment names now stay the same. There is one tiny risk of screwing up, namely if you have the same attachment name in two different logbooks (accidentally also submitted at the same second and therefore the same time stamp). If you then copy these two entries to a third logbook, one attachment will overwrite the other one, but that risk is indeed really small. I actually had to re-write the link to the attachment inside the text body (even differently for ELCode and HTML encoding). So I'm not 100% sure I covered all cases, so just give it a try.

 This is a major improvement. The only issue now is when we embed an image in the body of the message elog makes a nice thumbnail. When you move the message to another logbook the thumbnail doesn't work and instead it shows the MASSIVE full size version of the picture instead. Is that possible to fix?

Thanks Stefan!

Mike

Can you try revision #2206? 

 Stefan,

Works perfectly, thanks for the fix you rock!

Mike

elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
This was observed on Solaris 10 (SPARC).
The documentation states that elogd should re-read configuration after receiving SIGHUP.

> elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> This was observed on Solaris 10 (SPARC).
> The documentation states that elogd should re-read configuration after receiving SIGHUP.

I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe 
you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to 
start the daemon interactively and see what exactly happens if you send several SIGHUPs.

> > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > This was observed on Solaris 10 (SPARC).
> > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> 
> I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe 
> you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to 
> start the daemon interactively and see what exactly happens if you send several SIGHUPs.

The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
is called.  Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.

The solution is to use the POSIX sigaction() call instead of signal(). 

> > > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > > This was observed on Solaris 10 (SPARC).
> > > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> > 
> > I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe 
> > you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to 
> > start the daemon interactively and see what exactly happens if you send several SIGHUPs.
> 
> The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
> is called.  Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.
> 
> The solution is to use the POSIX sigaction() call instead of signal(). 

Can you try to modify the signal() calls into sigaction(). If this really works under Solaris, I will incorporate this 
then into the distribution.

> > > > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > > > This was observed on Solaris 10 (SPARC).
> > > > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> > > 
> > > I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe 
> > > you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to 
> > > start the daemon interactively and see what exactly happens if you send several SIGHUPs.
> > 
> > The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
> > is called.  Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.
> > 
> > The solution is to use the POSIX sigaction() call instead of signal(). 
> 
> Can you try to modify the signal() calls into sigaction(). If this really works under Solaris, I will incorporate this 
> then into the distribution.

Here is the patch.  It works under both Solaris and Linux.

> Here is the patch.  It works under both Solaris and Linux.

Thanks! I put that into revision #2207.

Hi Stefan,

When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
your FAQ about marking of whole threads).

In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
ID number.

Thanks,

David Pilgram.

Hi Stefan,

Any possibility on this one?

David Pilgram.
> Hi Stefan,
> 
> When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
> cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> your FAQ about marking of whole threads).
> 
> In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> ID number.
> 
> Thanks,
> 
> David Pilgram.

> Hi Stefan,
> 
> When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
> cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> your FAQ about marking of whole threads).
> 
> In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> ID number.
> 
> Thanks,
> 
> David Pilgram.

I have implemented this feature in revision 2205. You need to set the new flag "Preserve IDs = 1" in the 
configuration. I have not tested this extensively, but I'm sure you will do it ;-)

Thanks Stefan,  Downloading shortly and I'll let you know ;-)
> > Hi Stefan,
> > 
> > When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> > the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
> > cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> > your FAQ about marking of whole threads).
> > 
> > In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> > ID number.
> > 
> > Thanks,
> > 
> > David Pilgram.
> 
> I have implemented this feature in revision 2205. You need to set the new flag "Preserve IDs = 1" in the 
> configuration. I have not tested this extensively, but I'm sure you will do it ;-)

Hi,

There's seems to be a memory leak with elogd.exe running windows.  I had this problem with older version of elogd.exe, i've just upgrade to the latest and the problems still exist. I've had this issue with earlier versions.  I've just upgrade elog to the latest 2.76 version. The memory leak still persist. I really appreciate if you or anyone here can help me resolve this issue.

Thank!

JH

ELOG has been carefully designed not to contain memory leaks. The server for this forum for example runs for months without problem:

[ritt@midas ~]$ ps aux | grep elogd

elog      1958  0.4  3.1  39412 32940 ?        Ss   May09 178:16 /usr/local/sbin/elogd -D -c /usr/local/elog/elogd.cfg

So if you have a problem, it must be specific to your installation. You should note that if you up- or download big attachents, memory gets allocated for some network buffers to contain these attachments. The buffer is kept to contain the largest attachment, it will never shrink. But once established, it will also not grow. If you see however a constant increase in memory consumption, I would appreciate if you tell me how you do this. Like which configuration you use, if you just read entries or also upload them, etc. etc. Once I can reproduce exactly your problem, I can try to fix it. 

I am trying to add additional information to the subject of new entries:

Subst subject = $subject [INCIDENT $message id]
Subst on reply subject = Re: $subject
Fixed Attributes Reply = Subject

However, the new entry subject looks like:

this is my subject [INCIDENT this is my subject [INCIDENT $message id]

I'm not sure if there's a problem with the substitution or if this is just not allowed (I'm having LISP flashbacks).

By the way, if I use "Subst on reply subject" I get the behavior I would like but the original entry in the thread doesn't contain the appended data:

Subst on reply subject = Re: $subject [INCIDENT $message id]

Any help would be appreciated.

Alex

Subst subject = $subject [INCIDENT $message id]
Subst on reply subject = Re: $subject
Fixed Attributes Reply = Subject

this is my subject [INCIDENT this is my subject [INCIDENT $message id]

Subst on reply subject = Re: $subject [INCIDENT $message id]

The problem here is that the subsitution is executed before the entry is committed to the database. The message ID is assigned however only in the commit. So at the time of the substitution, the $message id is not available. When you do the reply however, the message id is valid and subsituted correctly. I see at this moment no clever solution for your problem (maybe "Subst on edit", but then you have to edit/submit each message manually once).