[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [multitail] Re: WARNING



Thanks for the info, Tony.

The machine is a SuSE 9.i-don't-remember which, prior to today,
had been running for about seven months with no downtime except
the brief exceptions when I'd do a postfix or policy server
upgrade (though then only long enough to restart or reload the
upgraded piece).  It is a multi-virtual-domain email server using
postfix, courier imaps/pops and offering login via Apache/SquirrelMail.
The pertinent pieces were compiled using gcc v3.3.4 (a bit of an
old version though I've never seen any problems).  Oh, and mysql
from a MySQL rpm.

I do use screen.  I am familiar with reattaching though have not
taken advantage of using it on remote machines over ssh. I will
look into that.

At the end of your post you state 

      "there are ways to avoid zombie processes"

though I went to your link and did not see any information about it.
What ways do you have in mind?


One new possibility occurs to me and it has the feel of "sure,
that must be it" but I need a real technical reason to be 
satisfied it *is* it.  Also, it seems to me that I should have
had problems sooner than today if this is the cause.  "This" is
that the copy of multitail running on the SuSE machine was copied
over to it from my Debian (Ubuntu) laptop.

Two things are obvious to me:
1) The libraries must have *some* compatibility else it would never
   have run.

2) The libraries are different to some degree between the machines.
   (Actually, this is not obvious, it is my belief because my laptop
    is a newer Debian vs. an older SuSE).

And now, doing the following, maybe there is no difference in the
libraries at all.  

libutil could be a problem; what function calls are called from libutil?


ON THE SuSE MACHINE  (this multitail was compiled on the Debian machine)

$ ldd multitail
        linux-gate.so.1 =>  (0xffffe000)
        libpanel.so.5 => /usr/lib/libpanel.so.5 (0xb7f6b000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb7f2a000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7f25000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f02000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dd4000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7dd0000)
        /lib/ld-linux.so.2 (0xb7f7e000)

$ ls -gGl /usr/lib/libpanel.so.5
lrwxrwxrwx  1 15 2005-03-26 19:13 /usr/lib/libpanel.so.5 -> libpanel.so.5.4

$ ls -gGl /lib/libncurses.so.5
lrwxrwxrwx  1 17 2005-03-26 19:13 /lib/libncurses.so.5 -> libncurses.so.5.4

$ ls -gGl /lib/tls/i686/cmov/libutil.so.1
/bin/ls: /lib/tls/i686/cmov/libutil.so.1: No such file or directory

$ ls -gGl /lib/tls/i686/cmov/libm.so.6
/bin/ls: /lib/tls/i686/cmov/libm.so.6: No such file or directory

$ ls -gGl  /lib/tls/i686/cmov/libc.so.6
/bin/ls: /lib/tls/i686/cmov/libc.so.6: No such file or directory

$ ls -gGl /lib/tls/i686/cmov/libdl.so.2
/bin/ls: /lib/tls/i686/cmov/libdl.so.2: No such file or directory

$ ls -gGl /lib/ld-linux.so.2
lrwxrwxrwx  1 11 2005-03-26 19:13 /lib/ld-linux.so.2 -> ld-2.3.3.so


If calls were made to the missing libraries I would expect immediate
problems.

QUESTIONS:
1) Anyone know the definitive command to check which glibc is being
   used on the respective machines? 

2) Anyone have a definitive reason why compiling/copying *would* be
   a problem?

If I can find a definitive technical answer to #2 I will feel safe in
recompiling directly on the SuSE machine and using multitail.  However,
I can't afford to bring down this machine again anytime in the near
future.

I am leaning towards the compile/copy as being the problem though I
would like to understand exactly why.  I have recompiled multitail
on the SuSE machine and now ...


$ ldd multitail
        linux-gate.so.1 =>  (0xffffe000)
        libpanel.so.5 => /usr/lib/libpanel.so.5 (0x4001f000)
        libncurses.so.5 => /lib/libncurses.so.5 (0x40024000)
        libutil.so.1 => /lib/libutil.so.1 (0x40069000)
        libm.so.6 => /lib/tls/libm.so.6 (0x4006d000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40090000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ ls -gGl /usr/lib/libpanel.so.5
lrwxrwxrwx  1 15 2005-03-26 19:13 /usr/lib/libpanel.so.5 -> libpanel.so.5.4

$ ls -gGl /lib/libncurses.so.5
lrwxrwxrwx  1 17 2005-03-26 19:13 /lib/libncurses.so.5 -> libncurses.so.5.4

$ ls -gGl /lib/libutil.so.1
-rwxr-xr-x  1 12643 2004-10-05 05:08 /lib/libutil.so.1

$ ls -gGl /lib/tls/libm.so.6
-rwxr-xr-x  1 174623 2004-10-05 05:21 /lib/tls/libm.so.6

$ ls -gGl /lib/tls/libc.so.6
-rwxr-xr-x  1 1359489 2004-10-05 05:21 /lib/tls/libc.so.6

$ ls -gGl /lib/ld-linux.so.2
lrwxrwxrwx  1 11 2005-03-26 19:13 /lib/ld-linux.so.2 -> ld-2.3.3.so

(I still have not run it to try and reproduce the problem!)


I would really like to find out exactly what happened because multitail
is very useful for keeping track of my remote charges.

thanks, all,


~Michael




On Mon, Apr 03, 2006 at 02:56:35PM -0400, tony summerfelt wrote:
> On Mon, 3 Apr 2006 11:30:01 -0700, you wrote:
> 
> 
> >  Is it possible that ^Z (placing multimail in background) could
> >  cause problems?
> 
> doesn't unexpected termination (ie. not waiting for the child process)
> of a parent process cause zombies?
> 
> out of curiosity is this a redhat machine? i know there was  a problem
> with some verisons of redhat ignoring the SIGCHLD signal... and
> multitail uses that in it's ui.c code. if you send it to the
> background that COULD be the problem.
> 
> i always use 'screen' myself. i use "screen -S mt" and then run
> multitail.
> 
> when i connect via ssh on another machine i can do:
> screen -D -R mt
> 
> and i get my multitail session back. 
> 
> the screen/ssh combination is very nice if you're never around a
> server machine :)
> 
> there are ways to avoid zombie processes
> 
> http://home.cogeco.ca/~tsummerfelt1
> telnet://ventedspleen.dyndns.org
> 

> --------------------------------------------------------------------------------------
> This message was sent through the MultiTail mailinglist (www.vanheusden.com/multitail)


-- 
Michael McDaniel
Portland, Oregon, USA
http://autosys.us
+1 503 283 5284