0

I started QEMU and immediately disowned it, but still receive output onto my 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

I can manually trigger the GTK warnings by resizing QEMU from within the View menu.

Did I not properly disown the process? Why am I still receiving output?

I notice that when I close my shell entirely and open a new one and su to root, I do not get any of those messages no matter how often I resize QEMU.

I would like to know how this works.

6

disown only removes a job from the table of active jobs (maintained by the shell), ensuring that the corresponding process isn’t killed when the shell terminates. It doesn’t change the I/O setup given to the process (standard input, output and error); so the disowned job’s output still goes to the terminal where it was started, or to wherever it was redirected. If you close the terminal (assuming output is going there), then the output is lost, and opening a new shell won’t recover the output. In this case, as soon as the process tries to read from or write to the terminal, it will receive a hang-up signal; see Difference between nohup, disown and & for details.

To avoid the issue entirely, you can redirect the process’s output to /dev/null when you start it.

  • Except disown does not stop sighup. – ctrl-alt-delor Jul 18 '17 at 15:56
  • It does inasmuch as disown stops the job control shell from sending the hangup signal in the first place. (It can be sent by other things in certain circumstances, of course, per unix.stackexchange.com/questions/379118 .) – JdeBP Jul 18 '17 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.