Using squeak rfb/vnc server with unix server stuff

>
> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPN: Double Precision No-op

Ah. Nothing was mentioned about that before. Bad news - starting it doesn't seem to make any difference so far. I've tried starting it with and without a sudo, it doesn't make any complaints but checking the status return either 0 seconds or 1 second, which makes it seem it isn't feeling too happy. But there isn't any log for the log logger log...

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

That works fine, which I hope means permissions are ok 

One bit of weird is the way I ended up with
/service -> /etc/service
/etc/service contains
   service -> /etc/service
  ss -> /home/pi/SqSrcDeploy/ss
  supervise

It's hard to imagine requiring a link to yourself in a directory? I can't see any way it would get created in your deployment scripts. Deleting it doesn't appear to make any difference though.

On 13/09/19 2:04 AM, tim Rowledge wrote:
> WHOAMI=`whoami`
>
> echo creating rotated log/main directory...
> mkdir -p log/main
> chmod o-rwx log/main
>
> echo --- generate log/run script
> echo ''#!/bin/bash
> exec 2>&1
> exec setuidgid ''$WHOAMI'' multilog t ./main'' > $PWD/log/run
> sudo chown -R $WHOAMI log

WHOAMI is local to the script, so it won't be set in the run script

leading to multilog being treated as a uid argument.

You could change this to the more readable:

echo -- generate log/run script
cat >$PWD/log/run <<EOF
#!/bin/bash
exec 2>&1
exec setuidgid $WHOAMI multilog t ./main
EOF
sudo chown -R $WHOAMI log

HTH .. Subbu