X11 lock file cleanup

[jimkring]

I ran into an issue where, while building a new container image that is based upon the NI container image, if VIPM or Lab view are running at the time a RUN statement in the docker file finishes/ends, then this will leave an X11 lock file that will prevent new instances of the xvfb display from starting up in a subsequent RUN statement or running a container based on that new image.

I haven’t looked into the inner workings of the scripts that start up the display when it is needed, but it may be a good idea to find a way to clean up these lock files if it’s possible to detect when the container is starting up cold.

One thought that I have is that the counter that is inside of that National Instruments cache file should probably be more sophisticated and keep a line inside that file for the process ID and it’s start time, rather than using a simple counter. That will make it easier to detect if all of those processes are still running and then clean up lock files before attempting to start another display. This is just a wild guess to hopefully get some ideas flowing.

I hope it’s helpful. Let me know if you have questions or need help reproducing. I’m away from my computer so I don’t have the exact error messages in front of me at the moment.

[shivaCode-2]

@jimkring - Could you please provide a small example that can help me reproduce this issue?
The cache file that you mentioned just stores the result of whether the current environment is a container or not. We are not intending to use this file from next release onwards.
Also, with our current implementation, if a existing Xvfb session is running, LabVIEW should be able to use that itself for its operations and would not try to start a new instance.
Once all the clients disconnect from the Xvfb server, it will clean itself automatically.

[jimkring]

@shivaCode-2 try this:

Create a new Dockerfile
Add a RUN /usr/local/natinst/<lv_version>/labview & sleep 5
Build the container.
Run the container and try to start labview

If my instructions/thinking are correct you will see the x11 lock file error.

The reason is that LabVIEW did not shut down. The container image was abruptly halted, and the x11 lock file was not cleaned up.

Again, I’m not in front of my computer right now, so if that doesn’t work, I can try to reproduce it on my end and give you a better example.

[shivaCode-2]

@jimkring - I was able to reproduce this issue on my dev system and did some investigation on the issue.
Your assessment: The reason is that LabVIEW did not shut down. The container image was abruptly halted, and the x11 lock file was not cleaned up. is correct. However even if we made sure that LabVIEW was closed, the lock file could have burned into the file system layer which can affect the subsequent commands.
It is not a recommendation to initialize an X Server during the build time of the image to avoid such issues. Does your use case require running LabVIEW during build time?

This is a limitation on containers rather than a LabVIEW specific issue

[jimkring]

@shivaCode-2 Thanks for that info. I have this need while installing and running vipm during container build (which uses the labview runtime engine and thus needs X Server). Seems like a reasonable thing to want to do, all things considered :)

The real limiation is that LabVIEW and apps built with it can't seem to exist without their UI, but I get your point about containers and file system layers.

I wonder if deleting the x11 lock file as part of the container build would do the trick. As long as it's recoverable and documented as a work-around, this could be acceptable.

Thanks!

[shivaCode-2]

@jimkring - In that case, a possible workaround with minimal risk would be to combine all commands that invoke or require LabVIEW into a single RUN instruction, or alternatively wrap those commands inside a single script that is executed in one RUN step.

This avoids Docker committing an intermediate filesystem layer while LabVIEW (and the associated X server) is still running, which is what ultimately causes the X11 lock file to be baked into the image.

If a subsequent RUN step truly requires LabVIEW again, then the only safe option would be to explicitly remove the stale X11 lock files before starting LabVIEW, and then follow the same “single RUN / single script” approach again. Let me know if this works for you.

We can evaluate internally whether this is something we should document as a workaround.

[shivaCode-2]

@jimkring - Did you get a chance to test this out?