Re: (my) Firefox breaks Elog with this config file, posted by Stefan Ritt on Thu Jun 25 10:51:12 2009
|
Michael Husbyn wrote: |
Stefan Ritt wrote: |
Michael Husbyn wrote: |
Stefan Ritt wrote: |
Michael Husbyn wrote: |
Hi, Did a fresh install on a Windows 2003 server (and tried it on my personal computer) After startup I can click on Norway/nor, and then the server just stops responding. I see in the log nothing, the last line: Received unknown cooke "style" Then it stops responding and after a few seconds I see the dos window returns to commandline prompt. Probably a very bad config file. On Windows XP it informs we of Dr Watson, memory could not be read message. Using Firefox 3.0.11 But if I use IE 7, no problem at all.. Any suggestion? Best regards Michael Husbyn |
This must be related to the unknown cookie "style". There was some work recently on elog to make it robust against unknonw cookies. The latest modification was on version 2192, and you probably have an older version. I made a release elog276-2.exe for you. Try it and let me know. You can also just delete your cookies in Firefor and it should be fine, but it's better not being able to crash elog.
|
Sure I will try, but I cannot find the version you are talking about in the download section. Should I find it there or any other place? Thanks for quick feedback |
It's here.
|
Looks more stable, but it still quits. Sometimes just entering the logbook, sometimes when I hit the config button. ==== Return ================================ <549 bytes of favicon.ico> TCP connection broken GET /nor/elog.rdf HTTP/1.1 Host: XXSERVERNAMEHEREXX:8091 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.11) Gecko/2 009060215 Firefox/3.0.11 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: elmode=Summary and just quits Strange |
Ah, the GET /nor/elog.rdf gave me somt hint: Your Firefox browser checks the RSS feed of elog regularly. If the logbook is empty, the routing producing the elog.rdf file went into some kind of infinite loop, but this only happens on an empty logbook. If fixed this and updated the 276-2 file just now, so try again. |
Re: Denial of access after failed import using invalid attributes, posted by Stefan Ritt on Thu Jun 25 12:30:17 2009
|
soren poulsen wrote: |
Hi,
A user tried to import a CSV file, which caused e-log to add a field called "date" to the list of attributes (and then crash). This caused the log-book to be blocked until someone (guess who) would go edit the elogd.cfg file and then trigger a reload.
1. suggestion : E-log should not crash in this case
2. suggestion: E-log should not allow invalid attributes to be added via CSV Import, which causes the log-book to be blocked.
For the time being, I will just "Deny import" (by the way, the doc says it is "Deny CSV import", but I think the syntax is "Deny import". Not really important.
I think this should be quite easy to reproduce.
Thanks a lot
Soren
|
If the CSV file contains a "date" column, elogd tries to interprete the date to the internal format. Now a date can be written in a huge number of variations, and I'm sure I did not cover all. So please send me your CSV file and I will fix the crash. |
Re: Formatting list page data, posted by Stefan Ritt on Thu Jun 25 15:02:55 2009
|
Steve Williamson wrote: |
Thanks for a great piece of software - it does so much and is (mostly) so simple to use. However, I do have a suggestion that (for me, at least) would make it even better -
I use elog for a variety of logging tasks but find that, because I want to see as complete a summary as possible, the list page can get very crowded with longer fields wrapping over several lines. I would like to have more control over the way attributes are displayed here. Specifically, being able to truncate data (e.g. to show just the first n characters of a description), being able to select a substring (e.g. displaying characters before the '@' character to remove the domain from an email address or displaying characters after the space to remove the day from a date in ddd dd/mm/yy format) and being able to concatenate fields (e.g. to show a reference in a single cell as "Incident 1234" by joining call type and call reference attributes).
regards
Steve
|
Something along these lines is however not implemented (and hard to do). The only chance you have is to export your data into a spreadsheet and do the reformatting/report generation there. |
Re: Export and save problem with IE7, posted by Stefan Ritt on Thu Jun 25 15:37:14 2009
|
soren poulsen wrote: |
Hi
Would it be possible to use the "Export to:" function with IE7 on the Forum logbook, and save the logbook.
I can do the export but saving the file with IE7 does not work. Saving the file with Firefox, Chrome, Safari works.
This makes me think that E-log is good and IE7 is bad ?
Soren
|
Right
It seems to be a well known probmel with IE: http://classicasp.aspfaq.com/files/directories-fso/how-do-i-send-the-correct-filename-with-binarywrite.html
So I tried all variations there, but none of them worked. The interesting thing is that it works if you use it locally, but not with the forum (which has an additional "/elogs" in the URL).
|
Re: Move to: elog crashes with large no of entries being moved., posted by Stefan Ritt on Thu Jun 25 15:55:04 2009
|
> Hi Stefan,
>
> I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.
>
> In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
> crashes with "Segmentation Fault". It does not erase the lock file /var/run/elog.pid
>
> I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.
>
> I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
> "content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
> twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
> was some factor within elog that could affect this.
>
> I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
> to: is the deletion of the thread after all the entries had been copied.
I reworked the internal memory allocation, since there was a stack overflow going over 24 entries. It should be now
much better. Give a try to revision 2226. |
Re: synchronization, posted by Stefan Ritt on Thu Jun 25 16:30:24 2009
|
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 |
Re: attached picture size changed, posted by Stefan Ritt on Fri Jun 26 08:15:16 2009
|
weiluo wrote: |
Hello everyone.
Here I found a problem recently with attaching screen-shot to the elog.
I am using "elog -f xxx/xxx.gif" to make elog entry. Recently I found my attached pictures were scaled to the half of the original size horizontally appearing in the log entry, the other half of the picture was filled with black. I need to click it once to magnify the picture to see it.
Does anyone know how to solve this problem? It bugs me a lot.
By the way, I saw some pictures were produced with the name "xxx.gif.png" in the logbook directory.
Thanks, and one of the modified picture is attached.
|
When you submit a picture, elogd calls the ImageMagick package to generate a thumbnail out of it, therefore you get the "xxx.gif.png" file (which represents the thumbnail). If you create your GIF images with the ROOT package, ImageMagick will give problems because ROOT does not use standard GIF encoding, therefor the black border on your pictures. You can turn off the thumbnail generation completely by specifying
Thumbnail size = 0
in the configuration file. This option was just introduced recently, so please update to SVN revision 2227 for this option to work. |
Re: Checks on datetime seconds field generate warning in IE7, posted by Stefan Ritt on Thu Jul 2 08:36:57 2009
|
Richard Stamper wrote: |
When adding a log entry containing a datetime field using the IE7 browser a Javascript warning is displayed - see the attachment. This is due to a change in the naming of the "seconds" field of a datetime entry (made in version 2143) not being propagated to the code that generates the Javascript that checks the supplied values.
Suggested patch follows.
Change "s%d" to "c%d" in lines 9675 and 9678.
Showing lines 9675-9680 below, change from:
rsprintf(" if (document.form1.s%d.value == \"\") {\n", i);
sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
rsprintf(" alert(\"%s\");\n", str);
rsprintf(" document.form1.s%d.focus();\n", i);
rsprintf(" return false;\n");
rsprintf(" }\n");
to:
rsprintf(" if (document.form1.c%d.value == \"\") {\n", i);
sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
rsprintf(" alert(\"%s\");\n", str);
rsprintf(" document.form1.c%d.focus();\n", i);
rsprintf(" return false;\n");
rsprintf(" }\n");
Regards,
Richard Stamper
|
This is absolutely correct, even the right fix. I put that into the distribution. Thanks a lot. |
|