How to trouble shoot GUI login problems

Hi Everyone,

This may be a very vague questions, but let me try it anyways.

We are having login issues via GUI, but ssh2 seems to work fine. Where do I start to troubleshoot this issue?

  • the clients are member of NIS domain, which I have tested working

Any inputs are very welcome. Thanks in advance.

Cheers,
Jatinder Singh

Hi
As in actual logging in the users (authentication), or getting the desktop environment up and running?

Check the log files down in /var/log for clues, eg messages.

Thanks for a quick answer malcolmlewis!

I have checked log files, nothing that stands out that could give me clues.
Is there a way to get more logging during login process?

are any mounted partitions full?


DenverD
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

What if there were no hypothetical questions?

nothing above 58%, which is /space

Hi
What about the Xorg log files assuming that all your authentication is working with NIS (Have you checked the NIS server log files).

So some more details on what you see would help. Can you login ok from a console session. At the login screen press ctrl+alt+F1 and login, press crtl+alt+F7 to get back to a GUI login. What desktop environment are you using, Gnome KDE4 etc?

I have checked Xorg.0.log, nothing specials othen some fonts missing (Speedo, PEX, cyrillic,latin2,latin7,baemuk,kwintv,ucs,hellas,misc,xtest). The systems were working yesterday.
Since these are remote systems, I don’t have console access. I accessing them via VNC and ssh, but I’m seeing the same thing as a local user. Nothing happens after password have been entered. Desktop environment is KDE.

Hi
So VNC or local access (As in physically in front of the remote system) to the KDE desktop doesn’t work? Have you tried a different desktop login?

What I ment was that I only have VNC and ssh access, I don’t have physical access to the system(s). No I have not tried other desktop login’s.

Hi
OK, so it’s a vnc with KDE issue then :wink: What about logs in the users home directory for the vnc session?

I have some corrections to give. Now that I have checked further, looks like gnome is being used because there is .gnome files in users home folders. I don’t see any vnc logs in users home dir.

ixin-rajdeepm:/home/rmukherjee # tail .xsession-errors
Nautilus-Share-Message: spawn arg “net”
Nautilus-Share-Message: spawn arg “usershare”
Nautilus-Share-Message: spawn arg “info”
Nautilus-Share-Message: end of spawn args; SPAWNING

Nautilus-Share-Message: returned from spawn: SUCCESS:
Nautilus-Share-Message: exit code 255
Nautilus-Share-Message: ------------------------------------------
Nautilus-Share-Message: Called “net usershare info” but it failed: ‘net usershare’ returned error 255: net usershare: usershares are currently disabled

Could this be it?

Hi
Can you disable that? I’m not really a VNC person, there should be a
vnc session or global startup config in /etc?


Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.32.24-0.2-default
up 3 days 2:57, 2 users, load average: 0.17, 0.07, 0.06
GPU GeForce 8600 GTS Silent - Driver Version: 260.19.29

jshunjan wrote:
> I have some corrections to give. Now that I have checked further, looks
> like gnome is being used because there is .gnome files in users home
> folders. I don’t see any vnc logs in users home dir.
>
> ixin-rajdeepm:/home/rmukherjee # tail .xsession-errors
> Nautilus-Share-Message: spawn arg “net”
> Nautilus-Share-Message: spawn arg “usershare”
> Nautilus-Share-Message: spawn arg “info”
> Nautilus-Share-Message: end of spawn args; SPAWNING
>
> Nautilus-Share-Message: returned from spawn: SUCCESS:
> Nautilus-Share-Message: exit code 255
> Nautilus-Share-Message: ------------------------------------------
> Nautilus-Share-Message: Called “net usershare info” but it failed: ‘net
> usershare’ returned error 255: net usershare: usershares are currently
> disabled
>
> Could this be it?

If you suspect that the problem is some exception whilst
mounting/accessing the users’ home directories then it might be worth
trying to login as root (using the GUI), because root shouldn’t use any
fancy directories/networking etc.

Cheers, Dave

Hi Everyone,

Thanks for you input so far, hopefully we get this problem resovled today.

This is what I/we have done so far:

  1. Tried login as root using GUI, same effect not able to login.
  2. Removed network connection, tried login as root -> sucsessful. As expected users are not able to login.

This leads us to believe that it has to be something locally. How can I check when the last system update happend and what was updated?

Found this in warn.log:

Jan 11 15:51:28 xxxx-xxxxxxxx dhclient: send_packet: please consult README file regarding broadcast address.
Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to load source “xml:readwrite:/home/xxxxxxxxxx/.gconf”: Failed: Could not make directory /home/xxxxxxxxxx/.gconf': Input/output error Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): None of the resolved addresses are writable; saving configuration settings will not be possible Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): No writable config sources successfully resolved, may not be able to save some configuration changes Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Unable to open saved state file '/home/xxxxxxxxxx/.gconfd/saved_state': Input/output error Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won't be able to restore listeners after gconfd shutdown (Input/output error) Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won't be able to restore listeners after gconfd shutdown (Input/output error) Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won't be able to restore listeners after gconfd shutdown (Input/output error) Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Error setting value for /desktop/gnome/background/picture_filename’: Unable to store a value at key ‘/desktop/gnome/background/picture_filename’, as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/opt/gnome/gconf/2/path doesn’t contain any databases or wasn’t found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn’t work in your home directory or 4) your NFS client machine crashed and didn’t properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put “ORBIIOPIPv4=1” in /etc/orbitrc. As always, check the user. syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Error setting value for `/desktop/gnome/background/picture_options’: Unable to store a value at key ‘/desktop/gnome/background/picture_options’, as the cd configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/opt/gnome/gconf/2/path doesn’t contain any databases or wasn’t found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn’t work in your home directory or 4) your NFS client machine crashed and didn’t properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put “ORBIIOPIPv4=1” in /etc/orbitrc. As always, check the user. syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:51:34 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to log addition of listener gnome-session (Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error));will not be able to restore this listener on gconfd restart, resulting in unreliable notification of configuration changes.
Jan 11 15:51:51 xxxx-xxxxxxxx zmd: Daemon (WARN): Not starting remote web server
Jan 11 15:52:04 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:52:04 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:52:04 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:52:04 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:52:04 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:52:04 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Failed to open saved state file: Failed: Failed to open gconfd logfile; won’t be able to restore listeners after gconfd shutdown (Input/output error)
Jan 11 15:52:04 xxxx-xxxxxxxx gconfd (xxxxxxxxxx-4283): Could not open saved state file ‘/home/xxxxxxxxxx/.gconfd/saved_state.tmp’ for writing: Input/output error
Jan 11 15:52:34 xxxx-xxxxxxxx dhclient: could not restore resolv.conf: No such file or directory
Jan 11 15:52:34 xxxx-xxxxxxxx dhclient: send_packet: Network is unreachable
Jan 11 15:52:34 xxxx-xxxxxxxx dhclient: send_packet: please consult README file regarding broadcast address.
Jan 11 15:52:42 xxxx-xxxxxxxx ntpdate[4747]: can’t find host 0.pool.ntp.org

Does this give you guys any hints?

The relevant directories for gnome are ~/.gnome2, ~/.gconf and - partly - ~/.config.
I would create a new user for testing purpose and see if you can log in as that user.
Make sure the new user’s home directory belongs to him (which should be the case if you create it from YaST or using useradd on the CLI.)
Also make sure you don’t have anything (or anything unappropriate ) in /etc/skel/.gnome2, /etc/skel/.gconf and /etc/skel/.config - in case someome created these directories.

Created a new user with YaST. Still the same. After entering the password and pressing <enter>, the field gets grayed out and it hangs there.
Is there a way to reinstall GUI?

Don’t have these files: /etc/skel/.gnome2, /etc/skel/.gconf and /etc/skel/.config

From /var/log/messages:

Jan 13 03:53:12 xxx-xxxxxxxx syslog-ng[21961]: Changing permissions on special file /dev/xconsole
Jan 13 03:53:12 xxx-xxxxxxxx syslog-ng[21961]: Changing permissions on special file /dev/tty10
Jan 13 03:53:12 xxx-xxxxxxxx syslog-ng[21961]: Cannot open file /dev/tty10 for writing (Permission denied)

6498 pr-------- 1 root tty 0 Jan 13 03:53 /dev/xconsole

Any ideas?

That’s OK. You don’t need them. Just wanted to make sure.

For testing purpose, try to replace

DISPLAYMANAGER="gdm"

with

DISPLAYMANAGER="xdm"

in the file /etc/sysconfig/displaymanager

making a backup of this file first, so as root:


cd /etc/sysconfig
cp displaymanager displaymanager.org

Then reboot in runlevel 3, login as user and type startx