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

Re: [multitail] Re: WARNING



that should not give zombies as no processes exit for that. well, no
multitail-induced processes (as the zombies were multitails, right?)


On Mon, Apr 03, 2006 at 08:51:29PM +0100, Pedro Alves wrote:
> 
> 
> 
> Wild, wild guess... rotating log files?
> 
> 
> On Mon, Apr 03, 2006 at 12:39:10PM -0700, Michael McDaniel wrote:
> > 
> > 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
> > 
> > 
> > 
> > --------------------------------------------------------------------------------------
> > This message was sent through the MultiTail mailinglist (www.vanheusden.com/multitail)
> 
> -- 
> Pedro Alves
> pedro.alves@zmail.pt
> 
> 
> 
> --------------------------------------------------------------------------------------
> This message was sent through the MultiTail mailinglist (www.vanheusden.com/multitail)


Folkert van Heusden

-- 
Feeling generous? -> http://www.vanheusden.com/wishlist.php
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com