Ajuda a decifrar 'ps' e 'pstree' com 'cron' e 'sudo'

4

Desculpe por essa captura de tela colorida, mas acho que ela ajuda a destacar melhor o problema do que copiar & amp; colar + formato de código:

Aqui está a mesma tela em formato de código:

───────────────────────────────────────────────────────────────────────────────
rick@dell:~$ ps a | grep display-
26457 pts/2    S+     0:00 grep --color=auto display-
───────────────────────────────────────────────────────────────────────────────
rick@dell:~$ ps a | grep display-
28927 pts/18   S+     0:00 sudo /usr/local/bin/display-auto-brightness
29174 pts/18   S+     0:00 /bin/bash /usr/local/bin/display-auto-brightness
30183 pts/2    S+     0:00 grep --color=auto display-
───────────────────────────────────────────────────────────────────────────────
rick@dell:~$ pstree | grep display-
        |-cron---cron---sh---display-auto-br---sleep
        |         |         |         |                 |-bash---sudo---display-auto-br---sleep
───────────────────────────────────────────────────────────────────────────────
rick@dell:~$ ps a | grep cron
16031 pts/2    S+     0:00 grep --color=auto cron
───────────────────────────────────────────────────────────────────────────────
rick@dell:~$ ps a | grep display
26773 pts/2    S+     0:00 grep --color=auto display
28927 pts/18   S+     0:00 sudo /usr/local/bin/display-auto-brightness
29174 pts/18   S+     0:00 /bin/bash /usr/local/bin/display-auto-brightness
───────────────────────────────────────────────────────────────────────────────

Esta manhã, depois de reiniciar o cron job - /etc/cron.d/display-auto-brightness deve ter iniciado. Eu pensei que nunca começou com base na primeira seção.

Eu iniciei manualmente o script com sudo /usr/local/bin/display-auto-brightness . A segunda seção mostra como ps retorna dois IDs de processo para o único trabalho. Uma vez a elevação de sudo que iniciou o trabalho e a segunda para o próprio script.

Existe uma maneira programática de identificar esses dois PIDs como um trabalho? O motivo da próxima etapa de desenvolvimento é ao retomar da suspensão para ver se o único trabalho (não dois processos) já está em execução e matá-lo ao iniciar o mesmo trabalho novamente. Isso proporcionará um ajuste instantâneo de brilho da tela se for retomado à luz do dia após a suspensão no escuro ou vice-versa.

Na terceira seção, usei o comando pstree e descobri que a tarefa cron que não aparece com o comando ps está sendo exibida aqui. Por que isso acontece? .

Na quarta seção canopro ps de saída através de grep usando cron como filtro e nada aparece. Por que isso acontece?

Na quinta e última seção, repito a segunda seção ps a | grep display- para reafirmar as descobertas anteriores.

Editar 1

Acho que descobri por que a quarta seção não mostra cron em execução. É por causa do status normal do usuário, enquanto o cron está rodando como root. A solução é usar:

$ sudo ps aux | grep cron
root      1122  0.0  0.0  29008  2936 ?        Ss   04:16   0:00 /usr/sbin/cron -f
rick      7273  0.0  0.0  14224  1028 pts/2    S+   17:50   0:00 grep --color=auto cron

Agora podemos ver a reinicialização original às 4:16 am ainda em execução no cron job. O ID do processo 1122 pode ser aquele que precisa ser eliminado ao retomar da suspensão em futuras alterações do programa. Isso ainda não vincula o nome do script display-auto-brightness , que pstree encontra.

Editar o atalho do ambiente de trabalho do Windows Subsystem for Linux

Ao configurar um ícone para chamar um script bash da área de trabalho do Windows 10, você obtém mais programas em execução do que sob o Ubuntu 16.04 e Unity:

$ ps -ef | grep lock-screen
rick     29243 29242  0 17:13 tty1     00:00:00 /bin/bash -c cd && DISPLAY=0:0 /mnt/e/bin/lock-screen-timer
rick     29244 29243  0 17:13 tty1     00:00:00 /bin/bash /mnt/e/bin/lock-screen-timer

Quando você usa pstree , há ainda mais PIDs:

$ pstree -gp | grep lock-screen
          |-init(29242,29242)---bash(29243,29242)---lock-screen-tim(29244,29242)---sleep(29777,29242)

No método "antigo" eu mataria lock-screen-timer "29244". Olhando para ps -aux eu acho que deveria matar "29243". Olhando para pstree , embora o processo init parent deva ser eliminado, o que é "29242".

Testes adicionais revelam que você não pode matar init PID

Esta captura de tela mostra como você não pode matar init PID diretamente. Você pode matar seu filho que faz com que ele morra, mas o neto e o bisneto continuam correndo. Parece que você precisa matar três PIDs no Windows 10 WSL quando um atalho na área de trabalho é usado:

rick@alien:/mnt/c/Windows/System32$ pstree -gp | grep lock-screen
          |-init(30554,30554)---bash(30555,30554)---lock-screen-tim(30556,30554)---sleep(30587,30554)
rick@alien:/mnt/c/Windows/System32$ kill 30554
-bash: kill: (30554) - Operation not permitted
rick@alien:/mnt/c/Windows/System32$ sudo kill 30554
[sudo] password for rick:
rick@alien:/mnt/c/Windows/System32$ pstree -gp | grep lock-screen
          |-init(30554,30554)---bash(30555,30554)---lock-screen-tim(30556,30554)---sleep(30587,30554)
rick@alien:/mnt/c/Windows/System32$ kill 30555
rick@alien:/mnt/c/Windows/System32$ pstree -gp | grep lock-screen
          |-lock-screen-tim(30556,30554)---sleep(30612,30554)
rick@alien:/mnt/c/Windows/System32$ pstree -gp | grep sleep
          |-lock-screen-tim(30556,30554)---sleep(30633,30554)
rick@alien:/mnt/c/Windows/System32$ kill 30556
rick@alien:/mnt/c/Windows/System32$ pstree -gp | grep sleep
          '-sleep(30633,30554)
rick@alien:/mnt/c/Windows/System32$ kill 30633
    
por WinEunuuchs2Unix 09.03.2017 / 01:25

3 respostas

0

Graças a este Q & amp; A ( como matar um cron job se ele não aparecer no ps? ou fazer com que ele apareça no ps? ) Eu estava no lado direito caminho:

───────────────────────────────────────────────────────────────────────────────
rick@dell:~$ ps wwuxa |grep display-auto | grep -v grep
root      1584  0.0  0.0   4508   780 ?        Ss   14:02   0:00 /bin/sh -c    /usr/local/bin/display-auto-brightness
root      1592  0.0  0.0  12564  2984 ?        S    14:02   0:00 /bin/bash /usr/local/bin/display-auto-brightness
───────────────────────────────────────────────────────────────────────────────
rick@dell:~$ pstree -p -g | grep display-auto
             |-cron(1376,1376)---cron(1436,1376)---sh(1584,1584)---display-auto-br(1592,1584)---sleep(16989,1584)
───────────────────────────────────────────────────────────────────────────────
rick@dell:~$ 

Matar o cron (com o 1376 e o 1436 do pid) é provavelmente uma má ideia. No entanto matando bash shell (1584) que é o pai para display-auto-brilho (1592) e avós para dormir (16989) deve matar a criança e neto. Então, duas cópias do processo filho (display-auto-brightness) não serão executadas ao mesmo tempo.

Agora vem o desafio de programar o script, mas pelo menos agora eu sei como extrair a informação.

    
por WinEunuuchs2Unix 12.03.2017 / 02:03
1

Efetivamente, sim, existe uma maneira de identificá-los como um único processo, mas com uma condição.

Suponha que tenhamos isso:

#!/bin/bash
loop_function(){
    while :
    do
       sleep 3
    done
}

loop_function &

while true
do
    sleep 3
done

E lançamos em segundo plano:

bash-4.3$ ./simple_example.sh &
[1] 16180

Aqui vemos que o próprio script tem 16180 PID. Todos os seus filhos teriam um diferente. Agora, todos eles têm um pai comum: o shell especificado em #! line, ou seja, exatamente o mesmo PID que foi relatado quando executamos o script em segundo plano. Assim, usando ps com a especificação de ppid , podemos procurar por todos os processos pertencentes ao mesmo processo.

bash-4.3$ ps -e  -o ppid,command | grep 16180 | grep -v grep
16180 /bin/bash ./simple_example.sh
16180 sleep 3

Agora, obviamente, isso implica duas coisas:

  • para agrupar os processos juntos, você deve conhecer o PID pai
  • Os processos filhos de
  • terão um PID pai diferente, portanto, se você tiver mais de um nível de chamadas de função, será difícil rastrear todos os processos.

Quanto a pstree da pergunta, o trabalho apareceu lá - foi simplesmente cortado por grep . Você também não precisa de sudo para visualizar cronjobs:

$ ps -ef | grep cron | grep -v grep && echo $USER                                                                        
root       896     1  0 09:47 ?        00:00:00 /usr/sbin/cron -f
xieerqi
    
por Sergiy Kolodyazhnyy 09.03.2017 / 01:38
1

Como você deseja localizar somente os PIDs do processo em execução, e não qualquer coisa indiretamente associada (isto é, o PID da chamada sudo e o grep pesquisando o nome do processo), você pode simplesmente desabilitar o ofensor palavras da pesquisa inicial.

$ ps aux | grep display-auto-brightness | grep -vw -e grep -e sudo | awk '{print }'
    
por neuro 12.03.2017 / 05:13