Hello,

Please could you help me.

We have 2 elog servers synchronized every minute via Elog mirroring function.

2 or 3 times a week, the slave crashes and we have to restart Elogd. I have found in /var/log/messages the same message every time elogd crash :

xmalloc: not enough memory

Thanks.

Dominique Bolla.

Hi,

Is there a way perhaps of implementing an email recall feature into E-Log? In other words, to recall an email before the recipient (s) read the email originating from the e-log. Something perhaps along the lines of what exists in something like Outlook.

Thks in advance.

Regards,

Niall

No, this is not implemented. What I usually do is to check "Suppress Email notification", submit and revise my entry. Once I'm satisfied, I edit again and do not check "Suppress Email notification" so that the email is finally sent out.

Hello,

I have installed the latest elog version from your web site.

My Admin user and my Login user are set in the elog.cfg to use the Self register process within the first login.

The issue is that I get only one time access to my log on the server (XP) and that is direct after the Selfregister process.

If I log out and login to test my admin and user account I will not get access to my server anymore.

My login page stays without any error message.

1 Notebook  XP Client internet explorer http://host ip:8080/demo------> 2nd Notebook XP Server

I have the deleted the cookies after each try.

I have retested later the accounts several times (login/logout) successful with the internet explorer http://host ip:8080/ on the server itself.

 Please could you help me to identify the issue?

Great, you found it! The original problem is probably related to your cookie handling. If you don't check the "keep me logged it" box, elog generates a temporary cookie, which is used for the duration of your browser session, then the browser discards it. If you theck the box, a persistent cookie is created, which your browser stores in the cookie database and reuses it for the coming 41 days. I believe you have a problem there (persistent cookies not allowed, disk full, whatever...) which does not allow handling of persistent cookies. Try from anohter browser/computer and you will see that it works.

Hi,

I'm curious is it possible to send email notificaitons from elog through an smtp server that requires SSL/TLS authentication? I think it's not but I thought I'd ask.

-Val

ps. sorry for the initial blank post...

This is currently not implemented and will probably not implemented in the next time, but it's on my (very long) to-do list.

Hi,

elogd sometimes crashes when there are large cookies. Or I'd guess it has something to do with the cookies, elogd crashed over and over again until I cleaned out cookies and authenticated sessions in firefox, then it stopped.

When I run "elogd -v" in gdb, and someone does:

GET / HTTP/1.1
Host: bba.eld.ki.sw.home.se:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; sv-SE; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,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: urem=0; TWIKISID=ecaa5a39e8446a27ec5a34bcbb9d4bcb; unm=erirone; upwd=c3w5MTg1; ipplanNoAuth=yes; SMSESSION=oKvAAv/J9WoCo6KoVdEJkhxz44G10x7TXigffOaAjLrSf0iOFrRJq97oWl32/UBQMvFslc4BgxN/VCz2K7/IRaKdFgmU4CHq/1UUv2RvdHB2HUbYbph+JgKUpAG+kN6Cc4BTwRWhmemUNhONXMRJUCfa6Tq9/osID2AT1wBFInFNww2xVmJPDSi1oltxtT345RgdGQIZbHzG2HBi1GijpiaD+4FI3WLLRzJOj3Art92BLlVDWSaPxKSdSZgVNfRSw33SupUqwD0Is2pc+ufKn4cg0azyOTLNDFOl0U5RI7K9AVgYM0NBsfDoEyBfK8pYIZTMqFFQsnWAdwYz9M2RLDBKyfMXdfGb3rrnOdPH0zvvkkoT01pZObI7dSqHD7IXLbjN/8Pt0O4eo5/SSQ7uKRGpBip0pKe3mxZYI4hsJejYwVBFegovS4qSUiL8UGDhG+lB20WEmDwIQfTG2ZtpckLC6t1CNfa5eFLWCOm+yESU+3AmP4zdJLJSqbznEl2SQTePP5NzI1R5WTAvBbsgX+N9Ab1g0Yui/i042qWNQPLg3/5c/WCHqzImi45+ov42C4mj9OcjGcAf7kaWBMwfdwfChREWkSpMrC2RRndlw+iVbShSK7lVfoCvIqk4491uQBT3bz3S0e56Vin+Oj8qbmEA/5Hp1x9b80qTRy/8lj7KLgbhV60BBvX7ahOkrIFCSjTi8y87K/u4b3KQHesNZgA7SyWRuT+vY4XCb8ANVl8eIui7vK5NNSiFFqLZ1IoeFaVu+gS/hhDu3m/rmK2t5iR2YW/aKmnGTVQsPPy/POVY/zXWgf7c6ps/sSMwTk9sy5Yr8yGYBSUrtZkn1/gK0wpqlRCcjuG991sfgr/UKbhK1dU0rI9E9PBPhvLQpjUHT49AAHL9A9S3FOs66CAFsoVo00WNqKuZcmLpEgXdpbW+mj43tiNugCT98Ec8+Iq0rZYKhYdqFu9AUOdJVXk2udBx9VkOVcRYteFICtwz3fvR02KCU3Sn3a0HKZ4wWOujUnH4nThZGVlUNyg/Of+9GKXY4mxqv/5ocEkO4q8xmAP/OJHrvgJ42kTAjaVgjlSG3b5iJTcu4jvqfC/yKU88Sw==


*** stack smashing detected ***: /root/elogd_2.7.5_2142 terminated
 

*** stack smashing detected ***: /root/elogd_2.7.5_2142 terminated

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7dad875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7daf201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7de4e5c in ?? () from /lib/tls/i686/cmov/libc.so.6
#4  0x00000000 in ?? ()
(gdb)

 Stefan,

perhaps there should be something like the bold text below in elogd.c:

int process_http_request(const char *request, int i_conn)^M
...

   /* extract cookies */^M
   if ((p = strstr(request, "Cookie:")) != NULL) {^M
      p += 6;^M
      do {^M
         p++;^M
         while (*p && *p == ' ')^M
            p++;^M
         strlcpy(str, p, sizeof(str));^M
         for (i = 0; i < (int) strlen(str); i++)^M
            if (str[i] == '=' || str[i] == ';')^M
               break;^M
         if (str[i] == '=') {^M
            str[i] = 0;^M
            p += i + 1;^M
            for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' && i < (int) sizeof(cookie); i++)
                      cookie[i] = *p++;

...

Wow, where did you get that long cookie from? Certainly not from elogd. You must run elogd under Apache, and have some other service next to it on your server which distributes this long cookies, that's why other people did not experience this problem yet. I appreciate your fix. It's alwasy nice to see users not only complain about things, but try to fix them. Your fix is almost correct, you need a

i<(int) sizeof(cookie)-1

since there is the trailing zero for terminating the cookie string. I applied your fix to SVN revision #2146.

i<(int) sizeof(cookie)-1

I the cookie is used for single-sign-on for multiple sites within company.com. So the cookie is issued for "company.com" i.e. all websites gets it even elog.company.com:8080..

I mostly fibble little bit in perl (dont need to bother with trailing zeros there ).

BR, Niklas

i<(int) sizeof(cookie)-1

 Just noticed that this fix does not work. Elog cookies e.g. "upwd" may be after other long cookies its not seen, as now it stops reading the cookie-string after 256 chars. There needs to be something that goes through the cookies and saves only elog cookies... Would probably be better if you code that, if you have time  =D

BR, niklas

Stefan,

To solve the problem I suggest following change to elogd.c (2.7.5 2159).

Create a list of elog cookies, and store only these as parameters. Example diff:

---
$ diff elog/src/elogd.c elogd_niho.c
26557a26558
>    const char *cookie_list[] = { "upwd", "unm", "elmode", "urem", "wpwd", "apwd", "uname", NULL };
26603c26604,26610
<          setparam(str, cookie);
---
>          for(i=0; cookie_list[i]; i++) {
>             if(strcmp(cookie_list[i], str) == 0) {
>                setparam(str, cookie);
>                break;
>             }
>          }
>
---

In a more readable fashion:
int process_http_request(const char *request, int i_conn)
{
...
const char *cookie_list[] = { "upwd", "unm", "elmode", "urem", "wpwd", "apwd", "uname", NULL };
...
...
...
         /* store cookie as parameter */
         for(i=0; cookie_list[i]; i++) {
            if(strcmp(cookie_list[i], str) == 0) {
               setparam(str, cookie);
               break;
            }
         }

...

Not sure if I got all the cookies used by elog.

BR, niklas

I'm not sure if this works, since your test

i < (int) sizeof(cookie)

still will stop parsing cookies if there is one which is too long. So I added your test plus changed the parsing to:

for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )

   if (i < (int) sizeof(cookie)-1)

      cookie[i++] = *p++;

   cookie[i] = 0;

The modification is in the curren SVN revision (# 2162). So have a look and check that it works.

Tried 2178 and I seem to hit some endless loop when I have big cookies. The loop seems to be in this for-loop (from gdb).

I perhaps you should have:

for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )

   if (i < (int) sizeof(cookie)-1)

      cookie[i++] = *p++;

   else
      break;

   cookie[i] = 0;

... Seems to be working for me =)

Yepp, you're right. I applied your change to the distribution code. 

Hi Stefan,

In the past I have requested the "mark whole thread" feature, not yet implimented.  At present, I 
edit (in my case) the icon on the first entry to indicate current status of the thread.  I have 
had an idea connected to this.

If you view a page, in threaded form, and collapsed, the header of the first entry of each thread is 
shown.  The order, however, is that of the timed order of the latest entry in that thread.


As an option, under the same circumstances (threaded, collapsed), if the header of the most recent 
entry was shown, then that could also be an indicator of closed thread, or of "marking whole thread" 
option (maybe would be enough for those who desire those features).  It also gives an indication of 
the current status of the thread without having to edit the original entry of the thread to edit 
(for example) the icon. 

Just a thought on how to improve a wonderful program ;-)

> In the past I have requested the "mark whole thread" feature, not yet implimented.

That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
add

Attributes = ..., Fixed
Options Fixed = boolean
Quick filter = Fixed

If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
Now if you want to mark the whole thread as fixed, do the following:

- go into list display
- display all entries in threaded mode
- click on "Select"
- select the thread you want to mark as fixed and click "Edit"
- now keep all attributes, but check the "Fixed" check box

and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
with one click.

Hi Stefan,

Must have missed it when the fixed/not fixed thread marking got implimented.

Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
states  (waiting, panic, work-in-progress....).  Clearly you can label the latest entry in a thread with the latest
status, and icon, but when in collapsed mode, you only see the initial entry.  If the latest entry were shown
(optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.



> > In the past I have requested the "mark whole thread" feature, not yet implimented.
> 
> That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
> add
> 
> Attributes = ..., Fixed
> Options Fixed = boolean
> Quick filter = Fixed
> 
> If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
> Now if you want to mark the whole thread as fixed, do the following:
> 
> - go into list display
> - display all entries in threaded mode
> - click on "Select"
> - select the thread you want to mark as fixed and click "Edit"
> - now keep all attributes, but check the "Fixed" check box
> 
> and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
> with one click.

> Hi Stefan,
> 
> Must have missed it when the fixed/not fixed thread marking got implimented.
> 
> Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
> states  (waiting, panic, work-in-progress....).  Clearly you can label the latest entry in a thread with the latest
> status, and icon, but when in collapsed mode, you only see the initial entry.  If the latest entry were shown
> (optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.

If you always mark the whole thread with states (waiting, panic, work-in-progress,...) as described in my last posting, 
then you will see this from the thread initial entry as well. If you use icons, then even more. The only disadvantage 
is that you have to discipline yourself always modifying the whole thread and not only one entry in that thread.

Apologies if these are known bugs, I'm very busy at the moment but I wanted to post this before I forget:

I'm using Safari on a Mac to make Elog entries.

1) The preview of some pdf attachments in edit mode displays huge areas of white space around each page. I can send examples if you'd like - please email me directly, for some reason I never get email notifications from this forum (and they aren't being tagged as spam, so I don't know where they go).

2) When that happens, the text entry area for ELcode format expands horizontally to match the huge pdf file width. Text without line feeds then doesn't wrap until the huge window width is filled, so I have to scroll horizontally all the time while editing to see what I've written.

3) So I turned off attachment previewing as a workaround (Preview attachments = 0 ). That worked fine by not expanding the entry area, but I noticed some odd behavior. The list of attachments below the text entry area is badly formatted. Here's a screen shot:

I tried to reproduce this with a new entry but the text was formatted properly for that entry.

P.S. While editing this entry, I see that the text area width is again being set by the width of the picture I've attached - try it yourself; if you try to resize your browser window smaller while editing, the text will only wrap until the width of the attachment is reached - the text no longer wraps at smaller widths than the attachment. 

Your problem 1) is probably caused by ImageMagick. I use that package to convert PDFs to images. If this package estimates the paper size from the PDF incorrectly, you're screwed. You can go and actually locate the thumbnail pictures in the ELOG directory (should be named  xxxxxx_yyyyyy_<name>-0.png). If you check these pictures, they are probably already huge.

Problem 3) indeed is a small bug in elogd, which I fixed in revision #2178. If you can download the SVN version and recompile elogd, you should be fine:

 Thanks for the bug fix, we'll get our installation updated ASAP. And I will look into why some of my pdf file image sizes are interpreted incorrectly by ImageMagick, it might having something to do with how I've generated them.

Is it possible to set the default image size to always scale to fit the browser window? For example, this entry has a png attachment, but it still suffers from the fact that the text window size is set by the width of the png image.

If I'm forgetting something, sorry, I'm writing in a hurry!

Dennis

Hi,

I was wondering if anybody else seen this problem and maybe has a solution. I use Elog version 2.7.5 rev. 2172 that I compiled from the tar.gz package on a Ubuntu PC. It is very strange that everything works fine except I can not view / download PDF attachments specifically. I can view / download images and I can download all sorts of file formats: xls, doc, ppt, etc. Viewing in the same window / tab or in a different one does not work. Saving the attachment produces a file empty file with the correct name! This is so strange, for example following a link from an image or any other attachment type works but if that link is a PDF file I get an empty page! When uploading a PDF file there a thumbnails that are generated, I do view the thumbnail but not the PDF itself! I didn't even managed to start a download on PDF attachment.

Any help would be appreciated!

This sounds to me like you have a problem on your browser. I know that Acrobat Reader sometimes causes problems. The current version always crashes my broswer, so I cannot display PDFs inline, I rather have to same them, and the open them for display. Maybe you have a simlar problem. Since you see the PDF thumbnails, I believe that the PDF operations indise ELOG are ok. Can you view PDFs from other websites? Have you tried another browser? Maybe on another computer?

- Stefan 

Hi,

Thanks for the reply. I just checked the access from two other computers and indeed it works. I tried to see what is the problem with my browser, I use Firefox 3.0.6 and tried to get a PDF from the web. So I do have the same problem with other sites for viewing a PDF, I mean when I click on a PDF link I get a white page and the browser does not invoke any plug-in or Acrobat Reader. But the major difference with Elog is that with other sites I can always right click on the link and do "Save as" and it starts the download and I get a valid file. With elog it does start the download but I get an empty file. Actually I checked inside and it is not really empty, it is a text file, here I attached an example (the content of the file when I tried to download a PDF from the Elog server):

gornea@hadriana ~
$ cat Ba_source_GG_Feb09.pdf
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<title>ELOG Login</title>
<link rel="stylesheet" type="text/css" href="default.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body OnLoad="document.form1.uname.focus();">
<form name=form1 method="POST" action="./" enctype="multipart/form-data">

<input type=hidden name=redir value="090219_111057/Ba_source_GG_Feb09.pdf">
<table class="dlgframe" cellspacing=0 align=center><tr><td colspan=2 class="dlgtitle">Please login</td></tr>
<tr><td align=right class="dlgform">Username:</td>
<td align=left class="dlgform"><input type=text name=uname value=""></td></tr>
<tr><td align=right class="dlgform">Password:</td>
<td align=left class="dlgform"><input type=password name=upassword></td></tr>
<tr><td align=center colspan=2 class="dlgform"><input type=checkbox checked name=remember value=1>
Keep me logged in on this computer<br>
for the next 31 days or until I log out</td></tr>
<tr><td align=center colspan=2 class="dlgform">
<a href="?cmd=Forgot">Forgot password?</a></td></tr>
<tr><td align=center colspan=2 class="dlgform"><input type=submit value="Submit"></td></tr></table>
<center><a class="bottomlink" title="Goto ELOG home page" href="https://midas.psi.ch/elog/">ELOG V2.7.5-2172</a></center></form></body></html>
 

The file you downloaded is actually the login screen of elog! So probably your login token expired between the display of the web page showing the attachemnt link and the attachment download, or you turned cookies off. So when you try to download the attachment, your user credentials are not passed as cookies together with that request and elog barks at you requiring a new login.  

 Hi,

OK but the box at login is checked to keep the login / password for 31 days and the cookies are enabled for sure. Now another user pointed out that it can not see pictures including the little icons when using Safari. I never used Safari but I got it just to see what is going on. So it took me some time but I think I have an idea now after comparing the source of a post that I read with Firefox to the one I get with Safari. Essentially the Firefox has the Javascript functions and class definitions before the HTML page starts. Very weird! Took me some time because when you view the source they both showed almost the same content (there are a few differences in <head>) ! But when I tried to save as HTML it showed this difference. Also I must mention that the problem for viewing the pdf attachments only happens with Firefox on Windows, I tried from a Linux PC and it works fine, now on Linux PC I have an older version of Firefox so maybe this has to do with Firefox version not OS. For this problem with the pictures and icons, if is not the Javascript related problem I am really totally last, how can one browser get the picture but not the other browser with the same content in the <body>!?!

 Hi Stefan,

I added a new logbook for test and posted a message with three attachments: picture file, PDF file and excel file. Could you log in and look if I did something obviously stupid? The link is:

http://exo-elog.stanford.edu/Test+logbook/

User name: testUser
Password: go

I have this specific problem with the PDF attachments and I can not see any picture or the icons with Safari. Thanks a lot!