Tl;dr - The good news is that the RFB/VNC connection pretty much works now, but the logging doesn't.

> On 2019-09-11, at 5:05 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> 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,

There doesn't appear to be a permissions issue for the general running stuff. The only 'locked up' dir is the log/supervise branch.

> 
> 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 actually does a good job of working out what the display number is from the rfbPort number, which is nice.

One of the initial things blocking me from connecting was the lost password you currently have set (reminder: needs changing!) combined with the problem in the RFBServer >hasPassword method that means any set password overrides the AllowEmptyPasswords setting.  I suspect that it was whilst finding this and changing it that I might have enabled the 'redirect transcript to stdout' and caused so many later problems  :-( We can probably improve the passwords situation in the run.st script you use for personal squeaksource at some point.


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

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


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

Interesting; that's not happening to me in this case. I think I have pretty solid evidence that my problem with no display was a side effect of the transcript redirection setting. With that disabled I get a connection immediately, which is a big relief.

> 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

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

Right now it just doesn't do anything. Tried taking both the log and ss down and the restarting, no change. Still getting the repeated 0 seconds uptime for the logging service; surely an error signifier?

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

Yup, that's just as your deploy process made it. I haven't been brave enough to change that yet.

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.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: SDS: Sort of Do Something