Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 31 of 806  Not logged in ELOG logo
icon8.gif   can't send form , posted by larbi benouahi on Thu May 14 14:26:36 2009 

Hi,

when i try to send a form after edit or create an entry i got this message : Connection closed by remote server

is there any idea

thanks

icon1.gif   Message ID and trouble ticketing system, posted by lance on Sat Nov 24 03:16:46 2007 

I am trying to create a trouble ticket system however when you do a reply you get a new message ID.  I was hoping to use the message ID as a ticket number and just wanted to use the reply as an append to the orginal message id, however each reply creates a new message id. This would be a nightmare to track and if I closed the ticket I would have to close every log entry related to this.

Does anyone know how to either make the reply and appended reply (appended to the orignal message id) or how to create a field that automatically gives it a new trouble ticket number.

Has anyone configured a trouble ticket system that I could look at to get some ideas?

 

Thanks,

 

Lance

    icon2.gif   Re: Message ID and trouble ticketing system, posted by lance on Mon Nov 26 16:58:26 2007 

Stefan Ritt wrote:

lance wrote:

I am trying to create a trouble ticket system however when you do a reply you get a new message ID.  I was hoping to use the message ID as a ticket number and just wanted to use the reply as an append to the orginal message id, however each reply creates a new message id. This would be a nightmare to track and if I closed the ticket I would have to close every log entry related to this.

Does anyone know how to either make the reply and appended reply (appended to the orignal message id) or how to create a field that automatically gives it a new trouble ticket number.

Has anyone configured a trouble ticket system that I could look at to get some ideas?

First of all, ELOG has been designed having shift logbooks in mind, so it probably will never be a perfect trouble ticket system. Nevertheless, there are some options which can help in that respect:

  • Use attributes Ticket and Status
  • Preset Ticket with a running ticket number via

    Preset ticket = TCK-#####

    This will increment the 5-digit ticket number whenever you create a new ticket, but will not update it when you do a reply

  • Use Status to determine the status of the whole trouble ticket chain (initial entry plus replies)

    Options Status = open, closed
    Preset Status = open

  • Once a ticked chain is closed, do the following:

    • Go to the threaded list display
    • Click on Select
    • Select the trouble ticket chain
    • Click on Edit
    • Now change Status from "Open" to "Closed"
    This will then modify the Status of the whole chain from "Open" to "Closed"

Stefan,

Thanks for this, I had already implemented the Preset Ticket Nr = TT-##### but I didnt use the threaded and Select to close the ticket, very nice tip thanks. I think this program can be have several uses, and working very well. The trouble ticketing will work for us.

Once again thanks for the very speedy support.

Lance

icon8.gif   synchronization, posted by lance on Wed Jun 17 09:05:27 2009 

We are running elog across two sites and synchronizing every four hours on change only. There are about 100 entries per day of which most are just one line entries. However this is taking up to 9 mins and during the replication process the server gives us an "unavailable" error. We are using a T1 across the sites so bandwidth should not be an issue, I am confused as to why this takes so long.

The issue for us is not how long the sync takes, providing this was happening in the background, and doesnt lock out the server while the replication was taking place. We are operating under a 24 hour call center type environment so the server being available all the time is of paramount importance.

We use version 2.7.2 and I know there have been several changes made since this version. Would changing to the latest version have any impact on this?

 

Cheers,

 

Lance

    icon2.gif   Re: synchronization, posted by lance on Fri Jun 19 09:44:02 2009 

lance wrote:

We are running elog across two sites and synchronizing every four hours on change only. There are about 100 entries per day of which most are just one line entries. However this is taking up to 9 mins and during the replication process the server gives us an "unavailable" error. We are using a T1 across the sites so bandwidth should not be an issue, I am confused as to why this takes so long.

The issue for us is not how long the sync takes, providing this was happening in the background, and doesnt lock out the server while the replication was taking place. We are operating under a 24 hour call center type environment so the server being available all the time is of paramount importance.

We use version 2.7.2 and I know there have been several changes made since this version. Would changing to the latest version have any impact on this?

 

Cheers,

 

Lance

 

Stefan,

I have been running logging and I think I have found the problem however I do not know how to resolve it.

Here is where it is going wrong:

19-May-2009 04:02:48 [] {NSS} MIRROR: ID21268: Local entry submitted

19-May-2009 04:07:34 [] {AMC} MIRROR: send entry #31056

It seems that when it has finished replication on one logbook there is a significant time before the next logbook replication starts. During this time the server is not avalable. I have noticed that the time between ending one logbook and starting the next differs betwee 2 and 5 minutes. Again the server is not available when this happens.

Do you have any idea?

Cheers,

 

Lance

    icon2.gif   Re: synchronization, posted by lance on Fri Jun 26 14:27:27 2009 log_for_stefan.pdfPMCLogfile

Stefan Ritt wrote:

lance wrote:

lance wrote:

We are running elog across two sites and synchronizing every four hours on change only. There are about 100 entries per day of which most are just one line entries. However this is taking up to 9 mins and during the replication process the server gives us an "unavailable" error. We are using a T1 across the sites so bandwidth should not be an issue, I am confused as to why this takes so long.

The issue for us is not how long the sync takes, providing this was happening in the background, and doesnt lock out the server while the replication was taking place. We are operating under a 24 hour call center type environment so the server being available all the time is of paramount importance.

We use version 2.7.2 and I know there have been several changes made since this version. Would changing to the latest version have any impact on this?

 

Cheers,

 

Lance

 

Stefan,

I have been running logging and I think I have found the problem however I do not know how to resolve it.

Here is where it is going wrong:

19-May-2009 04:02:48 [] {NSS} MIRROR: ID21268: Local entry submitted

19-May-2009 04:07:34 [] {AMC} MIRROR: send entry #31056

It seems that when it has finished replication on one logbook there is a significant time before the next logbook replication starts. During this time the server is not avalable. I have noticed that the time between ending one logbook and starting the next differs betwee 2 and 5 minutes. Again the server is not available when this happens.

Do you have any idea?

Cheers,

 

Lance

Hi,

I need more information to narrow down the problem:

- does this only happen on automatic mirroring or also when you do a manual synchronize?

- does this happen on both sides, like when you make the "other" elog server the master?

- if the server is inresponsive, does the CPU on that machine go to 100% or to 0%?

- do you have very long attachments in your logbooks?

- do you have the same problem on a "tiny" logbook like it comes with the distribution?

- are you using any Apache proxy in between?

I'm afraid that in the end you have to debug this yourself, since it will be very hard for me to reproduce exactly your problem (unless you send me all your files). 

Cheers,

  Stefan

Stefan,

Thanks for the reply.

This happens on automatic mirroring and by manual sync. However only the site initializing the mirror is locked out the remote seems to still be able to function.

The CPU jumps from very little usage to 50%+ being used by elogd.exe as soon as you start the mirroring/sync process

I have attached a file that that is in three parts and its pretty big. When I start up the elogd -v it takes over two minutes to scroll through hundreds of  files. I have attached the last of those entries in the first part of the attached PDF, the second part of the PDF shows a manual sync and the third part shows the same sync on the same logbook a few mins later. It seems to take about 3 minutes even when there has been no new log entries. In addition if you are mirroring more that one log book through the automated cron job it can take about 3-5 mins before the second logbook starts its replication. I have also added a screenshot of the completed replications on both runs.

If there is a way to redirect the output of the cmd window when running elogd -v I would capture all the data for you but the standard redirect ">> elog.txt" only creates a blank file.

We are running several logbooks and it does look like the smaller logbooks still take several minutes to start up. I have attached the PMCLogfile and if you look between the NSS and the AMC replications on any day there seems to be a 3 min gap between one book finishing and another starting.

We are not using Apache prox in between.

I am not a programmer but I can follow instruction, if you need anything else let me know.

Stefan this has been driving me nuts for a while now so any help you can give would be more than appreciated.

Cheers,

 

Lance

 

icon5.gif   Elog Crashes, posted by lance on Mon Jul 20 09:26:41 2009 Elog_crash_events.doc
Stefan,
 
Our log is crashing on a regular basis and I have been unable to identify the reason. Now the if the log crashes that is not a major problem however when you try to stop the daemon from the services it fails to stop. This means that the daemon cannot be restarted. The only way then is to start killing processes. This is not something I want none experienced guys to do.
 
Looking at the processes is look like the elogd.exe is still running and doesn’t die when you try to stop the daemon service.
 
I checked the times it was crashing with events in the elog logfiles but there was nothing actually happening at these times. It seems something is causing it to just hang.
 
I have attached the eventlog files for you if you have any ideas I would appreciate them.
 
I have not run the log in verbose mode as I have thus far been unable to redirect the output of the screen in order to see what is happening. If you have any tips on how to redirect the output I would save the file for off line analysis. Our log is used 24/7 therefore it is critical that it be kept running so if I was to run it with the –v option the guys would have to restart it and I would lose the data.
 
Any help is much appreciated
 
 
Regards,
 
Lance
icon5.gif   SQL Database, posted by lance on Thu Sep 2 10:30:14 2010 

We have been running elog for a few years now and its solid. The only thing is we are getting to 140k entries over a few books and its starting to slow down whist searching. My questions is can we go to an SQL type database rather than a flat file? Is it worth it? Is anyone running this type of configuration?

ELOG V3.1.5-3fb85fa6