Like know your setup. Could tell more ?

On 10/09/2019, 19:05, "Nicola Mingotti" nmingotti@gmail.com wrote:

I have one Squeak running in a server and I access it through VNC. But, I am using Unix VNC client/server programs, not Squeak native.   If you get it all working in Squeak please let me know.

bye Nicola

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

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@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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDS: Sort of Do Something

On 2019-09-11, at 6:59 PM, Chris Muller ma.chris.m@gmail.com wrote:

Heh, that's funny. :) Recall, daemontools simply runs the "run" script in the service directory, so what happens if you try running it in the foreground tty?

sudo ./log/run

Hmm, well it complains about the non-existence of user 'multilog', which tallies with a suggestion I found online to run `ps -aux | grep readproctitle` which resulted in the barely readable -

root 386 0.0 0.0 1668 304 ? S Sep11 1:13 readproctitle service errors: ...start service/run: file does not exist supervise: fatal: unable to start supervise/run: file does not exist supervise: fatal: unable to start service/run: file does not exist setuidgid: fatal: unknown account multilog supervise: fatal: unable to start supervise/run: file does not exist setuidgid: fatal: unknown account multilog supervise: fatal: unable to start service/run: file does not exist

The first weird bit in this is that since multilog is a program and not a user account we have to suspect some aspect of the script ie "exec setuidgid $WHOAMI multilog t ./main" from ./log/run

The weird bit *here* is that your configsvc script is clearly expecting to create the log/run script with the $WHOAMI already substituted (in my case with 'pi'). The next line in configsvc correctly uses the $WHOAMI value to set the file ownership.

It looks like the export of the configsvc script is not doing what is expected and missing quotes around the $WHOAMI. Indeed if I manually surround the $WHOAMI with single quotes it now magically creates a correct log/run file. As best I can tell, fixing SSRepository>configsvc solves this particular issue. See a) below.

OK, part b) Why is there not yet a visible log in log/main even after making the multilog stuff run without whining? From man multilog it seems that mulitilog t ./main is supposed to handle auto-rotated log files named 'current' in the directory .log/main and stick a timestamp in front of each entry. Ah; good old file caching nonsense. Simply using FileStream stdout nextPutAll: 'hello2'; cr is not good enough. FileStream stdout nextPutAll: 'hello2'; cr; flush actually flushes something to the log file. Hooray.

We still have a problem with `ps -aux | grep readproctitle` claiming - supervise/run: file does not exist It's not the most helpful error message I've ever seen since it doesn't give a full path but if we assume it refers to the 'supervise' directory within the squeaksource working directory then yeah, there is no run file. Is there supposed to be? I'm not getting a clear picture from whacking google around.

Time for a break. My brains are melting.

tim ---------------------- a) fix for SSRepository>configsvc "One time setup creates daemontools service and starts it." ^ '#!/bin/bash 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 sudo chmod 750 log/run

echo --- create Repository if not already existing... ./vm/bin/squeak -vm display=none ss.image configsvc.st $1 $WHOAMI > configsvc.out 2>&1

echo installing daemon, it will start... sudo ln -s $PWD /etc/service/`basename $PWD` sleep 7 sudo svstat /service/`basename $PWD`' -> [ Smalltalk runAndQuit: [ : whoami | SSRepository ensureRepositoryIfNoneCreateNewNamed: 'Personal SqueakSource' administeredBy: whoami ] {it's just the doubled-up single quotes around $WHOAMI}

-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- HASTE CUISINE - Fast French food

On Sun, Sep 15, 2019 at 5:17 AM K K Subbu kksubbu.ml@gmail.com wrote:

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

Correct. It's for the installation script only.

leading to multilog being treated as a uid argument.

My undestanding is that Tim's fix, to put double-quotations around it, will cause "$WHOAMI" to resolve during the run of this installation script, hardcoding the current user as the 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

Thanks!

- Chris

HTH .. Subbu