Linux guests aborting w/ ssh -X (X11Forward) to host

[brians-vbox]

Hi,

This is a strange problem that doesn't involve being connected to the guest. I just have to start it headless (using VBoxManage) from the host to which I'm connected remotely using ssh w/ X11Forward. The guest will abort when I logout of the ssh connection to the host. Other vms started from other ssh sessions are not affected. Everything is shell based in this scenario, nothing graphical. Confirmed to not occur when I connect to the host without X11Forward.

At logout, ssh actually hangs until I interrupt with Ctrl-C which is the point the abort occurs. Using ssh -vvv, it reports a number of open x11 connections after logout which are then closed with Ctrl-C. Looking at running processes, I see 'sshd: <user>@pts/2' get replaced with 'sshd: <user>@notty' at logout. After Ctrl-C, the notty session is gone as well as the 'sshd: <user> [priv]' which was originally started when ssh was initiated.

Can anyone explain why a running guest, with no actual connections, is dependent on X11Forward to run? Aside from the obvious (not using X11Forward), anyone know of any workarounds? I'm running 5.2.44 on Ubuntu 18.04 (LinuxMint 18).

Regards,
Brian

[scottgus1]

start it headless (using VBoxManage) from the host to which I'm connected remotely using ssh w/ X11Forward. The guest will abort when I logout of the ssh connection to the host. Other vms started from other ssh sessions are not affected.

Virtualbox runs in the user space for the account that is logged in on. When you log off the account the guests must stop. Are you logging in on an account that is different from the other ssh-launched VMs?

[brians-vbox]

Thanks for reply.

Virtualbox runs in the user space for the account that is logged in on. When you log off the account the guests must stop. Are you logging in on an account that is different from the other ssh-launched VMs?

No, I'm using the same user account. Also, the exact scenario does NOT abort the guests if the only thing I change is use of X11Forward.

Regards,
Brian

[fth0]

Does it happen if you're the only user logged in, and only logged in via SSH?

Does it make a difference, if you use ssh -X or ssh -Y?

Can you provide the exact commands (and options) for SSH and VBoxManage, and the output of ps -elfH and xlsclients -l?

[brians-vbox]

Does it happen if you're the only user logged in, and only logged in via SSH?
Does it make a difference, if you use ssh -X or ssh -Y?
Can you provide the exact commands (and options) for SSH and VBoxManage, and the output of ps -elfH and xlsclients -l?

Thanks again for the reply.

Well, I rebooted the host to make sure I was indeed the only one logged in by ssh, and in the process discovered that without X11Forward, the guest would not start due to 3d acceleration:

VBoxManage startvm --type headless testCentos8vm
VBoxManage: error: This VM was configured to use 3D acceleration.
However, the 3D support of the host is not working properly and the VM cannot be started.
To fix this problem, either fix the host 3D support (update the host graphics driver?)
or disable 3D acceleration in the VM settings (VERR_NOT_AVAILABLE)

If I disable 3D (modifyvm --accelerate3d=off), I no longer have the problem. I can ssh with or without X11Forward, start the vm, logout and the vms will not abort. I still see the abort if I login with X11Forward, start the vm w/ 3d acceleration enabled, then logout. The symptoms in this case are the same as before: the ssh session hangs due to open X11 connections, then when I interrupt to close the ssh, it causes the vm to abort.

So, for me, I can get by without 3d acceleration and thus have a work around to the problem I'm seeing. However, this still smells like a bug in VirtualBox 5.2. Not sure how big of a deal that really is at this point since 6.x changes the video drivers. Think I should file a bug against 5.2? I may not get around to testing 6.x anytime soon...

Regards,
Brian

[fth0]

Think I should file a bug against 5.2?

I don't know. You've configured the VM (3D acceleration) to connect to the X server (on your client), then start the VM in headless mode, which cannot successfully connect to the X server. If you file a bug, I wouldn't hold my breath ...