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 |
Re: Message ID and trouble ticketing system, posted by Stefan Ritt on Mon Nov 26 14:33:59 2007
|
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" |
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 |
Re: Message ID and trouble ticketing system, posted by Richard Ecclestone on Fri Feb 15 15:46:38 2008
|
lance wrote: |
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
|
Hi
I tried the 'Preset ticket = TCK-#####' method to create unique numbers for our application. This worked very nicely until we replied to a earlier message, if we then create a new message the system creates a sequential number after the last message number we replied to. For example if we have 10 messages. If someone replies to message number #2 then when a new record is created it is then assigned number #3 not #11, thus making a duplicate entry for #3.
Any ideas?
Cheers Richard |
Re: Message ID and trouble ticketing system, posted by Stefan Ritt on Thu Feb 21 08:04:50 2008
|
Richard Ecclestone wrote: |
I tried the 'Preset ticket = TCK-#####' method to create unique numbers for our application. This worked very nicely until we replied to a earlier message, if we then create a new message the system creates a sequential number after the last message number we replied to. For example if we have 10 messages. If someone replies to message number #2 then when a new record is created it is then assigned number #3 not #11, thus making a duplicate entry for #3.
Any ideas?
|
Yes. If you want this feature to work also for replies, you have to put following into your config file:
Preset ticket = TCK-#####
Preset on reply ticket = TCK-#####
|
Re: Message ID and trouble ticketing system, posted by Stefan Ritt on Fri Mar 7 14:29:00 2008
|
Stefan Ritt wrote: |
Richard Ecclestone wrote: |
I tried the 'Preset ticket = TCK-#####' method to create unique numbers for our application. This worked very nicely until we replied to a earlier message, if we then create a new message the system creates a sequential number after the last message number we replied to. For example if we have 10 messages. If someone replies to message number #2 then when a new record is created it is then assigned number #3 not #11, thus making a duplicate entry for #3.
Any ideas?
|
Yes. If you want this feature to work also for replies, you have to put following into your config file:
Preset ticket = TCK-#####
Preset on reply ticket = TCK-#####
|
When I was browsing this forum about my previous problem, I found
this thread. A ticket number that applies to all entries in a
thread, but is unique to that thread.
But I have the same problem as Richard Ecclestone reported, and the
"Preset on reply ticket" line from your reply has not had any effect.
It appears that on starting a new thread (which is to have that
ticket number), the ticket number is just incremented by one from
that of the previous (as in previous ID number) entry. This is
fine if each thread is completed before a new one started, but if
there are more than one active thread, which can be progressed
further in any order, new threads are likely to be issued with a
ticket number which has already been issued (see Richards's example).
An alternative source of unique numbers would be the Entry number (as
in "696 Entries", top right of the midas.psi.ch/elogs/Forum page),
which would be the seed for the ticket number on new entry. Not sure
of the syntax for that, or for the replies to have *that* number for
the config file. I know there is a problem if you move a number of
threads away, but the only alternative (that I can think of) is to
store the seed number somewhere, and increment it every time a new
thread is started.
Or have I got something wrong here?
Thanks.
Regards,
David.
|
Re: Message ID and trouble ticketing system, posted by Stefan Ritt on Fri Mar 7 14:45:02 2008
|
David wrote: |
When I was browsing this forum about my previous problem, I found this thread. A ticket number that applies to all entries in a thread, but is unique to that thread. But I have the same problem as Richard Ecclestone reported, and the "Preset on reply ticket" line from your reply has not had any effect. It appears that on starting a new thread (which is to have that ticket number), the ticket number is just incremented by one from that of the previous (as in previous ID number) entry. This is fine if each thread is completed before a new one started, but if there are more than one active thread, which can be progressed further in any order, new threads are likely to be issued with a ticket number which has already been issued (see Richards's example).
An alternative source of unique numbers would be the Entry number (as in "696 Entries", top right of the midas.psi.ch/elogs/Forum page), which would be the seed for the ticket number on new entry. Not sure of the syntax for that, or for the replies to have *that* number for the config file. I know there is a problem if you move a number of threads away, but the only alternative (that I can think of) is to store the seed number somewhere, and increment it every time a new thread is started.
Or have I got something wrong here? Thanks. Regards, David.
|
I cannot reproduce your problem. Assume we have following config file:
[demo]
Theme = default
Attributes = Ticket, Author, Subject
Preset Ticket = TCK-####
The the first entry gets TCK-0001. Any reply to that stays with TCK-0001. Then I do another "new" entry, which gets TCK-0002. Even if I then do another reply to the first thread, that will just stay with TCK-0001. So avoid using 'Preset on reply Ticket". The post from Richard was different, he wanted a new number also for replies (if I understand correctly). |
Re: Message ID and trouble ticketing system, posted by Stefan Ritt on Fri Mar 7 20:42:39 2008
|
Ok, now I got the point, also Richard had the same problem. Assume we have 10 threads, and thus ticket numbers 1-10. Now we get a reply to #2, which then pops up to the top of the list. A new message increments the top entry of all entries, and then wrongly gives a new #3, instead of #11.
I fixed this in SVN revision 2073, where elogd searches all logbook entries for the largest index, then increments this one by one. The fix will be contained in the next release. |
Re: Message ID and trouble ticketing system, posted by David Pilgram on Fri Mar 7 21:26:18 2008
|
>Stefan Ritt wrote:
>
>Ok, now I got the point, also Richard had the same problem. Assume we have 10 threads, and thus
>ticket numbers 1-10. Now we get a reply to #2, which then pops up to the top of the list. A new
>message increments the top entry of all entries, and then wrongly gives a new #3, instead of #11.
>
>I fixed this in SVN revision 2073, where elogd searches *all* logbook entries for the largest
>index, then increments this one by one. The fix will be contained in the next release.
----
Great! Thanks Stefan, off to download right now!
Great program, by the way, but don't think you need to be told that yet again! |
Re: Message ID and trouble ticketing system, posted by David Pilgram on Fri Mar 7 21:53:28 2008
|
>>Stefan Ritt wrote:
>>
>>Ok, now I got the point, also Richard had the same problem. Assume we have 10 threads, and thus
>>ticket numbers 1-10. Now we get a reply to #2, which then pops up to the top of the list. A new
>>message increments the top entry of all entries, and then wrongly gives a new #3, instead of #11.
>>
>>I fixed this in SVN revision 2073, where elogd searches *all* logbook entries for the largest
>>index, then increments this one by one. The fix will be contained in the next release.
>
>----
>
>Great! Thanks Stefan, off to download right now!
>
>Great program, by the way, but don't think you need to be told that yet again!
---
Oh ho!
I've tried this on an existing database, where most entries do not have a ticket #. The previous entry #
(previous in ID sense) is T00550, say. But when I start a new thread, the ticket # is T00001. Is it being put
out by no entry for ticket # in most of the database?
LATER UPDATE.
On a small database (12 entries, with 45 comments in total), this worked as expected if most or all entries have ticket numbers, even if the previous (by id #) had not had a ticket number. (I had to edit every entry to put in ticket numbers).
The only thing I can think of is the number of entries that don't have a ticket #, or a line in the .log file entry saying "Ticket: " but am looking further into this.
(BTW, am posting this way to get around the proxy server problem I have!) |
email subject, posted by Bill Whiting on Fri Mar 7 13:44:34 2008
|
Can I control the content of the Subject on an email notification?
i.e. Can I copy the subject from the elog entry into the email subject?
Thanks,
//Bill |
Re: email subject, posted by Bill Whiting on Fri Mar 7 14:09:40 2008
|
Bill Whiting wrote: |
Can I control the content of the Subject on an email notification?
i.e. Can I copy the subject from the elog entry into the email subject?
Thanks,
//Bill
|
I found the answer in the docs.
In the config file add
Use Email Subject = Added Text: $subject
This results in the e-mail subject being set to "Added Text: elogentry subject line"
Thanks for a great tool! |
Quick filter by ID, posted by David Pilgram on Tue Mar 4 14:03:00 2008
|
Hi,
I've just upgraded from 2.6.2 to 2.7.3.
In my config file, I have
Quick filter: Date, ID.
When starting 2.7.3, across the top I now get
"Error: Attribute "ID" for quick filter not found"
followed by an entry box.
If an ID is typed into that box, it sort of finds the right entry (+/- a few on occasion).
I cannot see any documented change that would affect how the Quick filter works. Any clues? Thanks. |
Re: Quick filter by ID, posted by Stefan Ritt on Thu Mar 6 15:06:35 2008
|
> Hi,
>
> I've just upgraded from 2.6.2 to 2.7.3.
>
> In my config file, I have
>
> Quick filter: Date, ID.
>
> When starting 2.7.3, across the top I now get
>
> "Error: Attribute "ID" for quick filter not found"
> followed by an entry box.
>
> If an ID is typed into that box, it sort of finds the right entry (+/- a few on occasion).
>
> I cannot see any documented change that would affect how the Quick filter works. Any clues? Thanks.
Actually it is nowhere written the 'ID' for a quick filter should work. After investigating, I realize that it
worked previously "by accident". I added in meantime some test so there is a warning for quick filter attributes
which do not exist, and that's what you got. I loosened this test for 'ID' now in the current SVN version, so it
can be used. It does however not display the single entry you want, but a page containing that entry (which then
is displayed in bold). If you want exactly one entry, just add it's ID to the URL, like
https://midas.psi.ch/elogs/Forum/65767
for your previous entry. |
Re: Quick filter by ID, posted by David Pilgram on Fri Mar 7 13:12:37 2008
|
> > Hi,
> >
> > I've just upgraded from 2.6.2 to 2.7.3.
> >
> > In my config file, I have
> >
> > Quick filter: Date, ID.
> >
> > When starting 2.7.3, across the top I now get
> >
> > "Error: Attribute "ID" for quick filter not found"
> > followed by an entry box.
> >
> > If an ID is typed into that box, it sort of finds the right entry (+/- a few on occasion).
> >
> > I cannot see any documented change that would affect how the Quick filter works. Any clues? Thanks.
>
> Actually it is nowhere written the 'ID' for a quick filter should work. After investigating, I realize that it
> worked previously "by accident". I added in meantime some test so there is a warning for quick filter attributes
> which do not exist, and that's what you got. I loosened this test for 'ID' now in the current SVN version, so it
> can be used. It does however not display the single entry you want, but a page containing that entry (which then
> is displayed in bold). If you want exactly one entry, just add it's ID to the URL, like
>
> https://midas.psi.ch/elogs/Forum/65767
>
> for your previous entry.
Thanks Stefan! |
#include statements and attachment visibility, posted by Yoshio Imai on Thu Feb 28 19:07:19 2008
|
Hi!
First of all, thank you again for the great software and all the support.
Recently, one collaborator here noted that it would be helpful if the preview of attached files could be disabled on a file-by-file basis (via a checkbutton next to the "Upload" button maybe?). This applies e.g. to cases where someone performs a measurement outside of routine operations and attaches the ASCII data file (preview not wanted, in particular if it contains many lines) and the graph representing the evaluation (preview wanted). The disabling should apply to both single-entry view and list view with "Show attachments" option.
Another "fancy" idea of ours would be to allow #include-like statements in the ELOG config file. E.g. if the number of logbooks gets large, people might choose to put old logbooks to an archive disk which is then stored on some shelf. If a user then wants to access these, the disk could be mounted again (say, under /elog-archive). But since we don't know which archive disk has been mounted, and in order to keep the main config file small, the best would be to have the configurations for the logbooks of each disk on the disk itself (say, in a file called additional.config). We could then have a line like#include /elog-archive/additional.config in the main config file. When the elogd is (re)started, it would try to include that file. If it finds none (because no archive disk is mounted) it would silently ignore this. But if it finds such a file, it would include the logbook definitions found therein.
Do you think it is possible (and preferable) to implement this?
Cheers
Y |
Re: #include statements and attachment visibility, posted by Stefan Ritt on Thu Mar 6 14:03:17 2008
|
Yoshio Imai wrote: | Recently, one collaborator here noted that it would be helpful if the preview of attached files could be disabled on a file-by-file basis (via a checkbutton next to the "Upload" button maybe?). This applies e.g. to cases where someone performs a measurement outside of routine operations and attaches the ASCII data file (preview not wanted, in particular if it contains many lines) and the graph representing the evaluation (preview wanted). The disabling should apply to both single-entry view and list view with "Show attachments" option. |
I made you something even better: I added a new option called Attachment lines. This number restricts the number of lines shown for any ASCII attachment. The default is 300, but you can set this to 10 maybe. This still shows you the first 10 lines of the attachment which might be handy. If you set this value to zero, no line at all is shown. The new feature is in SVN revision 2069.
Yoshio Imai wrote: | Another "fancy" idea of ours would be to allow #include-like statements in the ELOG config file. E.g. if the number of logbooks gets large, people might choose to put old logbooks to an archive disk which is then stored on some shelf. If a user then wants to access these, the disk could be mounted again (say, under /elog-archive). But since we don't know which archive disk has been mounted, and in order to keep the main config file small, the best would be to have the configurations for the logbooks of each disk on the disk itself (say, in a file called additional.config). We could then have a line like#include /elog-archive/additional.config in the main config file. When the elogd is (re)started, it would try to include that file. If it finds none (because no archive disk is mounted) it would silently ignore this. But if it finds such a file, it would include the logbook definitions found therein.
|
I will put this feature on the wishlist. |
Re: #include statements and attachment visibility, posted by Yoshio Imai on Thu Mar 6 18:19:48 2008
|
Thanks you! I just installed the new revision, and it works.
However, it does not seem to work in list mode (with attach=1 option): elog still shows all the lines of attached text files there.
I also noticed that the images referenced inline are also shown in the attachment list in list mode, although this post gave me the impression that in list mode, too, inline images should only be displayed inside the elog entry and not in addition as attachment.
Might this be a bug, or is there a particular reason why it is like that? |
Re: #include statements and attachment visibility, posted by Stefan Ritt on Fri Mar 7 08:01:44 2008
|
Yoshio Imai wrote: | However, it does not seem to work in list mode (with attach=1 option): elog still shows all the lines of attached text files there.
I also noticed that the images referenced inline are also shown in the attachment list in list mode, although this post gave me the impression that in list mode, too, inline images should only be displayed inside the elog entry and not in addition as attachment. |
I fixed both issues in revision #2072. |
Re: #include statements and attachment visibility, posted by Yoshio Imai on Fri Mar 7 13:07:34 2008
|
Thank you, works perfectly! |
Problem with Email Notification, posted by mike cianci on Sat Mar 1 07:40:18 2008
|
Sorry to bother you with this, but I am not a programmer and this is probably a simple question but I need some help if someone has the time.
Under Global I have the command - SMTP host = smtp.comcast.net
ELOG responds with - Error sending Email via "smtp.comcast.net": 5.1.0 sender rejected : invalid sender domain
|
Re: Problem with Email Notification, posted by Stefan Ritt on Sat Mar 1 15:08:07 2008
|
mike cianci wrote: |
Sorry to bother you with this, but I am not a programmer and this is probably a simple question but I need some help if someone has the time.
Under Global I have the command - SMTP host = smtp.comcast.net
ELOG responds with - Error sending Email via "smtp.comcast.net": 5.1.0 sender rejected : invalid sender domain
|
Your SMTP server does not accept the email send request from ELOG. That can have many reasons. Most systems are set up so that they do not accept SPAM. To do that, they do various checking of the sender address etc. Maybe you need an "Email from = mike2.cianci@comcast.net" in your config file to have a "real" sender address. Some more information you can get if you start elogd interactively in a DOS box with the "-v" flag, because then you will see all the debugging output of the communication between elogd and your SMTP server. |
Problem updating from 2.7.2 to 2.7.3, posted by Uwe on Tue Feb 26 03:06:06 2008
|
Hello,
I am trying to update from version V2.7.2-2041 to V2.7.3 but getting the attached error message. OS is Windows 2003. I installed the update on Windows XP without a problem. Does anybody know ho to solve that problem? Thanks!
Uwe
|
Re: Problem updating from 2.7.2 to 2.7.3, posted by Stefan Ritt on Wed Feb 27 03:46:28 2008
|
Uwe wrote: |
Hello,
I am trying to update from version V2.7.2-2041 to V2.7.3 but getting the attached error message. OS is Windows 2003. I installed the update on Windows XP without a problem. Does anybody know ho to solve that problem? Thanks!
|
The shared library msvcr71.dll should be part of the operating system and placed under c:\windows\system32\msvc71.dll. If not it can be downloaded from
http://www.dlldump.com/download-dll-files.php/dllfiles/M/MSVCR71.dll/download.html |
Re: Problem updating from 2.7.2 to 2.7.3, posted by Uwe on Thu Feb 28 01:56:53 2008
|
Stefan Ritt wrote: |
Uwe wrote: |
Hello,
I am trying to update from version V2.7.2-2041 to V2.7.3 but getting the attached error message. OS is Windows 2003. I installed the update on Windows XP without a problem. Does anybody know ho to solve that problem? Thanks!
|
The shared library msvcr71.dll should be part of the operating system and placed under c:\windows\system32\msvc71.dll. If not it can be downloaded from
http://www.dlldump.com/download-dll-files.php/dllfiles/M/MSVCR71.dll/download.html
|
Thanks, that fixed it... |
elog hand once mirror started, posted by stephane on Thu Feb 21 12:55:56 2008
|
Hello,
When I started elogd on the mirror server, I can access to the website on it until cron job started. Once cron job started, the elog mirror server hang and I can't obtain any response on it.
How can I solve this problem ?
Kind regards
Stéphane |
Re: elog hand once mirror started, posted by Stefan Ritt on Thu Feb 21 14:36:32 2008
|
stephane wrote: |
Hello,
When I started elogd on the mirror server, I can access to the website on it until cron job started. Once cron job started, the elog mirror server hang and I can't obtain any response on it.
How can I solve this problem ?
|
With this information I cannot diagnose the problem. I would recommend you to run the elogd on the mirror server in interactive mode with the "-v" flag, so you see all net traffic. Maybe this sheds some light on the problem. |
Re: elog hand once mirror started, posted by stephane on Thu Feb 21 15:09:25 2008
|
Stefan Ritt wrote: |
stephane wrote: |
Hello,
When I started elogd on the mirror server, I can access to the website on it until cron job started. Once cron job started, the elog mirror server hang and I can't obtain any response on it.
How can I solve this problem ?
|
With this information I cannot diagnose the problem. I would recommend you to run the elogd on the mirror server in interactive mode with the "-v" flag, so you see all net traffic. Maybe this sheds some light on the problem.
|
Hello,
The server hang at this point :
ID362 : 45F505AF26644D7F71A2AF6E9822554D
Cache : 45F505AF26644D7F71A2AF6E9822554D
Remote : 45F505AF26644D7F71A2AF6E9822554D
I can't stop the process with ctrl+c
Kind regards
Stéphane |
Re: elog hand once mirror started, posted by Stefan Ritt on Thu Feb 21 17:18:55 2008
|
stephane wrote: |
Hello,
The server hang at this point :
ID362 : 45F505AF26644D7F71A2AF6E9822554D
Cache : 45F505AF26644D7F71A2AF6E9822554D
Remote : 45F505AF26644D7F71A2AF6E9822554D
I can't stop the process with ctrl+c
|
No, that does not help me to come to a conclusion. So I have no idea what's going on. When you do mirroring, you can start the synchronization from both server sides. Can you maybe try to do that from the "other" server? Maybe you have some firewall problem. |
Re: elog hand once mirror started, posted by stephane on Fri Feb 22 06:32:48 2008
|
Stefan Ritt wrote: |
stephane wrote: |
Hello,
The server hang at this point :
ID362 : 45F505AF26644D7F71A2AF6E9822554D
Cache : 45F505AF26644D7F71A2AF6E9822554D
Remote : 45F505AF26644D7F71A2AF6E9822554D
I can't stop the process with ctrl+c
|
No, that does not help me to come to a conclusion. So I have no idea what's going on. When you do mirroring, you can start the synchronization from both server sides. Can you maybe try to do that from the "other" server? Maybe you have some firewall problem.
|
How can I put the output in a file to send it to you ?
|
Re: elog hand once mirror started, posted by stephane on Fri Feb 22 08:38:38 2008
|
stephane wrote: |
Stefan Ritt wrote: |
stephane wrote: |
Hello,
The server hang at this point :
ID362 : 45F505AF26644D7F71A2AF6E9822554D
Cache : 45F505AF26644D7F71A2AF6E9822554D
Remote : 45F505AF26644D7F71A2AF6E9822554D
I can't stop the process with ctrl+c
|
No, that does not help me to come to a conclusion. So I have no idea what's going on. When you do mirroring, you can start the synchronization from both server sides. Can you maybe try to do that from the "other" server? Maybe you have some firewall problem.
|
How can I put the output in a file to send it to you ?
|
I solve my mirror problem. It came from old logbooks made with old elog version. I replicate these manually and exclude them from mirror.
Kind regards
Stéphane |
elog hand on destination mirror server, posted by stephane on Thu Feb 21 12:50:53 2008
|
Hello,
When I start elogd on the mirror destination server, until cron job started, I can access to the website normaly. Once cron job started, I can't access to the website of the elog mirror destination server.
How can I solve this problem ?
Kind regards
Stéphane |
|