CDE Login - root is fine but users cannot log in

[William Ip]

root user logs into CDE fine.

end-users logging in sit and hang for a very long time on blue screen.

Looking in a user's /home/[user]/.dt/errorlog shows:

ColorServer: Color Server Warning, losing ownership of the selection: Should nev
er lose the selection.

Workspace Manager: Unable to read bitmap file Fphelp

Looking in /var/dt/Xerrors, I see:

/usr/bin/X11/xset: bad font path element (#43), possible causes are:
Directory does not exist or has wrong permissions
Directory missing fonts.dir
Incorrect font server address or syntax
/usr/bin/X11/xset: bad font path element (#43), possible causes are:
Directory does not exist or has wrong permissions
Directory missing fonts.dir
Incorrect font server address or syntax

I suspect this is a permissions thing. I've already checked /etc/hosts, /etc/resolv.conf and /etc/nsswitch.conf. Have verified inetd.conf.

Have run dr_dt and things are verified fine for CDE (note, root logs in fine via CDE).

Help!

Thanks in advance,

Bill

[G. Vrijhoeven]

Hi,

check out the rigts on the files, make shure you have the right permissions.

Gideon

[Sanjay_6]

Hi Willliam,

Try this,

http://us-support3.external.hp.com/cki/bin/doc.pl/sid=85b115db03cec582ad/screen=ckiDisplayDocument?docId=200000056191644

Hope this helps.

Regds

[Sachin Patel]

May be your user has home directory on nfs and it is not there.

Sachin

[Sanjay_6]

Hi William,

Here is another thread for you to look at,

http://us-support3.external.hp.com/cki/bin/doc.pl/sid=c2681bc31d21f51faa/screen=ckiDisplayDocument?docId=200000016256883

Hope this helps.

Regds

[Scott Van Kalken]

I would be checking the /usr/bin/X11 directory.

look at the perms on /usr/bin/X11/xfs

there should be a symlink to it.

We use weird permissions here, so I'm not sure what it's supposed to be...

hang on - on my play box, which IS a default install of HPUX 11.00 it's got a stick bit set.

[William Ip]

Hi... tried all the suggestions above, and no resolution yet.

BTW, this is a single C-class system running HPUX 10.20, and users are logging in at the system console, not via Xterms, or PC emulation.

- accounts are not on an NFS server... they're on a local volume on the system
- I've run dr_dt and checked the CDE permissions
- I've tried creating new accounts and they still hang
- only the root user can login via CDE normal or failsafe... all user accounts hang.

Does anyone know what the required permissions are for the X11 system, including any sticky bits? I'm suspecting someone twiddled with folders in the /usr or /var system.

Thanks in advance!

Bill

[Wodisch]

Hello William,

check the permissions for everything in and below the following directories:

/etc/dt/
/usr/dt/
/var/dt/

since they are used during every CDE session.

HTH,
Wodisch

[William Ip]

Wodisch wrote:

"check the permissions for everything in and below the following directories:

/etc/dt/
/usr/dt/
/var/dt/

since they are used during every CDE session."

What are the proper permissions/sticky bits for these folders/files? I don't have another system here to compare it against.

Thanks,

Bill

[Sachin Patel]

This is what I have for 10.20 system.

drwxr-xr-x 4 root sys 1024 Jun 10 1996 /etc/dt
drwxrwxrwx 4 root sys 1024 Jul 28 1997 /var/dt
dr-xr-xr-x 9 bin bin 1024 Jul 8 1997 /usr/dt

[William Ip]

Satchin Patel wrote:

"This is what I have for 10.20 system.

drwxr-xr-x 4 root sys 1024 Jun 10 1996 /etc/dt
drwxrwxrwx 4 root sys 1024 Jul 28 1997 /var/dt
dr-xr-xr-x 9 bin bin 1024 Jul 8 1997 /usr/dt "

What about the files/folders underneath? Is there an HP utility that verifies standard permissions, or is there a function to reset a system to "standard" permissions?

Thanks,

Bill

[S.K. Chan]

Attached doc might help. Look at the "Only the Root User is able to Login" section of the doc for tips on what to check for.

[Sachin Patel]

Hi William,
As from your posting
it might be font server problem.

Setup a fontserver to provide the necessary fonts.

It is necessary to set up a fontserver to provide fonts to an Exceed Xserver so
that CDE and HP-UX applications will work correctly. Therefore, begin by
checking to see whether or not a fontserver is already running using the
following command:

ps-ef | grep xfs

If the fontserver is running then perform step 1. Otherwise, perform step 2.

1. Ensure that the fontserver's config file (/etc/X11/fs/config) contains
the following fontpath at the end of the catalogue line:

/usr/dt/config/xfonts/C/

If the above fontpath is missing, then append it to the catalogue line and
stop and restart the fontserver so that the change will take effect. The
following command can be used to stop and start the fontserver:

/sbin/init.d/xfs stop;/sbin/init.d/xfs start

Note: All font paths are seperated by a ",". Additionally, stopping
and restarting the fontserver while in use by users on Xterminals could
potentially reset their Xserver. Thus, causing their session to exit.

2. Set up the fontserver as follows:

a. Edit the file /etc/X11/fs/config and append
/usr/dt/config/xfonts/C/ to the end of the catalogue line if it is
not present.

b. Edit the file /etc/rc.config.d/xfs and make sure it has
the following set:

RUN_X_FONT_SERVER=1

c. Start the fontserver by typing the following:

/sbin/init.d/xfs start

NOTE: If the error "XFontserver error: Cannot open configuration
file." results when trying to start the fontserver, then perform one of
the following steps to resolve the problem:

1. Install the latest fontserver patch which corrects the defect.

2. Add the following line to the /etc/rc.config.d/xfs file to resolve
this problem: CONFIG_FILE_NAME=/etc/X11/fs/config

[William Ip]

Okay, I've been poking around with some of the suggestions given to date... The root user still remains the only account that can log into CDE, failsafe and commandline.

Still can't get any user accounts to log into CDE (including new users created to test this)... and I've even pointed these test accounts to non-NFS accounts. User are able to login to fail safe and to Command Line. They are able to nslookup [host] and nslookup [ip]. I've done pretty much all the variants actions of deleting the .* files from users' home to let the system recreate them, to copying the working .* files from root and changing ownership.

The users' .dt/errorlog still shows:

Thu Dec 06 13:57:48 2001
ColorServer: Color Server Warning, losing ownership of the selection: Should nev
er lose the selection.

The users' ./dt/startlog shows:

--- Thu Dec 6 13:57:47 EST 2001
--- /usr/dt/bin/Xsession starting...
--- Xsession started by dtlogin
--- sourcing /wip/.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...
--- sourcing /usr/dt/config/Xsession.d/0040.xmbind...
--- sourcing /usr/dt/config/Xsession.d/0060.srcsysenv...
--- sourcing /etc/dt/config/Xsession.d/xsession.eds...
--- sourcing /etc/dt/config/Xsession.d/xsession.ugs...
--- starting /usr/dt/bin/dthello &
--- starting /usr/dt/bin/dtsearchpath -ksh
--- starting /usr/dt/bin/dtappgather &
--- execing /usr/dt/bin/dtsession...

The /var/adm/startlog/startlog.log shows:

Dec 6 13:57:39 kull syslog: libtt[2844]: _Tt_rpc_client::init(): fcntl(F_SETFD)
: m
Dec 6 13:57:39 kull syslog: libtt[2844]: ttdt_Xt_input_handler(): tttk_message_
receive(): TT_ERR_NOMP^INo ttsession process is running, probably because tt_ope
n() has not been called yet. If this code is returned from tt_open() it means tt
session could not be started, which generally means ToolTalk is not installed on
this system.
Dec 6 13:57:39 kull syslog: libtt[2851]: _Tt_rpc_client::init(): fcntl(F_SETFD)
: m
Dec 6 13:57:39 kull syslog: libtt[2851]: ttdt_Xt_input_handler(): tttk_message_
receive(): TT_ERR_NOMP^INo ttsession process is running, probably because tt_ope
n() has not been called yet. If this code is returned from tt_open() it means tt
session could not be started, which generally means ToolTalk is not installed on
this system.
Dec 6 13:57:39 kull syslog: libtt[2846]: _Tt_rpc_client::init(): fcntl(F_SETFD)
: m
Dec 6 13:57:39 kull syslog: libtt[2846]: ttdt_Xt_input_handler(): tttk_message_
receive(): TT_ERR_NOMP^INo ttsession process is running, probably because tt_ope
n() has not been called yet. If this code is returned from tt_open() it means tt
session could not be started, which generally means ToolTalk is not installed on
this system.

I've looked up and tried all the Tooltalk problem fixes on ITRC here, and no go.

I've run dr_dt and it gives a clean bill of health for CDE.

I'm still very suspicious it is permissions for the various X11 or dt files *AND* folders in /etc, /usr and /var... I'm hoping someone can provide a listing, or let me know if there is a tool/reference guide somewhere that tells me what the proper ownership and permissions are...

Since the system is still down, would love more suggestions.

Thanks!

Bill

[Christopher Caldwell]

I've seen this problem when there were DNS resolution problems;
specifically
-check forward and reverse look up of the client
-check forward and reverse of the server (note *where* the name was found (files, DNS, etc.) to make sure the name is being found where it should be found.
-look at nsswitch.conf or resolv.conf

[William Ip]

C. Caldwell wrote:

"I've seen this problem when there were DNS resolution problems;
specifically
-check forward and reverse look up of the client
-check forward and reverse of the server (note *where* the name was found (files, DNS, etc.) to make sure the name is being found where it should be found.
-look at nsswitch.conf or resolv.conf"

Have checked these already... used both with DNS and Files, and Files only, and both offer same behaviour. We don't use nsswitch.conf at all.

Regards,

Bill

[Sachin Patel]

Hi William,
Is it posible for you install X again?

Sachin Patel

[Alex Glennie]

You *could* have several red herrings here !

If the error is time stamped in the users $HOME/.dt/errorlog file and coincides with when the user last logged in try the following :

Check for the correct permissions on $HOME: drwxr-xr-x and make sure the correct owner and group are on the file. ps don't forget to check the group ! nb usually the errorlog contains errors pertaining to the users CDE session .... but they cant login so how can they have one or maybe its not that simple ;)?

if not =>

any further clues in $HOME/.dt/startlog if you add set -x in the users .dtprofile ?

As to the TT Tooltalk errors :

The problem is that ttsession exits before other CDE processes that
expect to communicate with ttsession upon user log out. These
messages can be ignored, as all processes successfully exit. The messages
are informational, indicating that dtwm and other processes attempted
to notify ttsession of their exit, but the ttsession process
was not found. Again this is a known issue and not necessarily associated with your problem.

I like the idea of adding files first before resolving hostnames by DNS in the /etc/netconf file but it doesn't explain why root is OK

I'd also check permissions on /tmp /dev/null (make sure character device) and /var/spool/sockets if you haven't already.

If you create a NEW local user do you still have the problem.

ps EDS and UG ..... no connection with EDS UK and unigraphics by any chance .... ?

[Wodisch]

Hello Bill,

can your users log in (through the CDE login-dialog) with the "options" used to select a "Fail-safe session"?

Curious,
Wodisch

[K.Vijayaragavan.]

I had similar problem with my HP workstation and i found the /home file system almost full (100% used) and i extended the file system size to get more free space. The problem got resolved with the above approach.Hope this may be useful for you.

regards

k.vijayaragavan.