On Fri, 2008-11-07 at 00:20 -0800, Peter Eriksson wrote:
> Ok, it happened now again. It definitely is related to the $HOME directory
> being inaccessible due to some Kerberos stuff.
>
> I ran 'xscreensaver' with '-verbose' and stored the output in a file. The
> relevant parts of it look like:
>
> ....
> Monitor is not DPMSCapable!!
> xscreensaver: restarting watchdog_timer (36000, 1348808)
> xscreensaver: restarting watchdog_timer (36000, 1348808)
> xscreensaver: restarting watchdog_timer (36000, 1348808)
> xscreensaver: starting cycle_timer (60000, 1348840)
> --->watchdog_timer()
> xscreensaver: watchdog timer raising and clearing screen.
> xscreensaver: restarting watchdog_timer (36000, 1348808)
> xscreensaver: restarting watchdog_timer (36000, 1348904)
> xscreensaver: 1: KeyPress on 0x6abe37
> ************************************
> -->sleep_until_idle() event: Motion or Key Press
> Window of Motion or KeyPress:6abe37
> until_idle_p=0 g_passwd_dialog_created=0
> ===> timers.c goto DONE user activity detected
> --> init_file_changed()
> -->pam_passwd_valid_p()
> Before uid=103 euid=103
>
> After seteuid(0) uid=103 euid=0
>
> PAM is using SERVICE_NAME="xscreensaver"
>
> xscreensaver: pam_start ("xscreensaver", "peter", ...) ==> 0 (Success)
> -->pam_conv()
> -->spawn_external_passwd()
> spawning external passwd process in make_window()
> xscreensaver: PAM ECHO_OFF("Password: ") ==> password
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> HAVE_SCRSVR_LOCK message is:Password: writing to fd:21
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> xscreensaver: spawning "/usr/openwin//lib/xscreensaver/bin/xscreensaver-lock"
> in pid 29612.
> Xlib: connection to ":3.1" refused by server
>
> Xlib: Client is not authorized to connect to Server
>
>
> (xscreensaver-lock:29770): Gtk-WARNING **: cannot open display:
> PAM_ECHO_OFF/ECHO_ON msg[replies]-> Password:
> WAiting for window id from lock dialog
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> HAVE_SCRSVR_LOCK message is:pw_read writing to fd:178
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> xscreensaver: mouse is on screen 1 of 3
> passwd input handler() fd=179
> done reading...
> removing input handler...
> passwd input handler() returning...done reading
> xscreensaver: password entry cancelled.
> <---passwd_event_loop() state =2
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> HAVE_SCRSVR_LOCK message is:pw_time writing to fd:178
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> destroy_passwd_window
> We didnt receive any input from user!!!
> after calling pam_authenticate status is:4 state is:5
> xscreensaver: pam_authenticate (...) ==> 4 (System error)
> xscreensaver: pam_end (...) ==> 0 (Success)
> <--end of pam_authenticate() returning ok_to_unblank = 0
> destroy_passwd_window
> -->cycle_timer()
> xscreensaver: dialog box up; delaying hack change.
> xscreensaver: starting cycle_timer (30000, 1348840)
> xscreensaver: blanked A: brk grew by 8K.
> -->passwd_animate_timer() returning..no dialog yet
> xscreensaver: 1: MotionNotify on 0x1680009 at 1679,181.
> ************************************
> ...
> (then the cycle repeats from '-->sleep_until_idle() event: ...'
> untill I kill the process)
>
> I had a terminal window open from another machine so I could
> check some things. I noticed that the Kerberos ticket
> seems to have expired (no NFS access to HOME directory,
> thus no access to .Xauthority, thus no access to display :3.1):
>
> [0] algorah:/tmp> cd /var/tmp
> [0] algorah:/var/tmp> emacs xscreen.out
> [3] 29863
> [0] algorah:/var/tmp> Xlib: connection to ":3.1" refused by server
> Xlib: Client is not authorized to connect to Server
> Display :3.1 unavailable, simulating -nw
>
> [3] + Suspended (tty output) emacs -i xscreen.out
> [0] algorah:/var/tmp> cd
> cd: Can't change to home directory.
> [1] algorah:/var/tmp> klist
> Ticket cache: FILE:/tmp/krb5cc_103
> Default principal: peter at IFM.LIU.SE
>
> Valid starting Expires Service principal
> 06/11/2008 12:33 06/11/2008 20:33 krbtgt/IFM.LIU.SE at IFM.LIU.SE
> renew until 11/11/2008 14:50
> 06/11/2008 07:09 06/11/2008 15:09 imap/ifm.liu.se at IFM.LIU.SE
> renew until 11/11/2008 14:50
> 06/11/2008 07:29 06/11/2008 15:09 nfs/andromeda.ifm.liu.se at IFM.LIU.SE
> renew until 11/11/2008 14:50
> 06/11/2008 10:06 06/11/2008 17:50 host/sculptor.ifm.liu.se at IFM.LIU.SE
> renew until 11/11/2008 14:50
> 06/11/2008 15:10 06/11/2008 20:33 nfs/andromeda.ifm.liu.se at IFM.LIU.SE
> renew until 11/11/2008 14:50
>
>
> I have a feeling that maybe ktkt_warnd isn't renewing the tickets as is
> should perhaps?
> It is enabled though...
>
> [0] algorah:/etc/krb5> svcs -a|egrep ktkt
> online Oct_28 svc:/network/security/ktkt_warn:default
You can quite easily verify if ktkt_warnd is renewing tickets for you by
requesting a TGT with a short lifetime and then waiting to see if it is
renewed.
Run "kinit -l 3m", "klist", then wait for at least 3 mins and run
"klist" again - you should see a renewed ticket available.
If ktkt_warnd fails to renew your ticket for some reason you should see
a message on your terminal. You can change this behaviour to log to
syslog which might be simpler to retrieve if you can't log in again.
-M
