I've been noticing that, under my current VM, especially for a few minutes after booting, if I try to run my firefox sandbox, I sometimes get this:
No protocol specified
Error: cannot open display: unix:100
After some time, that stops happening until next boot. I was able to track it down to the fact that, upon launching the Xpra client, the Xpra server might still not be ready. For some reason (heavy load?) this happens mostly during the first ~10 minutes during boot.
By waiting 5 seconds before the waitForServerContainerToLaunch() method returns, this is no longer reproducible in my current setup:
def waitForServerContainerToLaunch(self):
while True:
if os.path.exists(os.path.join(self.getServerSideX11Path(),"X100")) and os.path.exists(self.getXpraSocket()):
time.sleep(5)
return
time.sleep(0.05)
I also tried to reduce it to 3 seconds, but then it still happened more or less once per boot, if I try to run a sandbox right after booting and logging in. Of course, waiting 5 seconds on every launch isn't exactly efficient, so this isn't a real fix.
With Xpra debugging active, I've noticed that the following line should appear on the console before launching the client, or it will very likely fail with the above error.
xpra is ready.
A solution might be to listen to the Xpra server's stdout until it outputs that line, and only then launch the client, instead of basing this decision off the existence of the pipes. I might find some time to look into it a bit more myself, but Python isn't my best language, and I'm not really familiar with the code base or with docker. From a cursory glance there doesn't seem to be an easy way in the current code base to "listen" to a runtime, though, so my suggested fix might not be at all simple.
I've been noticing that, under my current VM, especially for a few minutes after booting, if I try to run my firefox sandbox, I sometimes get this:
After some time, that stops happening until next boot. I was able to track it down to the fact that, upon launching the Xpra client, the Xpra server might still not be ready. For some reason (heavy load?) this happens mostly during the first ~10 minutes during boot.
By waiting 5 seconds before the waitForServerContainerToLaunch() method returns, this is no longer reproducible in my current setup:
I also tried to reduce it to 3 seconds, but then it still happened more or less once per boot, if I try to run a sandbox right after booting and logging in. Of course, waiting 5 seconds on every launch isn't exactly efficient, so this isn't a real fix.
With Xpra debugging active, I've noticed that the following line should appear on the console before launching the client, or it will very likely fail with the above error.
A solution might be to listen to the Xpra server's stdout until it outputs that line, and only then launch the client, instead of basing this decision off the existence of the pipes. I might find some time to look into it a bit more myself, but Python isn't my best language, and I'm not really familiar with the code base or with docker. From a cursory glance there doesn't seem to be an easy way in the current code base to "listen" to a runtime, though, so my suggested fix might not be at all simple.