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

[DaveHarrison]

This is what I have from the errorlog:

---------------------------------------------------------------------------
Mon Jan 07 16:43:55 2008
Workspace Manager: I/O error on display:: :0.0


ERROR: Unable to start required local loopback device lo0, CDE unavialable.
ERROR: Unable to start required local loopback device lo0, CDE unavialable.
ERROR: Unable to start required local loopback device lo0, CDE unavialable.
ERROR: Unable to start required local loopback device lo0, CDE unavialable.
ERROR: Unable to start required local loopback device lo0, CDE unavialable.
ERROR: Unable to start required local loopback device lo0, CDE unavialable.

---------------------------------------------------------------------------

I gather from this its lost its loopback somehow, but from logging in as root, it can see the loopback no problem.

1 thing I do know has changed is the original user "unit" has been locked as the new user "unitf" has been created.

I'm going to unlock that account now and see if that makes any difference.

Both users, root and unitf can log into the fail-safe session, however once I was in there, I didnt really know what or how to diagnose so I stopped there.

The hostname matches up in both the rc.config and hosts file, however in the hosts file there is other types of the name next to the IP add but this has been like that since the servers were built.

(e.g.
127.0.0.1 localhost
172.16.51.1 Servera1 serveras1 Serv1
172.16.51.2 Servera2 serveras2 Serv2 )

I cant seem to find the file /etc/resolv.conf?? hosts is ok and setup. There's no multiple lines of the same IP in there.

The network runs on a fixed IP range so theres no DHCP configured although I now NTP has been setup as well but the servers have been restarted a number of times since that and all was ok.

I've just checked the owner of the account and unitf owns the unitf account and all inside it.


The ls -ld /cluster/members/member/tmp/.X11-unix command has returned:

drwxrwxrwt 2 root daemon 8192 Jan 9 12:30 .X11-unix

daemon??? is that right??


The ls -ld /cluster/members/member/tmp/.X11-unix/X0 returned:

drwxrwxrwx 1 root daemon 8192 Jan 9 12:30 .

again with daemon? daemon isn't something I've made...


If the original account created is locked, would this cause a problem to accounts in the same group?

Thanks to everyone who's helping btw

[DaveHarrison]

Have just unlocked the original user, no difference.

Have just found that the Hosts file was actually missing the 127.0.0.1 loopback as someone had changed it for NTP. I've put that back and...

still not working. Still claims it cant use the loopback

I've just logged into the fail-safe as well and ran an ifconfig and the loopback is running there fine..

[Pieter 't Hart]

check /etc/passwd wich shell is configured for these users (root unit and unitf).
check the appropriate login scripts for these users for differences
(.profile or .login, .dtprofile, etc)

[DaveHarrison]

In the passwd file, the scripts are different.

root is /usr/bin/ksh
unitf is /bin/ksh

would this cause a problem?

[Rick Retterer]

Hi Dave,
I can only get to this group in the evenings.

Yes, there appears to be a problem with the loopback device.

Would you like to remove CDE dependancy on the network altogether? You really won't loose that much functionality and it should not affect security any.

Before you do this, you will need to remove the 0050.init2 script from the /usr/dt/config/Xsession.d directory completely.

To disable the tooltalk is a series of two steps.

1. The desktop portion of the network configuration must be disabled by
adding the line:

DTNONETWORK=true;export DTNONETWORK

to the user(s) $HOME/.dtprofile file.

NOTE: The default .dtprofile is /usr/dt/config/sys.dtprofile. If the
network setting is to be permanent for all future users, the preceeding line

line may be added to this file, which will then propagate to each
user's .dtprofile.

2. The command that executes the ttdb daemon,located in the
/etc/inetd.conf, must be commented out.
The following is provided as an example. (The example has the command
line wrapped for readability. In the /etc/inetd.conf file it is on one
line):

**************** Original ************************

rpc.ttdbserverd stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd
rpc.ttdbserverd

to


**************** Modified ************************

#rpc.ttdbserverd stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd
rpc.ttdbserverd


This will disable ToolTalk, which may have an impact. Some
applications as some make use of the ToolTalk protocol, and some
applications do not... Testing may be necessary to determine the
impact on the environment.

As a side note, the portmap daemon is started in the /sbin/init.d/nfs
script. The portmap daemon is a server that converts Remote Procedure
Call (RPC) program numbers into Defense Advanced Research Projects
Agency (DARPA) protocol port numbers. It must be running in order to
make RPC calls.

If one wants to disable rpc (remote procedure calls) on the system in
question, then the /sbin/init.d/nfs script should be copied to
nfs_original to preserve the original file, with changes to the nfs
script being made to satisfy the needs, i.e. not starting the portmap
daemon...

Give that a try and see if that helps any.

Cheers,
Rick

[DaveHarrison]

HURRAH!

Thats fixed it!!

The users can now login!

Thanks Rick

Also to:
Steven
Ivan
Pieter
Victor

for helping out!

[Rick Retterer]

Cool!!

Rick.