Well, this is all very curious. Some good news at the end, but first some details of testing for the record because maybe, just maybe it will help somebody else one day.

> On 2019-09-10, at 5:41 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> 

> Try
> 
> lsof -p <PID_OF_THE_SQUEAK_VM_RUNNING_YOUR_IMAGE>


OK, after installing it I get 'interesting' results.

The image as run via daemontools (let's acall it the 'background image') results in no report from `lsof -p ` other than a warning about "can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs". Except just now on the n'th attempt (where n is probably around 10) at restarting the image I also actually got a listing of a dozen or so open files like libasound, the directory and a couple of pipes. 
`lsof -i:5900-5950` shows the single vnc connection to my iMac vnc client, so we kow it is working at that level, at least.

Using lsof -i  when the *same* image is run directly from the commandline, with the same input .st file etc shows the new 5901 port open, and after I connect it shows the ESTABLISHED status.

> 
> It should tell you whether the RFB server is really listening on the tcp port you defined or not.
> If not, there are some possibilities
> - missing sources file hangs the startup process, thus RFBServer hasn't been started

That's an interesting idea and I'd hope that we'd get an error log in that case but so the the daemontools 'run' script isn't giving me any output all despite claiming to redirect stdout/err to a log.  The directly run image happily copies all Transcript output to stdout and it appears in the terminal.

OK, this is a bit different; lsof is now showing me that the background image is listening on 5901 as hoped and after connecting from the viewer image it is apparently ESTABLISHED. But no actual display appears...

I added a couple of very deliberate write-to-known-file logging lines and both output ok, demonstrating that the background image has got past the VNC setup. I guess this is good. I added the RFB log info to my file and that seems ok too. But still no display.

I tried out `kill -10 PID` to get the status dump that Eliot added some time ago. In the background image it seemed t obe stuck in attemtping to write to a file and it seemed to be as a result of the Transcript redirecting to stdout that I had previously enabled in the hope of getting some useful information! So, turn off that preference in the image.. .and we get a display in the VNC viewer. Yay!

So; after all that annoyance it appears that some aspect of the daemontools related script used to start the image is causing attempts to write to stdout/err to block. I can't say I'm hugely surprised at this, pretty much everything I've ever had problems with seems to come down to some weird crap in unix (or Windows, etc). 

I guess the question has now become something like 
"does anyone understand daemontools related usage (or systemd etc) to be able to send stdout/err output to somewhere helpful?

The current 'run' script I have is -

#!/bin/bash
# cd /home/pi/SqSrcDeploy/ss
# redirect stderr to stdout so error messages will show up in log/main
exec 2>&1

# remove Magma _open indicator (same as a "lock" file),
# this subverts Magma's safety check, but if controlled by daemontools
# then we know it shouldn't be due to duplicate run
setuidgid pi rm -f /ss.magma/_open

# permission for root to run the HT version of the vm
ulimit -r 2
exec setuidgid pi ./vm/bin/squeak -vm display=none ss.image run.st `cat webPort`



> 
> Also, if you use RFBServer on any machine, make sure that you have a firewall blocking its port from the outside. You should only be able to
> connect to it through an ssh tunnel.

Yeah, the security thing will be important. The VNC server does at least have DES encrypted passwords available. since all this 'fun' is related to running a private squeaksource server I think we'll be wanting to run it behind a firewall, use a VPN or similar and probably change the user registration stuff to only be usable by some admin etc.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: DPN: Double Precision No-op