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