TRU64 5.1B Login freeze

[DaveHarrison]

Hello

I have a Compaq Alpha Server ES40 running TRU64 5.1B.

The server is used quite a bit through a days work and I think someone has either inadvertantly changed something or its just had enough.

Now it loads into the login screen, but when the username and password is entered and it begins to load the CDE environment, it freezes.

I've read about for some kind of solution but have found nothing that helps and I'm totally out of ideas!

You can remote log into the server from another terminal using the rlogin command and roam around as if there isnt a problem. Its just when the server opens the starting environment screen it freezes.

Any experts out there who can help?

Thanks

[Steven Schweda]

> [...] the username and password [...]

Any user? (How many have you tried?)

How much of the CDE do you get before it
freezes? (Hour-glass, desktop background,
complete desktop, some old application
windows, ...?)

Have you tried any of the other CDE log-in
options (fail-safe, ...)?

After you rlogin, you can look for some
resource shortage, like swap space
exhaustion, or the like. You can also look
for interesting things in the system log
file(s).

How long since the last re-boot?

[Ivan Ferreira]

Ensure that the host name returned by "hostname" match an entry in /etc/hosts.

Check your .dtprofile and .profile files. Rename these files to troubleshoot the problem.

Does this happens with any user including root?

[DaveHarrison]

I've attempted login with 2 users:
root and a user names unitf

There was an original user named unit who I know has been locked while the server has been running using the sysman and just checking the "lock account" button.

The server hasn't been rebooted for around 2 days, it was only after changing the network setting to force 100m full duplex (originally set to 10 half after auto-negotiation saw the hub, not switch) I decided to restart the box to give it a fresh start then I noticed this.

The fail-safe login works fine, only when I'm logged in that, I'm clueless what to actually do to find the problem.

The screen it dies on every time is directly after clicking ok after entering the password. It jumps to the "starting session" screen and stays in hourglass. You can move the cursor around the screen, but the rest is just dormant.

The hosts file is set up with the 127.0.0.1 localhost and 172.16.101.111 hostname


Not sure where the .dtprofile is?

[Rick Retterer]

Dave,
I don't know if I'm a expert or not but I have been in your shoes.

CDE is network dependant on Tru64 Unix, so if you change anything that has to do with the network, you can affect your login with CDE.

I have attached a script for you to put on your system in the directory /usr/dt/config/xsession.d/ directory.

It's in a tar file named 0050.tar and you will need to ftp this from your PC to your Tru64 Unix system in "binary" mode.

Then untar the file, and it will create a file named: 0050.init2

Do NOT edit this file as most editors will introduce line feeds and carrige returns and corrupting the file. You can more or cat the file out if you like.

This script must be placed in the /usr/dt/config/xsession.d directory and given the name 0050.init2. Make sure that the file has 755 priv's on it.

What the script does, is checks the basic network functionality and if it is not OK, it will define a environment variable named DTNONETWORK to "true" and exports it. This will instruct CDE to not pay attention to the network status and allow you to login.

It will also tell you if something is amiss such as your hostname not matching your hostname variable in /etc/rc.config... etc...

It has helped me in the past, and I hope that it helps you as well.

[Rick Retterer · Accepted solution]

Dave,
I almost forgot the most important part...

After you have the file in place, simply logout and back in again.

Try the root user first.

The script will output information into the console window, and in your $HOME/.dt/startlog file.

If it finds that the network is OK, it will say: Network OK in the log file.

Cheers,
Rick

[DaveHarrison]

That script ran like a dream.

When logging in with the user "unitf" it now restarts the login session rather than freezing and gives a readout of some kind of loopback problem.

root can now successfully login.

The startlog file for "unitf" is as follows:

--- Wed Jan 9 09:23:18 GMT 2008
--- /usr/dt/bin/Xsession starting...
--- Xsession started by dtlogin
--- Reloading host access via dxhosts
--- sourcing /usr/users/unitf/.dtprofile...
--- sourcing /etc/dt/config/Xsession.d/0010.dtpaths...
--- sourcing /usr/dt/config/Xsession.d/0010.dtpaths...
--- sourcing /usr/dt/config/Xsession.d/0020.dtims...
--- sourcing /usr/dt/config/Xsession.d/0030.dttmpdir...
--- sourcing /usr/dt/config/Xsession.d/0050.init2...
NOTE: Starting CDE required local loopback device lo0.
ifconfig: ioctl (SIOCDIFADDR): Permission denied


Does this mean that there is a problem with the loopback device?

When logged in as root and I run the ifconfig command the loopback device Lo0 127.0.0.1 is there and fine, it's also in the hosts file ok as well!

Am I missing something really obious like a permissions thing?

[Ivan Ferreira]

If root can login then it should be a permission problem.

Check that everyone has read permissions for /etc/hosts file.

Check that the user owns the HOME directory and all files inside it.

>> ifconfig: ioctl (SIOCDIFADDR): Permission denied

This is extrange.

[Pieter 't Hart]

Dave,
I agree with Rick that Tru64 is very network dependant. More specific it dependands very much on name resolution.
So first things that must be right is /etc/resolv.conf and /etc/hosts.
The entry for this host and the localhost entry must be correct, (no multiple lines with same ip-adress FQDN and short name).
dns-servers (if configured) must be reachable (nslookup).
hostname must match in rc.config and /etc/hosts.

Do you have different behaviour on the local console and from a different X-station?
It may be that not the server has a problem but the networkname of the workstation from wich you connect.

I don't see if you answered if you could establish a "failsafe session".
if you can, what's in the $HOME/.dt/errolog ?

cheers,
Pieter

[Victor Semaska_3]

We had a similar problem wrt to permissions. Check the permissions of this directory & file:

# ls -ld /cluster/members/member/tmp/.X11-unix
drwxrwxrwt 2 root system 8192 Oct 22 20:16 /cluster/members/member/tmp/.X11-unix
# ls -ld /cluster/members/member/tmp/.X11-unix/X0
srwxrwxrwx 1 root system 0 Oct 22 20:16 /cluster/members/member/tmp/.X11-unix/X0

Our problem was with X0, it had permssion 755 set somehow. Still happens on occasion for some reason.

Vic