Hi Tim,

I don't have a definitive answer, but some tidbits not yet mentioned in
this thread.

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,

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.


> >
> > 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.


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:

     svc -u /service/squeaksource/log

Beyond that, double check those permissions...

There is also the application-level log, "ss.log" in the image directory,
but this is just app-level stuff.


>   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 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...


>
> 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


This makes me wonder whether FileStream class>>stdout needs to be guarded
with a Mutex or something.


> 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 actually think its because daemontools is strict in order to be secure.
You may simply have a permissions issue.

>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?


>
>
> 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 logging is definitely working on source.squeak.org 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 ...


>
> The current 'run' script I have is -
>
> #!/bin/bash
> # cd /home/pi/SqSrcDeploy/ss
>

The ./ss subdirectory is supposed to be a soft-link to your main MC
directory, with one project subdirectory per project.

The directory you want to cd to is the directory ABOVE that.

But, I have my cd commented out too, and it still works (on Ubuntu), so
maybe not an issue then.


> # 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.
>

This is how its done for source.squeak.org.  Thanks for this ingenius setup
Levente!

 - Chris


>
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190911/a4cfd749/attachment.html>