Почему я все еще получаю stdout или stderr после отказа от процесса?

Я начал QEMU и сразу отказался от него, но все равно получаю вывод на свою оболочку:

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 

Я могу вручную запустить предупреждения GTK, изменив размер QEMU в меню «Вид».

Разве я не отреагировал должным образом на процесс? Почему я все еще получаю выход?

Я замечаю, что когда я полностью закрываю свою оболочку и открываю новую, а su для root, я не получаю ни одного из этих сообщений независимо от того, как часто я изменяю размер QEMU.

Я хотел бы знать, как это работает.

disown удаляет задание из таблицы активных заданий (поддерживается оболочкой), гарантируя, что соответствующий процесс не будет уничтожен, когда оболочка завершится. Он не изменяет настройки ввода / вывода, заданные процессу (стандартный ввод, вывод и ошибка); поэтому выход отложенной работы по-прежнему поступает на терминал, где он был запущен, или туда, где он был перенаправлен. Если вы закроете терминал (при условии, что выход идет туда), тогда выход будет потерян, и открытие новой оболочки не восстановит результат. В этом случае, как только процесс попытается прочитать или записать на терминал, он получит сигнал зависания; см. Разницу между nohup, disout и & details.

Чтобы полностью исключить эту проблему, вы можете перенаправить вывод процесса в /dev/null при его запуске.