Hi folks.
I’m running into an issue when forking images with OSProcess in headless images. In older versions of OSProcess #forkSqueak would try to fork in any case, independent of the presence of or the connection state to XDisplayControlPlugin. In dtl.57 #forkSqueak was changed to explicitly check if XDisplayControlPlugin is present and can be controlled. This is obviously a good thing for when the image runs headful. In my case however I can no longer fork my headless image, even though I don’t need an X session.
Important: apparently #safeToForkSqueak answers true if the XDisplayControlPlugin is available, even in a headless image. But since we don’t need windows, we don’t install X libraries on our server and so #safeToForkSqueak answers false. So the whole thing boils down to a situation where Squeak / Pharo is run in an environment where the XDisplayPlugin can’t be loaded but where forking is still possible.
I don’t know how to do this in a cross platform way but for Pharo we could extend #safeToForkSqueak with a headless check like this:
safeToForkSqueak "The forkSqueak method is currently supported only for X11 displays with XDisplayControlPlugin available. If the plugin is not available, the child Squeak VM will continue interacting with the X display, which leads to errors in the parent Squeak, including VM crashes."
^self canControlXDisplay or: [ Smalltalk isHeadless ]
I’m going to dirty patch this for my images because I really need it but I think some version of this patch would be a good thing to integrate into OSProcess.
Cheers, Max
On Wed, Aug 13, 2014 at 09:42:50AM +0200, Max Leske wrote:
Hi folks.
I?m running into an issue when forking images with OSProcess in headless images. In older versions of OSProcess #forkSqueak would try to fork in any case, independent of the presence of or the connection state to XDisplayControlPlugin. In dtl.57 #forkSqueak was changed to explicitly check if XDisplayControlPlugin is present and can be controlled. This is obviously a good thing for when the image runs headful. In my case however I can no longer fork my headless image, even though I don?t need an X session.
Important: apparently #safeToForkSqueak answers true if the XDisplayControlPlugin is available, even in a headless image. But since we don?t need windows, we don?t install X libraries on our server and so #safeToForkSqueak answers false. So the whole thing boils down to a situation where Squeak / Pharo is run in an environment where the XDisplayPlugin can?t be loaded but where forking is still possible.
I don?t know how to do this in a cross platform way but for Pharo we could extend #safeToForkSqueak with a headless check like this:
safeToForkSqueak "The forkSqueak method is currently supported only for X11 displays with XDisplayControlPlugin available. If the plugin is not available, the child Squeak VM will continue interacting with the X display, which leads to errors in the parent Squeak, including VM crashes."
^self canControlXDisplay or: [ Smalltalk isHeadless ]
I?m going to dirty patch this for my images because I really need it but I think some version of this patch would be a good thing to integrate into OSProcess.
Hi Max,
Thanks for this fix. I'll add it to the OSP repository as soon as I have a chance (but maybe not until Sunday).
As a side note, I have also found that an active RFB (VNC) connection presents a similar issue. If I have a headless image (such as a SqueakSource server), and if I have a VNC session connected to that image, then a forkSqueak does bad things because it results in two instances of the VM/image connected to the same socket. This is the same kind of issue as with the X11 server socket connection, so I should probably find a way to handle this in the safeToForkSqueak checks.
Dave
On Wed, Aug 13, 2014 at 09:42:50AM +0200, Max Leske wrote:
Hi folks.
I?m running into an issue when forking images with OSProcess in headless images. In older versions of OSProcess #forkSqueak would try to fork in any case, independent of the presence of or the connection state to XDisplayControlPlugin. In dtl.57 #forkSqueak was changed to explicitly check if XDisplayControlPlugin is present and can be controlled. This is obviously a good thing for when the image runs headful. In my case however I can no longer fork my headless image, even though I don?t need an X session.
Important: apparently #safeToForkSqueak answers true if the XDisplayControlPlugin is available, even in a headless image. But since we don?t need windows, we don?t install X libraries on our server and so #safeToForkSqueak answers false. So the whole thing boils down to a situation where Squeak / Pharo is run in an environment where the XDisplayPlugin can?t be loaded but where forking is still possible.
I don?t know how to do this in a cross platform way but for Pharo we could extend #safeToForkSqueak with a headless check like this:
safeToForkSqueak "The forkSqueak method is currently supported only for X11 displays with XDisplayControlPlugin available. If the plugin is not available, the child Squeak VM will continue interacting with the X display, which leads to errors in the parent Squeak, including VM crashes."
^self canControlXDisplay or: [ Smalltalk isHeadless ]
I?m going to dirty patch this for my images because I really need it but I think some version of this patch would be a good thing to integrate into OSProcess.
Thanks Max,
I added your patch to the OSP repository. I added a check so that it will work on classic Squeak 3.8 as well as the latest Squeak trunk and Pharo.
Dave
squeak-dev@lists.squeakfoundation.org