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

Re: zombie

É, é possível. Só que vai ficar um pouco complicado porque podem existir muitas conexões simultaneamente. Antes, aliás ainda utilizo, e funciona, o tcpd. Mas como o número de acessos está almentando e ficando complicado gerenciar todos esssas conexões como atualmente gerencio. Encontrei uma forma que simplifica bastante minha administração que foi fazer com que cada micro externo, faça sua conexão utilizando uma porta específica. Só que utilizando o tcpd não dá para descobrir qual porta foi utilizada para gerar a conexão 
e blá blá blá como dito antes

Valeu

Rúben Lício escreveu:

Bom dia,
como gambiarra, eu sugeriria você criar uma linha de cron para executar o outro processo, e quando o outro iniciase, vc tiraria a linha. obviamente essa não é uma solução boa a longo prazo, mas pode servir para você dar continuidade ao script até achar uma solução realmetne boa. 

Abraços,

Rúben
On 1/16/07, *sluiz* <sluiz@webcpd.com.br <mailto:sluiz@webcpd.com.br>> wrote: 

    Valeu Rúben, mas acho que não vou ter como implementar isso em meu
    projeto
    De qualquer maneira, valeu pela resposta.

    Rúben Lício escreveu:
    > Até onde eu sei, o processo zumbi não é isso. De acordo com
    > http://aplawrence.com/SCOFAQ/FAQ_scotec6cantkill.html um processo
    > zumbie não é realmente um processo, ele foi um processo que já
    > terminou sua execução, mas por algum motivo o kernel ainda não
    liberou
    > a tabela de informações sobre o processo da memória, como
    afirmado em
    > http://wlug.org.nz/ZombieProcess
    > Neste link
    >
    http://maillist.perforce.com/pipermail/perforce-user/2001-August/006710.html
    >
    <http://maillist.perforce.com/pipermail/perforce-user/2001-August/006710.html
    <http://maillist.perforce.com/pipermail/perforce-user/2001-August/006710.html>>
    > é mostrado um meio de criar um processo zumbi .
    >
    > Agora, como matar um processo pai sem matar todos os filhos, eu não
    > sei. De uma olhada no manpage do próprio kill ou xkill.
    > O & não funciona mesmo, porque o comportamento padrão é matar
    todos os
    > filhos para evitar lixo na memória, já que normalmente processos
    > filhos são forks criados para atender algumas necessidades do
    processo
    > pai...
    >
    >
    > On 1/14/07, *sluiz* < sluiz@webcpd.com.br
    <mailto:sluiz@webcpd.com.br> <mailto:sluiz@webcpd.com.br
    <mailto:sluiz@webcpd.com.br>>>
    > wrote:
    >
    >
    >     Estou precisando criar um processo zombei, ou seja, preciso
    matar o
    >     processo
    >     pai e manter o filho funcionando. Toda vez que utilizo kill -9
    >     $PPID mato o
    >     processo atual também. Já tentei executar o script filho com
    & no
    >     final, já
    >     tentei nohup, mas não adianta esse filho tá muito ligado ao
    pai.
    >     Aguém tem ulguma idéi para separar esse dois?
    >
    >     Veleu
    >
    >
    >     --
    >     To UNSUBSCRIBE, email to
    >     debian-user-portuguese-REQUEST@lists.debian.org
    <mailto:debian-user-portuguese-REQUEST@lists.debian.org>
    >     <mailto:debian-user-portuguese-REQUEST@lists.debian.org
    <mailto:debian-user-portuguese-REQUEST@lists.debian.org>>
    >     with a subject of "unsubscribe". Trouble? Contact
    >     listmaster@lists.debian.org
    <mailto:listmaster@lists.debian.org>
    <mailto:listmaster@lists.debian.org
    <mailto:listmaster@lists.debian.org>>
    >
    >
    >
    >
    > --
    > Rúben Lício Reis
    >
    > www.rubenlr.com.br <http://www.rubenlr.com.br>
    <http://www.rubenlr.com.br>
    > Linux user #433535
    > Linux because we are freedon.


    --
    To UNSUBSCRIBE, email to
    debian-user-portuguese-REQUEST@lists.debian.org
    <mailto:debian-user-portuguese-REQUEST@lists.debian.org>
    with a subject of "unsubscribe". Trouble? Contact
    listmaster@lists.debian.org <mailto:listmaster@lists.debian.org>




--
Rúben Lício Reis

www.rubenlr.com.br <http://www.rubenlr.com.br>
Linux user #433535
Linux because we are freedon.
Reply to: