Redirecionar todas as saídas (stdout, stdin, stderr) pode desassociar um processo filho com o pai.
Você pode tentar anexar ao processo com gdb, digitar 'c' para continuar e assistir a esse console enquanto o hup de outro.
gdb / bin / dd pid
Eu iniciei um longo processo em segundo plano ( dd
with /dev/urandom
) no meu console ssh. Mais tarde eu tive que desconectar. Quando eu entrei, novamente (desta vez diretamente, sem ssh), o processo ainda parecia rodar.
Não sei ao certo o que aconteceu - não usei disown
. Quando eu entrei mais tarde, o processo não foi listado em top
no começo, mas depois de um tempo ele recuperou uma alta porcentagem de CPU, como eu esperava. Então, suponho que dd
ainda esteja em execução.
Agora, gostaria de ver o progresso. Eu uso kill -USR1 <pid>
mas nada é impresso. Existe alguma maneira de obter a saída novamente?
Redirecionar todas as saídas (stdout, stdin, stderr) pode desassociar um processo filho com o pai.
Você pode tentar anexar ao processo com gdb, digitar 'c' para continuar e assistir a esse console enquanto o hup de outro.
gdb / bin / dd pid
Graças à resposta do kmarsh e this threads Eu consegui redirecionar minha saída perdida (stderr) para um arquivo:
gdb /bin/dd 2616
(gdb) p creat("/root/dd.stderr",0600)
[Switching to Thread 0x7f651ece56e0 (LWP 2616)]
$1 = 3
(gdb) p dup2(3,2)
$2 = 2
(gdb) p close(3)
$3 = 0
(gdb) q
Depois de executar kill -USR1 2616
, posso pesquisar meu novo arquivo:
631820341060 bytes (632 GB) copied, 81603.1 s, 7.7 MB/s
eu não tenho medo. mas da próxima vez - use a tela . procure no Google tutoriais ou inicie aqui .
Você pode ver a saída procurando em /proc/(pid of your dd/fd/1
ou /proc/(pid)/fd/2
. Cat que, em seguida, bateu com um USR1 e veja se você consegue alguma coisa.