Last Updated May 20, 2003
Applies to versions of GemStone/S prior to 6.2; applicable to later versions of GemStone/S and GemStone/S 64-bit, except some operations performed by pagemanager
Linked logins differ greatly from rpc logins. Linked logins do not require launching a separate gem process, since the libraries containing gem code are linked to the application. RPC logins, on the other hand, need to launch a gem. To make this flexible, this task is handled by the netldi process.
If you have problems on login, the error message may or may not be specific as to the problem. Some problems will be reported in either the gem log or the netldi log, depending on where they occur. These may be GemStone specific, or errors that occur in the underlying OS and are just reported back up to the user, such as network or permission errors. Other problems, like timeout, are more difficult to debug. If you have a timeout or other error for which the error message is not useful, restart the netldi process in debug mode (with the -d option). This will print more information in the netldi log to help in understanding where the problem is occurring.
Also, you should try to verify the login failure using topaz, running on the same machine as the stone, and running as the stone/netldi user. This elimates the variables of GBS, network, and (possibly) permissions issues.
This is the sequence of steps that occurs on RPC login, with corresponding entries in the netldi log:
1. Client (Topaz, GBS, or GCI): Contacts the Netldi and requests a session
In the netldi -d log, see the following lines:
0: Fri 25 Apr 2003 11:30:43 AM PDT
Attempting accept...
...succeeded accepting client from <machineName>, connection = 2
0: Fri 25 Apr 2003 11:30:43 AM PDT
Finished reading client request:
Client is a rpc application.
'!#encrypted:<username>@password!gemnetobject'
If there is no message here after a login attempt, the failure is in connecting to the netldi. This is usually clear in the error message. Check your login parameters, particularly the netldi name, the port id assigned in the services file, and the GEMSTONE_NRS_ALL setting. If you have started netldi with the -p option to specify a port range, check that these ports are appropriate and if you have a firewall, that these ports are open.
2. Netldi: Starts listening on a “callback” port
See step 3 for the port id that the netldi will be listening on. This is a different port than the netldi uses to accept connections (the -p option). This port is just used temporarily for the gem-netldi communication.
3. Netldi: Launches gemnetobject (or other similar script that was specified in the login parameters), telling it the number of the callback port it should use
0: Fri 25 Apr 2003 11:30:43 AM PDT
Successful fork; Child's Pid: 25449 command is:
'/<$GEMSTONE>/sys/gemnetobject TCP 47218 30'
Note that “Successful fork” does not mean the gem was correctly started and initialized; the netldi does not block.
4. gemnetobject script sources .profile
Errors in this step are difficult to diagnose as they occur in the script, outside of the netldi or gem, so details are not reported either in the netldi nor the gem logs.
5. gemnetobject script exec’s gem to start running gem’s code.
6. Gem: Initializes itself
At this point there is a gem log. The pid of the gem process is in the netldi log (see step 3).
7. Gem: Starts listening on a client service port
This is yet another distinct port; this is the one that will be used for ongoing communication between the gem and the client. See the port id in the netldi log, in step 10.
8. Gem: Connects to the Netldi on the callback port
9. Gem: Tells the Netldi that it is ready, and the number of its client service port
0: Fri 25 Apr 2003 11:30:43 AM PDT
Now reading reply from child
If this step does not occur within the netldi timeout, the netldi times that gem out and stops listening on the callback port. You will see a message to that effect in the netldi log. If you are getting timeouts with the default timeout interval, try increasing this using the -t<number of seconds> option. It may at least help you keep working while determining why the timeout is occurring.
10. Netldi: Passes the number of the client service port back to the client
0: Fri 25 Apr 2003 11:30:43 AM PDT
Reply to client started:
'SUCCESS 47219'
0: Fri 25 Apr 2003 11:30:43 AM PDT
Done writing reply to client.
0: Fri 25 Apr 2003 11:30:43 AM PDT
Disposed. elapsed time = 0
The netldi is replying to the original request in step 1, from the client (topaz, GBS or GCI), informing it that a gem has been started for it, and this gem is waiting for a connection at a specific port.
11. Client: Contacts the gem directly on its client service port
FURTHER DEBUGGING OF LOGIN PROBLEMS
If it is still not clear what the reason for the login failure is, it is possible to do some of the login steps individually to try to isolate the failure. These are instructions to start up the gem in network mode, and allow it to wait for a connection.
1. In one window, start up a gem in network mode and allow it to wait for a connection:
$GEMSTONE/sys/gem GDBG> connect agent foo
2. In a separate window, login from topaz using this prestarted gem.
topaz -r topaz> set gemnetid foo topaz> set gemstone <stoneName> topaz> set user <userId> pass <password> topaz> login