[squeak-dev] [OSProcess] #safeToForkSqueak when running headless

David T. Lewis lewis at mail.msen.com
Wed Aug 13 11:45:08 UTC 2014

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.


More information about the Squeak-dev mailing list