query on /etc/sm

[Ronny_7]

Hi,

My customer has a A4100 running on Tru64 Unix V4.0D. The users are logging to the applications from their PCs.

Once they login to the application, the application will access the files on the A4100 system through NFS.

My customer noticed that whenever there is a reboot of the A4100 system, the initial login of the users to the application will be very long. The users have to logout from their PCs and login again then they will get faster connection.

He noticed during the initial login, there are no files in the /etc/sm directory.
He did a test to manual created one of the PCs name in /etc/sm and that PC can get immediate connection to the A4100 system.

His queries,
1. Is it normal for the initial login to take very long from the PCs?

2. Is it correct for him to manual create the file in /etc/sm?

Hopefully I have post this query correctly as I am not very sure myself if there is a problem here.

Regards,
Ronny

[Ralf Puchner]

1. if nameresolution works fine there should be no long login process.

2. no the /etc/sm directory contains the information for the locking/statd daemon. Do not create them manually!

nameresolution is an important factor if using locking and authentication. Be sure both machines see the same names (long/short) and resolution works fine using ip and naming (long/short)!

If communicating via nfs to an pc, lower the packet size to prevent slow responses!

[Ronny_7]

Hi Ralf,

Thank you for the reply.

I do not quite understand your explanation.

Can you elaborate in more details?

Thanks and Regards,
Ronny

[Ralf Puchner]

Ronny,

the /etc/sm directory will be used by the rpc.statd and rpc.lockd to write down their informations about the workstations holding locks. rpc.statd will poll the workstations and check if the workstations are still available.

So if changing the /etc/sm directory manually will lead to an unknown state within the locking mechanism.

/etc/sm and login/nfs does not depend on each other. You can use locking within nfs, but local locking of files are also done by the rpc.lockd meachnism.

It is important, that the nameresolution mechanisms (/etc/hosts, bind, yp) do have the same view of the hostnames, because the name hugo and hugo.domain.com is not equal for lockd and telnet. Telnet and lockd will do reverse name/ip resolution for security and internal management reasons, leading to an timeout if name can not be resolved properly.

[Ronny_7]

As per replies.