<div dir="ltr"><div>Hi Tim,</div><div><br></div><div>I don't have a definitive answer, but some tidbits not yet mentioned in this thread.</div><div><br></div><div>daemontools runs programs in a *minimal environment*.  It uses setuidgid to set the user, so it needs to have permissions on the directory and ./log subdirectories,</div><div><br></div><div>and... I seem to remember something about the "environment" that daemontools runs in, that even though as your user "pi", it does not include a :1 display -- or something like that.  That may be why you're experiencing the difference between connecting to RFB when its running in the daemontools environment -- but I could be wrong about that -- since its Squeak's RFB, it seems like it should just be an open port with data...   Very strange.  Levente is the expert on this.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> <br>
> It should tell you whether the RFB server is really listening on the tcp port you defined or not.<br>
> If not, there are some possibilities<br>
> - missing sources file hangs the startup process, thus RFBServer hasn't been started<br>
<br>
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.</blockquote><div><br></div><div>daemontools runs the log as a separate service, I can't remember if you have to start it separately, if so, the command would be the same as your service, just add /log to the end:</div><div><br></div><div>     svc -u /service/squeaksource/log</div><div><br></div><div>Beyond that, double check those permissions...</div><div><br></div><div>There is also the application-level log, "ss.log" in the image directory, but this is just app-level stuff.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  The directly run image happily copies all Transcript output to stdout and it appears in the terminal.<br>
<br>
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...<br></blockquote><div><br></div><div>I found that Squeak's RFB seems to have a bug where, when it starts, it's blank, but if you RESIZE the window, it'll "refresh" and display the desktop...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br>
<br>
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</blockquote><div><br></div><div>This makes me wonder whether FileStream class>>stdout needs to be guarded with a Mutex or something.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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!<br>
<br>
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).</blockquote><div><br></div><div>I actually think its because daemontools is strict in order to be secure.  You may simply have a permissions issue.</div><div><br></div><div>From your image directory, you could try a sudo setuidgid pi echo test > './log/main/test.out'  and see if you get any revealing error messages?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
<br>
I guess the question has now become something like <br>
"does anyone understand daemontools related usage (or systemd etc) to be able to send stdout/err output to somewhere helpful?<br></blockquote><div><br></div><div>The logging is definitely working on <a href="http://source.squeak.org" target="_blank">source.squeak.org</a> and my laptops.  Assuming all your directories are owned by "pi" all the way down, I don't see any problems with your setup...   just maybe try that sudo svc -u /service/ss/log ...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The current 'run' script I have is -<br>
<br>
#!/bin/bash<br>
# cd /home/pi/SqSrcDeploy/ss<br></blockquote><div><br></div><div>The ./ss subdirectory is supposed to be a soft-link to your main MC directory, with one project subdirectory per project.</div><div><br></div><div>The directory you want to cd to is the directory ABOVE that.</div><div><br></div><div>But, I have my cd commented out too, and it still works (on Ubuntu), so maybe not an issue then.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
# redirect stderr to stdout so error messages will show up in log/main<br>
exec 2>&1<br>
<br>
# remove Magma _open indicator (same as a "lock" file),<br>
# this subverts Magma's safety check, but if controlled by daemontools<br>
# then we know it shouldn't be due to duplicate run<br>
setuidgid pi rm -f /ss.magma/_open<br>
<br>
# permission for root to run the HT version of the vm<br>
ulimit -r 2<br>
exec setuidgid pi ./vm/bin/squeak -vm display=none ss.image <a href="http://run.st" rel="noreferrer" target="_blank">run.st</a> `cat webPort`<br>
<br>
<br>
<br>
> <br>
> 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<br>
> connect to it through an ssh tunnel.<br></blockquote><div><br></div><div>This is how its done for <a href="http://source.squeak.org" target="_blank">source.squeak.org</a>.  Thanks for this ingenius setup Levente!</div><div><br></div><div> - Chris</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br>
<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
Strange OpCodes: DPN: Double Precision No-op<br>
<br>
<br>
<br>
</blockquote></div></div>