ELOG Forum

Demo Discussion

Forum Config Examples Contributions Vulnerabilities

Discussion forum about ELOG, Page 777 of 806

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

6445 Entries

Goto page Previous 1, 2, 3 ... 776, 777, 778 ... 804, 805, 806 Next

Wed Jun 24 15:02:49 2009

Auto-increment substitutions broken with records for multiple days

With a logbook defined by 

 [test]
 Theme = default
 Comment = Test of auto-increment
 Attributes = Batch
 Subst Batch = %Y%m%d-##

the auto-incrementing of the Batch attribute within dates works when the logbook contains only entries for
today's date but otherwise will give a batch number of "01" for each entry.  

Changing line 8714 of elogd.c as follows, from:

      /* if date part changed, start over with index */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
         old_index = 0;   
      else
         /* retrieve old index */
      if (atoi(attrib[index] + loc) > old_index)
         old_index = atoi(attrib[index] + loc);
to
      /* if date part changed, start over with index */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
         break;            /* <------------- */
      else
         /* retrieve old index */
      if (atoi(attrib[index] + loc) > old_index)
         old_index = atoi(attrib[index] + loc);

appears to fix this bug when I test it.  This code is inside a loop stepping back through all log entries, and
the variable old_index is already set to zero before the loop. The existing code resets old_index whenever the
prefix of the attribute string (containing a date) does not match the "current" value of that prefix as found in
retstr (set using strftime).  So, if there are any records for dates other than today then old_index is reset
and attribute values will be set with the counter = (old_index+1) = 1.  The modified version stops comparisons
once a different date is seen, but assumes that records are date ordered.  An alternative patch:

      /* if date part matches */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
          /* retrieve old index */
         if (atoi(attrib[index] + loc) > old_index)
            old_index = atoi(attrib[index] + loc);
  
does not make this assumption and also appears to work OK when I test it.

66414

Thu Jun 25 10:09:18 2009

Re: Auto-increment substitutions broken with records for multiple days

> An alternative patch:
> 
>       /* if date part matches */
>       if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
>           /* retrieve old index */
>          if (atoi(attrib[index] + loc) > old_index)
>             old_index = atoi(attrib[index] + loc);
>   
> does not make this assumption and also appears to work OK when I test it.

Yes, this is the right one, it searches all entries to have the same date than the current one, and then looks for the 
largest index which will be stored in old_index and later incremented by one. I committed your patch to the 
repository. Thanks a lot.

66638

Thu Dec 3 20:25:50 2009

elogd keeps crashing, any thoughts?

We are trying to track down an issue where elogd just stops, and I cannot seem to find a cause.

In the logs, I see:
Dec 3 14:01:23 nissrv18a kernel: [419738.139675] elogd[32003]: segfault at 4 ip 00007f183b19b560 sp 00007fff79f5e278 error 4
in libc-2.10.1.so[7f183b119000+166000]

Any thoughts?

66639

Fri Dec 4 23:45:56 2009

Re: elogd keeps crashing, any thoughts?

Allen wrote:

We are trying to track down an issue where elogd just stops, and I cannot seem to find a cause.

In the logs, I see:
Dec 3 14:01:23 nissrv18a kernel: [419738.139675] elogd[32003]: segfault at 4 ip 00007f183b19b560 sp 00007fff79f5e278 error 4
in libc-2.10.1.so[7f183b119000+166000]

Any thoughts?

I need more information about that. Please have a look at Faq #19.

67069

Fri May 20 22:45:00 2011

my_shell (OS_UNIX) uses /tmp/elog_shell - conflict when more than one elogd runs at the same time

all instances of elogd use the same file name in /tmp when calling my_shell. This can cause some inconsistent behavior when two or more copies of elogd are runnnig at the same time. (eg. one might detect ImageMagik is installed, and the other not,)

The propsed solution is to have the parent read from a pipe to the child rather from a file. A patch is attached.

Attachment 1: elogd.c.patch_shellPipe

--- elogd.c.orig	2011-05-20 13:28:48.000000000 -0600
+++ elogd.c	2011-05-20 14:16:12.000000000 -0600
@@ -866,25 +866,27 @@
 
 #ifdef OS_UNIX
    pid_t child_pid;
-   int fh, status, i;
+   int fd[2], status, i;
    char str[256];
 
+   /* create pipe for parent<->child communication */
+   if (pipe(fd) < 0)
+      return 0;
+
    if ((child_pid = fork()) < 0)
       return 0;
    else if (child_pid > 0) {
-      /* parent process waits for child */
-      waitpid(child_pid, &status, 0);
+
+      /* parent does not write to child */
+      close(fd[1]);
 
       /* read back result */
       memset(result, 0, size);
-      fh = open("/tmp/elog-shell", O_RDONLY);
-      if (fh > 0) {
-         i = read(fh, result, size);
-         close(fh);
-      }
+      i = read(fd[0], result, size);
+      close(fd[0]);
 
-      /* remove temporary file */
-      remove("/tmp/elog-shell");
+      /* parent process waits for child */
+      waitpid(child_pid, &status, 0);
 
       /* strip trailing CR/LF */
       while (strlen(result) > 0 && (result[strlen(result) - 1] == '\r' || result[strlen(result) - 1] == '\n'))
@@ -926,8 +928,7 @@
             eprintf("Falling back to user \"%s\"\n", str);
       }
 
-      /* execute shell with redirection to /tmp/elog-shell */
-      sprintf(str, "/bin/sh -c \"%s\" > /tmp/elog-shell 2>&1", cmd);
+      /* execute command with redirection to pipe to parent */
 
       if (is_verbose()) {
          efputs("Going to execute: ");
@@ -935,7 +936,17 @@
          efputs("\n");
       }
 
-      system(str);
+      /* redirect stdout/stderr to pipe for parent to read */
+      close(STDOUT_FILENO); dup2(fd[1], STDOUT_FILENO);
+      close(STDERR_FILENO); dup2(fd[1], STDERR_FILENO);
+      /* child does not read the pipe */
+      close(fd[0]);
+      /* child nolonger uses fd[1] - use stderr or stdout instead */
+      close(fd[1]);
+      
+      if (system(cmd) == -1) {
+          fprintf(stderr, "unable to execute command: %s\n", cmd);
+      }
       _exit(0);
    }

67123

Tue Sep 13 13:38:19 2011

Andreas Luedeke

andreas.luedeke@psi.ch

Bug fix

Linux

2.9.0-2414

Re: Elog crashes with URL find npp=0

> [...] It appears that npp=0 crashes elogd [...]

Here's a patch: search for "npp" in src/elogd.c and add the following line:
  if (n_page<=0) n_page = 20;

Here's the diff output for version 2.9.0-2414
*** 20092,20096 ****
     if (isparam("npp"))
        n_page = atoi(getparam("npp"));
+    if (n_page<=0) n_page = 20;

     if (page_mid) {

67184

Sat Feb 11 05:43:33 2012

Andreas Luedeke

andreas.luedeke@psi.ch

John Doroshenko wrote:

Olaf Kasten wrote:

Hi there,

I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't connect to the elog server with ssl = 1 in elogd.cfg.

I tested with Firefox 3.6 and IE 7 installations and there are no problems.

I guess it's a bug. Does someone have a suggestion to solve that problem?

Thx. Olaf

Hi!

This just started happening here also. Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome. SAFARI works. Occurs in 2.8.0 and a newly built (even after

ssl yum updates) 2.9.0 version on SL5.5 system. Seems to accept self signed cert then nothing.. (connection reset message). Tried an stunnel from one port to port running elog

with SSL=0. Same behavior. Doesn't work on some browsers. Any clues?

Thanks,

-John

Hi everyone,

it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:

Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.

I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.

To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.

I hope this settles the matter.

Cheers

Andreas

PS: I've solved this with the help of google : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls

67186

Sat Feb 11 22:05:36 2012

Andreas Luedeke wrote:

John Doroshenko wrote:

Olaf Kasten wrote:

Hi there,

I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't connect to the elog server with ssl = 1 in elogd.cfg.

I tested with Firefox 3.6 and IE 7 installations and there are no problems.

I guess it's a bug. Does someone have a suggestion to solve that problem?

Thx. Olaf

Hi!

ssl yum updates) 2.9.0 version on SL5.5 system. Seems to accept self signed cert then nothing.. (connection reset message). Tried an stunnel from one port to port running elog

with SSL=0. Same behavior. Doesn't work on some browsers. Any clues?

Thanks,

-John

Hi everyone,

it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:

Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.

I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.

To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.

I hope this settles the matter.

Cheers

Andreas

⇄

Detect language » English

PS: I've solved this with the help of google : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls

Hi all,

it is NOT the firewall. First off, I don't use a firewall. 2. I AM our computing division. 3. if it were the firewall blocking the access, why do I see "TCP connection broken" in the elog log file? 4. it's not working on port 443 either.

Something's flaky in elog's https implementation. For me it's not a big deal any more, as I use an apache reverse proxy in production now anyway, but other people may not.

thanks,

-Christian

Goto page Previous 1, 2, 3 ... 776, 777, 778 ... 804, 805, 806 Next

ELOG V3.1.5-3fb85fa6