non-root user can't login on CDE console

[Victor Semaska_3]

Greetings,

I have a weird problem that just started happening. First, the stats:
5 ES45s in a TruCluster V5.1B PK4.

A non-root user can't log into the console on the 5th member. It accepts the username and password but stalls for a few seconds with the a blank screen and then the login window re-appears. Account root can login without any propblems.

The same non-root user can log into the consoles of members 1 thru 4 without any problems.

I'm not that familiar with CDE but this is what I found:

~/.dt/errorlog
Mon Oct 17 10:05:34 2005
Workspace Manager: I/O error on display:: :0.0

~/.dt/startlog
--- Mon Oct 17 10:13:29 EDT 2005
--- /usr/dt/bin/Xsession starting...
--- Xsession started by dtlogin
--- Reloading host access via dxhosts
--- sourcing /usr/users/SYSO/whitmans/.dtprofile...
--- sourcing /usr/dt/config/Xsession.d/0010.dtpaths...
--- sourcing /usr/dt/config/Xsession.d/0020.dtims...
--- sourcing /usr/dt/config/Xsession.d/0030.dttmpdir...
--- starting /usr/dt/bin/dthello &
--- starting /usr/dt/bin/dtsearchpath
/usr/dt/bin/dthello: can't open display
Error: Can't open display: :0
--- starting /usr/dt/bin/dtappgather &
--- execing /usr/dt/bin/dtsession with no profile...
--- Starting /usr/dt/bin/sdtdbcache -init
--- Starting /usr/dt/bin/ttsession -s
--- Starting /usr/dt/bin/dtsession
--- not sourcing /usr/users/SYSO/whitmans/.profile (see /usr/users/SYSO/whitmans/.dtprofile)

So it appears to be having problems opening the display but why? Also, why only on the 5th member?

I tried restarting the CDE with:
/sbin/init.d/xlogin stop
/sbin/init.d/xlogin start
It didn't help.

Thanks,
Vic

[Ivan Ferreira]

It may be a file system permissions error, or a bad DISPLAY environment variable set.

Verify the permissions for the hosts file, the home directory, the tmp directory. This is less probably because on the other nodes it works, but as root can login, you still should check that.

Verify the value of the DISPLAY variable for the user.

Verify the hosts and dns entry for this host.

[Victor Semaska_3]

Ivan,

Thanks for the advice. I checked the permissions of the files you mentioned and they're OK. Also, host and DNS entries are fine. The user doesn't set DISPLAY. When I log in on another member as that user DISPLAY is:
:0.0
Which is normal.

It does look like a permissions problem and since it's only member 5 it sounds CDSL related.

Vic

[Ivan Ferreira]

You could use cdslinvchk to verify CDSLs.

[Victor Semaska_3]

Ivan,

Thought of that too. Ran it with no errors plus ran allverify and it didn't find anything related to CDE.

Vic

[Ivan Ferreira]

I think that you have a long way to go.

Can a newly added user logon to the console?

Can you post please the contents of /var/dt/Xerrors.

Also verify the permissions of the files and directories in /var/dt.

[Victor Semaska_3]

Ivan,

You're right, I do have a long way to go. When it became apparent that it wasn't a simple problem I decided to call HP Telephone Support and so far he's baffled.

I'll post what the problem was when we find it.

Vic

[Vladimir Fabecic]

Do all servers have same graphycs adapter? Do device files of this node have the same permitions?
Just my thinking. I would like to know what was the reason of problem so please post.
Regards

[Balasubramanian S]

Hello Victor,
Can you please do/check the following?

* Can you make sure that /etc/hosts is world readable.

* remove the $HOME/.dt directory this ensures that the problem is not with the session files.

* Is the DISPLAY environment variable the same for root and non-root users?

[Victor Semaska_3]

Vladimir,

All 5 ES45s have the same graphics adapters, actually they are identical in hardware configuration.

The device files have the same permissions.

I will post what the problem was when we find it.


Balasubramanian,

/etc/hosts is world readable.

We did try deleting the ~/.dt but it didn't help.

The DISPLAY environment variable is the same for root & non-root which is :0.0

Thanks guys for your help,
Vic

[Vladimir Fabecic]

Hello
Once I had strange problems with newly added cluster member with /tmp. It was not writable by users, only root. Probably will not help, but try.

[Rick Retterer]

Hello,
I'm working with Victor on this from the support center. The part that is missing here is that theses systems have C2 security enabled on them.

Applications that have the SUID bit set on them will run and display on the graphics terminal. If the application does not have the SUID bit set, then the appliation fails with "can't open display" or "Invalid display for transport" which in this case is the "local" transport. If you use ip.address.of.system:0.0, then the application is allowed to display.

The applications with the SUID bit set on them are: xterm, dtterm, dxterm and xmesh.

All 4 of these applications can display to the console using ":0.0" or "local:0.0".

We are going to look into the SIA stuff today to see if there have been any changes into this database.

Cheers,
Rick Retterer
HP Services
Atlanta, GA.

[AwadheshPandey]

if root or all other user can login on the system. then delete ~/.Xauthority file of particular user.

[Rick Retterer]

We have already removed the user's .Xauthority file as well as the .TTauthority.

It is something more hidden from us than that.

We are continuing to work on this issue.

Cheers,
Rick

[AwadheshPandey]

sorry for last reply it is .TTauthority to move, try mv .TTauthority .TTauthority.old
this will solve ur problem

Awadhesh

[Rick Retterer · Accepted solution]

Found the cause of the problem.

It appears that the permissions on the /tmp/.X11-unix/X0 file were changed from 777 to 755.

This only permitted the root user to have write access to the device file.

After changing the permissions back to 777 on the /tmp/.X11-unix/X0 file, now the non-root users are able to login and bring up a CDE session successfully.

Cheers,
Rick Retterer
HP Services
Atlanta, GA.
Tru64 Unix Graphics Support

[Vladimir Fabecic]

That is what I said. It was very strange that newly added member did not have 777 permition on /tmp. I did "chmod 777 /tmp" and fixed the problem.

[Johan Brusche]

Vladimir ,

Setting 777 on /tmp is insecure !! The "t"-bit must be set on /tmp , so rather use :

chmod 1777 /cluster/members/member2/tmp

Rgds,
___ Johan.

[Vladimir Fabecic]

Johan, of course you are right. I did what you said later, but first I had to be sure that /tmp permition is causing problem. This kind of problem happened to me just once and still do not know why it happened.

[Victor Semaska_3]

Rick beat me to it. It was a permissions problem.

Vic