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

Re: Processo zumbi]

Oi Marcos... :)

Então, descobri a seguinte árvore, mas pelo que entendi o pai não morreu, ou estou errada:

       1  5361  5361  5361 ?          -1 Ss      0   0:00 /bin/sh /command/svscanboot
5361  5363  5361  5361 ?           -1 S        0   0:00  \_ svscan /service
5363  5365  5361  5361 ?           -1 S        0   0:00  |   \_ supervise tinydns
5365 19440  5361  5361 ?          -1 Z        0   0:00  |   |   \_ [tinydns] <defunct>
5363  5366  5361  5361 ?           -1 S        0   0:00  |   \_ supervise log
5366  5370  5361  5361 ?           -1 S     1002   0:00  |   |   \_ multilog t ./main
5363  5367  5361  5361 ?           -1 S        0   0:00  |   \_ supervise dnscache
5367  5372  5361  5361 ?           -1 S     1001   0:02  |   |   \_ [dnscache]
5363  5368  5361  5361 ?           -1 S        0   0:00  |   \_ supervise log
5368  5371  5361  5361 ?           -1 S     1002   0:00  |       \_ multilog t ./main
5361  5364  5361  5361 ?           -1 S        0   0:00  \_ readproctitle service errors: ...............................

The svscanboot program
svscanboot starts svscan in the /service directory, with output and error messages logged through readproctitle.

svscanboot is available in daemontools 0.75 and above.

Interface 

     svscanboot

svscanboot runs the pipeline

     svscan /service 2>&1 | readproctitle service errors: .....
with 400 dots. The last 400 bytes of error messages from svscan will be visible to ps through readproctitle.

svscanboot sets $PATH to

     /command:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
and clears all other environment variables. Program writers are encouraged to use globally allocated names in /command.

The svscan program
svscan starts and monitors a collection of services.

Interface

svscan starts one supervise process for each subdirectory of the current directory, up to a limit of 1000 subdirectories. svscan skips subdirectory names starting with dots. supervise must be in svscan's path.

svscan optionally starts a pair of supervise processes, one for a subdirectory s, one for s/log, with a pipe between them. It does this if the name s is at most 255 bytes long and s/log exists. (In versions 0.70 and below, it does this if s is sticky.) svscan needs two free descriptors for each pipe.

Every five seconds, svscan checks for subdirectories again. If it sees a new subdirectory, it starts a new supervise process. If it sees an old subdirectory where a supervise process has exited, it restarts the supervise process. In the log case it reuses the same pipe so that no data is lost.

svscan is designed to run forever. If it has trouble creating a pipe or running supervise, it prints a message to stderr; it will try again five seconds later.

If svscan is given a command-line argument, it switches to that directory when it starts.

The readproctitle program
readproctitle maintains an automatically rotated log in memory for inspection by ps.

readproctitle is available in daemontools 0.75 and above.

Interface 

     readproctitle L D
L consists of any number of arguments. D is one argument consisting of at least five dots.

readproctitle reads data into the end of D, shifting D to the left to make room. This means that the most recent data is visible to process-listing tools such as ps. readproctitle always leaves three dots at the left of D.

For example, if

     readproctitle io errors: ....................
reads the data 
     fatal error xyz
     warning abc
then its command-line arguments change to 
     readproctitle io errors: ... xyz!warning abc!
with a newline character in place of each !. Process-listing tools typically show the newline character as ? or \n.

readproctitle exits when it reaches the end of input.

Beware that most implementations of ps have small argument-length limits. These limits apply to the total length of readproctitle L D. I have not seen a system with a limit below 512 bytes.



Em Sex, 2005-05-13 às 14:00 -0300, Marcos Vinicius Lazarini escreveu: 
Andrea Viana da Silva wrote:

> Claudio valeu mesmo !
> 
> Segundo o texto:
> 
> " o processo que se encontra nesse estado teoricamente não mais existiria, ou
> estaria "morto", porém uma copia dele ainda reside na memoria, dá o nome
> zumbi. Essa situação pode ocorrer se, por exemplo, se elimina um processo pai
> sem antes fazer o mesmo com seus filhos, pois dessa maneira o processo
> que controlava as ações dos demais não mais existe e estes perdem sua função
> passando então para o estado Z.
> 
> O processo zumbi, tira além do processamento da máquina, mémoria, 
> inviabilizando assim o uso de outros necessários ao usuário e ao sistema."
> 
> 
> O restante do texto mostra um script para matar o processo zumbi, que 
> nada mais é do que um
> kill -9 no PID no processo zumbi.
> 
> O interessante é: o PID do Zumbi, muda cada vez que pesquiso ele, sendo 
> impossivel matá-lo,
> mesmo resetando a máquina ele continua lá.

Todos os  processos ficam 'zombie' uma vez na vida - pelo menos por um 
instante de tempo.

Todo processo (filho) criado (por um pai) tem uma relação de 'paternindade'. 
  O pai tem condições de saber se o filho ainda está vivo ou não, e algumas 
outras coisas bem simples (veja um bom livro de S.O. para mais detalhes). 
Por conta dessa 'vantagem', o pai sempre é informado qdo o filho morre - 
nesse momento, o filho morreu, mas o pai ainda nao tratou a msg, 
efetivamente recebendo a mensagem; nessa situação o processo filho é fica 
como zombie até que o pai reconheca essa 'msg' e só ai o filho pode morrer 
em paz... :-)

Veja a saida de 'ps alx', e preste atençao no campo PID e PPID (Parent PID)

Uma coisa interessante: qdo vc mata o pai, todos os filhos vão embora 
juntos... qdo vc estiver logado no X, tente matá-lo pra ver se sobra alguma 
coisa... :-)

No seu caso, deve ter ocorrido algum problema com o pai, e ele não está 
tratando as msgs do filho. Se for o caso, tente matar o PPID dele

-- 
Marcos
--
Andrea Viana da Silva <andrea@csp.com.br>
CSP Controle e Automaçao Ltda
Reply to: