[Glass] Seaside - Installation - (1) problem with gemServer.ston script; (2) attaching via localhost
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Fri May 19 06:57:37 PDT 2017
Reg,
Did you notice that in my email I identified the .topazini in your $HOME
directory as the culprit?
Your (probably old) .topazini has a `gemnetid` entry that causes toaz to
be opened in rpc mode using the default netldi `gs64ldi` ... the topaz
sessions for the gemserver are intended to be run as linked logins, so
no attempt was made for setting up a netldi.
Remove the .topazini in your $HOME directory and things should run as
expected ...
Dale
On 5/19/17 6:50 AM, Reg Krock wrote:
>
>> On 18 May2017, at 11:42 PM, Dale Henrichs
>> <dale.henrichs at gemtalksystems.com
>> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>> On 5/18/17 5:14 PM, Reg Krock wrote:
>>> This continues to be frustrating. Do you know if there is anything
>>> special that needs to be done on OS/X?
>> Up until now, I didn't know you were on a mac. When Sierra was first
>> released there were issues with running a stone[1]. Those issues were
>> resolved with the release of 10.2.2[2]. Since then Johan reported
>> some issues with getting the hostname set up correctly for Sierra[3].
>> James had some issues with running GemStone on Sierra, but I don't
>> have an email trail for his issue -- I'll ask him to see if he
>> remembers what the problem was and what he did to fix or work around
>> it ... Other than James, it seems that there are a number of people
>> using GsDevKit_home and Seaside without hitting the type of problem
>> you are reporting, but then you are using a relatively recent version
>> of Sierra and I don't know (yet) if your issue is related to the new
>> version or something else.
>>
>
> I had added my computer name to the host file back in 2014 [1]. The
> server starts fine and I can connect with the tode1 client.
>
> It is just the seaside connection that appears to be a problem. I have
> even turned my mac’s own firewall off to ensure that was not the
> source of the problem.
>
> port: 1750
> seaside server class: aZnSeasideNewGemServer
> browser:localhost:1750
>
> [1] etc/hosts file contents. I think that I added rk.home for the
> installation of 3.1.x in 2014.
> rk:etc regkrock$ cat hosts
> ##
> # Host Database
> #
> # localhost is used to configure the loopback interface
> # when the system is booting. Do not change this entry.
> ##
> 127.0.0.1localhost
> 255.255.255.255broadcasthost
> 127.0.0.1rk.home
> ::1 localhost
> fe80::1%lo0localhost
>
>> I'm running on OS/X 10.10.5 ... at home ... up until now and I've
>> been testing against linux .. at work. When Sierra first came out it
>> didn't support the VPN client that I use and then there were the
>> basic problems with GemStone and then there were the issues with
>> running stones at all, so I've been a bit gun shy about updating ...
>>
>> [1] http://forum.world.st/GS3-3-0-and-macOS-Sierra-100-CPU-td4918469.html
>> [2] http://forum.world.st/MacOS-Sierra-support-td4928733.html
>> [3]
>> http://forum.world.st/SmalltalkCI-gemstone-on-mac-os-sierra-td4939640.html#a4939669
>>
>>> I am running both code client and gemstone server on my MacBook
>>> (OS/X 10.12.4) and I have answered ‘Allow’ to ‘’stoned’’ and
>>> “netldi” accepting incoming network connections.
>>>
>>> What I did today was to rename my GsDevKit_home to GsDevKit_home_old
>>> and then I have three reinstalled 3.3.5 from scratching using port
>>> 1750. All to no avail.
>> Okay ... I'm building a Seaside stone on my own laptop so that I've
>> got something to compare with ....
>>> However I did not have any problems with gemServer.ston script. That
>>> problem went away.
>> Okay ... I'll guess that I've got an issue with on the dev branch of
>> tODE ...
>>>
>>> The two files below are: (1) the installation steps including
>>> ‘project load’ prints and inspector prints of the seaside server and
>>> WADisplatcher; (2) the transcript.
>> I notice in the installation steps that you explicitly installed
>> GsApplicationTools (step 13) --- it shouldn't make a difference
>> because Seaside itself should install GsApplicationTools --- I'm just
>> curious why you felt it necessary to do that step, since it isn't
>> listed in the Seaside steps that I've recommended that you use[1] ...
>>
>> [1]
>> https://github.com/GsDevKit/GsDevKit_home/blob/master/docs/gettingStartedWithSeaside.md
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> All attempts to connect from the Web Browser to the seaside gem failed.
>>>
>>> I then took a Pharo 5.0 image, loaded in seaside and started
>>> seaside. I was able to connect.
>> Did you use port 1750 for the seaside port in Pharo5.0?
>
> Yes.
>
>>>
>>> I have also attached copies of all of the logs in case they are useful.
>>>
>>>
>> I'm suspicious that the seaside gems aren't properly starting ... and
>> concerned that the you didn't get any error feedback (if indeed the
>> gems didn't start properly)... My first clue is in your transcript.
>> At the very end your transcript looks like the following
>>
>> transcript '---Finished backup to 18/05/2017 16:22:35 -- seas... 95534 05/18/2017 16:22:36:469
>> transcript 'scriptLogEvent: ''performOnServer: seaside :: $GS... 95534 05/18/2017 16:23:20:291
>> transcript 'scriptLogEvent: ''performOnServer: SeasideMainten... 95534 05/18/2017 16:23:20:371
>> and when I ran the /home/seaside/gemServer script I got the following
>> entries:
>>
>> transcript '---Finished backup to 17/05/2017 15:55:19 -- seas...
>> 30803 05/17/2017 15:55:21:314
>> transcript 'scriptLogEvent: ''performOnServer: seaside :: $GS...
>> 30803 05/17/2017 15:55:47:562
>> transcript 'scriptLogEvent: ''performOnServer: SeasideMainten...
>> 30803 05/17/2017 15:55:47:655
>> transcript 'scriptLogEvent: ''-->>Script Start seaside on 175...
>> 32375 05/17/2017 15:55:47:686
>> transcript 'scriptLogEvent: ''recordGemPid: seaside on 1750''...
>> 32375 05/17/2017 15:55:47:686
>> transcript 'scriptLogEvent: ''setStatmonCacheName: seaside'''
>> 32375 05/17/2017 15:55:47:688
>> transcript 'scriptLogEvent: ''enableRemoteBreakpointHandling:...
>> 32375 05/17/2017 15:55:47:689
>> transcript 'scriptLogEvent: ''-->>Script Start SeasideMainten...
>> 32385 05/17/2017 15:55:47:696
>> transcript 'scriptLogEvent: ''recordGemPid: SeasideMaintenanc...
>> 32385 05/17/2017 15:55:47:700
>> transcript 'scriptLogEvent: ''setStatmonCacheName: SeasideMai...
>> 32385 05/17/2017 15:55:47:704
>> transcript 'scriptLogEvent: ''enableRemoteBreakpointHandling:...
>> 32385 05/17/2017 15:55:47:704
>>
>> This implies that there is something fishy going on ... and sure
>> enough, when I look at your seaside_server-1750.log file, the login
>> is failing:
>>
>> GemStone: Error Fatal
>> Unable to create a session, check netldi and gem log files.
>> NetLDI service 'gs64ldi' not found on node 'localhost6' port 50377 :
>> connect(11,::ffff:127.0.0.1,port=50377) failed with errno=22,EINVAL,
>> Invalid argument (programmer error)
>> Error Category: 231169 [GemStone] Number: 4042 Arg Count: 0 Context
>> : 20 exception : 20
>>
>> Login failed due to errors.
>> topaz > exec iferr 1 : stack
>> STACK can't be used prior to logging in.
>> topaz> iferror stack
>> topaz>
>> topaz> login
>> -----------------------------------------------------
>>
>> The maintenance vm is having a similar problem:
>>
>> topaz> login
>> -----------------------------------------------------
>> GemStone: Error Fatal
>> Unable to create a session, check netldi and gem log files.
>> NetLDI service 'gs64ldi' not found on node 'localhost6' port 50377 :
>> connect(11,::ffff:127.0.0.1,port=50377) failed with errno=22,EINVAL,
>> Invalid argument (programmer error)
>> Error Category: 231169 [GemStone] Number: 4042 Arg Count: 0 Context
>> : 20 exception : 20
>>
>> Sooo for some reason the gemserver script is not failing when the gem
>> fails to start, so that looks like a bug in the gem server starting
>> code and/or tode script ...
>>
>> I've compared the post-Seaside load `project list` and other than the
>> fact that your listing of the short SHA does not exactly match the
>> short SHA that I see in my list, we have loaded and are using exactly
>> the same code .... so thank you for rebuilding the system and
>> providing me with the additional details, so I can confirm that we're
>> on the same page and eliminate those variables ...
>>
>> Well my build just finished and of course the servers start just fine
>> for me ...
>>
>> You are obviously able to connect to the netldi, since you are using
>> tODE ...
>>
>> Looking closer at the seaside_server-1750.log note that topaz is
>> processing the $HOME/.topazini file which also appears to be doing a
>> login ...
>> ================
>> Reading initialization file /Users/regkrock/.topazini
>> topaz> set gemstone gs64stone
>> topaz> set gemnetid gemnetobject
>> topaz> set username DataCurator
>> topaz> set password swordfish
>> topaz> lo
>> [Info]: libssl-3.3.5-64.dylib: loaded
>> -----------------------------------------------------
>> GemStone: Error Fatal
>> Unable to create a session, check netldi and gem log files.
>> NetLDI service 'gs64ldi' not found on node 'localhost6' port 50377 :
>> connect(14,::ffff:127.0.0.1,port=50377) failed with errno=22,EINVAL,
>> Invalid argument (programmer error)
>> Error Category: [GemStone] Number: 4042 Arg Count: 0
>>
>> Login failed due to errors.
>> End of initialization files
>> topaz>
>> topaz> set user DataCurator pass swordfish gems devKit_33
>> Warning: clearing the previous GemStone password.
>> topaz>
>> topaz> display oops
>> topaz> iferror stack
>> topaz>
>> topaz> login
>> -----------------------------------------------------
>> GemStone: Error Fatal
>> Unable to create a session, check netldi and gem log files.
>> NetLDI service 'gs64ldi' not found on node 'localhost6' port 50377 :
>> connect(11,::ffff:127.0.0.1,port=50377) failed with errno=22,EINVAL,
>> Invalid argument (programmer error)
>> Error Category: 231169 [GemStone] Number: 4042 Arg Count: 0 Context
>> : 20 exception : 20
>> ==========================
>>
>> Now, I've created a similar .topazini file in my $HOME and I get the
>> same login failure:
>>
>> ==========================
>> Reading initialization file /Users/dhenrich/.topazini
>> topaz> SET GEMSTONE gss_344
>> topaz> set gemnetid gemnetobject
>> topaz> set user DataCurator
>> topaz> set password swordfish
>> topaz> login
>> [Info]: libssl-3.3.5-64.dylib: loaded
>> -----------------------------------------------------
>> GemStone: Error Fatal
>> Unable to create a session, check netldi and gem log files.
>> NetLDI service 'gs64ldi' not found on node 'localhost6' port 50377 :
>> connect(14,::ffff:127.0.0.1,port=50377) failed with errno=22,EINVAL,
>> Invalid argument (programmer error)
>> Error Category: [GemStone] Number: 4042 Arg Count: 0
>>
>> Login failed due to errors.
>> topaz>
>> End of initialization files
>> topaz>
>> topaz> set user DataCurator pass swordfish gems reg_335
>> Warning: clearing the previous GemStone password.
>> topaz>
>> topaz> display oops
>> topaz> iferror stack
>> topaz>
>> topaz> login
>> -----------------------------------------------------
>> GemStone: Error Fatal
>> Unable to create a session, check netldi and gem log files.
>> NetLDI service 'gs64ldi' not found on node 'localhost6' port 50377 :
>> connect(11,::ffff:127.0.0.1,port=50377) failed with errno=22,EINVAL,
>> Invalid argument (programmer error)
>> Error Category: 231169 [GemStone] Number: 4042 Arg Count: 0 Context
>> : 20 exception : 20
>> ==========================
>>
>> Sooooo, it's the .topazini file in your home directory that is the
>> culprit ... if you remove that file, the scripts should start the
>> gemservers properly ...
>>
>> I've submitted a bug on this[4] and I consider it a bug that the
>> gemserver script was not exiting with an error message ...
>>
>> Hopefully things will start to go a bit smoother for you ...
>>
>> Dale
>>
>> [4] https://github.com/GsDevKit/GsDevKit_home/issues/175
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170519/703a0f9a/attachment-0001.html>
More information about the Glass
mailing list