no window borders, no controls after container stop - start

[samlnx03]

no window borders, no controls after container stop - start

[accetto]

Hello @samlnx03,

thank you for you feedback. Unfortunatelly, I'm not able to reproduce the issue.

Can you please closer describe your environment and the use case?

Are you on Windows or Linux? Are you on the cloud?

How do you start your container? Can you provide the statement?

How do you stop and start the container? Do you use docker start or docker restart? Does it help if you do it the other way?

Have you overriden the container user? Have you bound any external volumes?

Does it help, if you rename the folder /home/headless/.config/xfce4 to /home/headless/.config/xfce4_old and then restart the container?

Remark: You can rename it inside the running container, but you have to use sudo.

For the comparison, this is what I get if I create the container like this:

docker run -d -P --name testing --hostname testing accetto/ubuntu-vnc-xfce-g3

and this is after stopping and starting the conatiner again:

Regards,
accetto

[accetto]

I've just published Release 23.03 with TigerVNC 1.13.1 bugfix release.

Please let me know if it has solved your issue.

[accetto]

Hello @samlnx03,

while working on other issues, I was able to get sometimes similar behaviour you've described.

However, it happens only if I bind the complete directory /home/headless to an external folder on the host.

Have you also bound the complete /home/headless directory?

I've prepared two images that fix it on my environment.

Could you test them please and let me know, if they've helped?

1. accetto/headless-drawing-g3:debug-issue-37

2. accetto/headless-ubuntu-g3:debug-issue-36-v2

Regards,
accetto

[samlnx03]

Hello accetto

Yes, i use a local directory used as directory /home/headless/

That way I can check each student work out of the container

I'll test you image as soon as possible
Thanks a lot

[accetto]

Oh, now it's all clear. According my testing, binding the complete $HOME directory to an external folder on the host causes exactly this kind of problems. There is the discussion thread #39 about it.

The reason for the behaviour is, that the container needs to initialize the $HOME content on its first start and that doesn't work correctly, if the complete $HOME is bound.

You can quickly recognize that the container has not initialized correctly if you don't see the Version Sticker icon on your desktop. Please refer to the screenshots in the discussion #39.

You have generally two possibilities.

I would recommend, that you create a separate parent directory for the workspaces of your students. You can bind that folder without problems. It can be a subfolder of the $HOME directory.

You can also initialize the container first in some controlled environment. It can be the container itself, without any bindings, or using a named Docker volume for the $HOME directory. After that you can copy the initialized $HOME content to some external directory and later bind to it. This is the approach I've tried to describe in the discussion thread #39.

There is one more thing.

During my testing I've found, that if bind the whole $HOME directory, then the container was only seemingly correctly initialized. (By closer look there was no Version Sticker icon on the desktop.). However, after I've restarted the container, there was a black screen or only a partially initialized desktop.

I've found, that it happens because the image accetto/ubuntu-vnc-xfce-g3 doesn't include the package libgl1. However, I don't want to include it yet, because it increases the size of the image by almost 40% and I already have the image accetto/ubuntu-vnc-xfce-opengl-g3, which includes it.

So, if you decide to bind the whole $HOME diectory and you'll get the black screen or the problems you've described in the beginning, then you have to install that package or use the image accetto/ubuntu-vnc-xfce-opengl-g3.

[accetto]

I'm removing the bug label and closing the issue, because the behaviour has been caused by using bind mounts for the complete $HOME directory, which is not a supported use case. It can work under some conditions on some environments, but you have to be sure, that your are able to configure it correctly. The only working scenario across the environments is using Docker volumes. There is already the discussion thread #39 about this use case.