Por que ainda recebo stdout ou stderr após rejeitar um processo?

Question

Eu iniciei o QEMU e deserdou-o imediatamente, mas ainda recebi a saída no meu shell:

aburk@aburk:~$ su
Password: 
[root@aburk aburk]# QEMU_AUDIO_DRV="pa" QEMU_PA_SERVER="/run/user/1000/pulse/native" qemu-system-x86_64 -m 3096M -hda /dev/sdb -cpu host -smp cores=3,threads=1,sockets=1 --enable-kvm
WARNING: Image format was not specified for '/dev/sdb' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
^Z
[1]+  Stopped                 QEMU_AUDIO_DRV="pa" QEMU_PA_SERVER="/run/user/1000/pulse/native" qemu-system-x86_64 -m 3096M -hda /dev/sdb -cpu host -smp cores=3,threads=1,sockets=1 --enable-kvm
[root@aburk aburk]# bg
[1]+ QEMU_AUDIO_DRV="pa" QEMU_PA_SERVER="/run/user/1000/pulse/native" qemu-system-x86_64 -m 3096M -hda /dev/sdb -cpu host -smp cores=3,threads=1,sockets=1 --enable-kvm &
[root@aburk aburk]# 
(qemu-system-x86_64:19530): Gtk-WARNING **: Allocating size to GtkScrollbar 0x7f261f20c2c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(qemu-system-x86_64:19530): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -150829368 and height 400

(qemu-system-x86_64:19530): Gtk-WARNING **: Allocating size to GtkScrollbar 0x7f261f20c4c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(qemu-system-x86_64:19530): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -150829368 and height 400

(qemu-system-x86_64:19530): Gtk-WARNING **: Allocating size to GtkScrollbar 0x7f261f20c6c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(qemu-system-x86_64:19530): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -150829368 and height 400
jobs -p
19530
[root@aburk aburk]# disown 19530
[root@aburk aburk]# 
[root@aburk aburk]# 
[root@aburk aburk]# 
(qemu-system-x86_64:19530): Gtk-WARNING **: Allocating size to GtkScrollbar 0x7f261f20c2c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(qemu-system-x86_64:19530): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -150829368 and height 900

(qemu-system-x86_64:19530): Gtk-WARNING **: Allocating size to GtkScrollbar 0x7f261f20c4c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(qemu-system-x86_64:19530): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -150829368 and height 900

(qemu-system-x86_64:19530): Gtk-WARNING **: Allocating size to GtkScrollbar 0x7f261f20c6c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(qemu-system-x86_64:19530): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -150829368 and height 900

Eu posso acionar manualmente os avisos do GTK redimensionando o QEMU a partir do menu Exibir.

Eu não ignorei o processo corretamente? Por que ainda estou recebendo saída?

Eu noto que quando eu fecho meu shell completamente e abro um novo e su para root, eu não recebo nenhuma dessas mensagens, não importa quantas vezes eu redimensione o QEMU.

Eu gostaria de saber como isso funciona.

    

Answer 1

disown apenas remove um trabalho da tabela de tarefas ativas (mantido pelo shell), garantindo que o processo correspondente não seja eliminado quando o shell for encerrado. Ele não altera a configuração de E / S fornecida ao processo (entrada, saída e erro padrão); então a saída do trabalho rejeitado ainda vai para o terminal em que foi iniciado ou para onde foi redirecionado. Se você fechar o terminal (supondo que a saída esteja indo para lá), a saída será perdida e a abertura de um novo shell não recuperará a saída. Nesse caso, assim que o processo tentar ler ou gravar no terminal, ele receberá um sinal de desligamento; veja Diferença entre nohup, disown e & para detalhes.

Para evitar totalmente o problema, você pode redirecionar a saída do processo para /dev/null ao iniciá-lo.