[7701] in testers
Re: My Athena session will not run.
daemon@ATHENA.MIT.EDU (William Cattey)
Wed Sep 17 15:51:50 2008
In-Reply-To: <7AC85619-0285-474C-AC34-966B10310E81@mit.edu>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4A855825-CA55-4893-BAD5-E4997360ADC4@mit.edu>
Cc: testers@mit.edu, athena10@mit.edu
Content-Transfer-Encoding: 7bit
From: William Cattey <wdc@MIT.EDU>
Date: Wed, 17 Sep 2008 15:51:04 -0400
To: William Cattey <wdc@mit.edu>
Ok, this is bizarre.
Now I am able to log in just fine.
amb suggested that the problem was that the gconfd-wdc directory in /
tmp might have been owned by the old uid 1000 for the local wdc.
I did ls -n and determined that wasn't the case. The directory was
owned by uid 11306, my Athena uid.
I saved the contents of /tmp, removed them and tried again to log in.
no joy. Instant abort as always, and complaint that it couldn't read
my .xsession-errors file when I asked to see details.
I then changed my session to "GNOME Failsafe".
Interestingly it logged me in just fine, asking me if I wanted to set
"alps_modmap".
I have no .startup.X file.
However, moving it aside a couple times, I have a .startup.X~ and
a .startup.X.foo file
both of which refer to alps_modmap.
Is it possible that our bash-based Athena default X session is being
too aggressive looking
for any file beginning with ".startup.X" instead of an exact match?
Probably not, since NOTHING else like setting a variable "hostname"
seems to have been executed.
Anyway, I told it, no I didn't want to run alps_modmap, and it gave
me a perfectly normal looking session.
I then logged out, change the login session to "GNOME" and logged
back in.
I was asked if I wanted to keep session "GNOME" for this one trial or
for all time,
and i selected for all time.
It then logged me in just fine.
----
How do we figure out what happened here so that it doesn't happen to
others?
How did the Ubuntu sesssion decide to care about my alps_modmap script?
Shouldn't all the gnome and session directories created in /tmp be
removed on logout anyway? They were not. Present in /tmp after I
logged out were:
Directories: gconfd-wdc, orbit-wdc, pulse-wdc, virtual-wdc.nDwIAZ
File: xses-wdc.VlQT6x
If there's something that gets messed up in one of these directories,
it will break the ability to log in, won't it?
-wdc
On Sep 16, 2008, at 6:01 PM, William Cattey wrote:
> In another thread we're working on debugging the account deletion
> procedure.
> Meanwhile I'm trying to log in on the athena10 system.
>
> I did userdel wdc and that enabled the Athena login screen to try
> and pull from
> my Athena account.
>
> When I log in, it gives me the error that my session ran for less
> than 10 seconds.
> When I click on show details it says, "/mit/wdc/.xsession-errors
> could not be opened."
>
> From another system, my .xsession-errors file does exist. It says:
>
> hanta-yo:~ wdc$ cat /mit/wdc/.xsession-errors
> /etc/gdm/Xsession: Beginning session setup...
> Setting IM through im-switch for locale=en_US.
> Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/
> xinit/xinput.d/default.
> set: Variable name must begin with a letter.
>
> ----
>
> When I do a GNOME failsafe login I get a FLURRY of alerts:
>
> An error occurred while loading or saving configuration information
> for evolution-alarm-notify. Some of your configuration settings
> may not work properly.
> Details: Failed to contact configuration server <explanation>
> Details -1 IOR file /tmp/gconfd-wdc/lock/ior couldn ot be opened
> successfully. no gconfd located: permission denied.
> (Details repeat several times.)
>
> Similar alert for Nautilus, gnome-panel
>
> GConf Error (repeat of evolution-alarm-notify error).
>
> ----
>
> I thought that might be due to our not having done the gconf work.
> After all I am logged in elsewhere. So I logged out of the other
> Athena system, but that made no difference.
>
> The fail safe Gnome session gives me no panel. I had to log out by
> creating a xterm launcher, and then su to root, and then killing X.
>
> ----
>
> A failsafe terminal session will let me in at all, and I can
> examine the contents of my AFS home directory, and run commands.
>
> Issuing the "logout" command complains that the login shell is not
> my login shell.
> (This is a simple bug easily fixed, I believe.) I AM able to
> logout by issuing the "exit" command.
>
>
> -Bill
>
> ----
> Important: IS&T IT staff will *NEVER* ask you for your password,
> nor will MIT send you email requesting your password information.
> Please continue to ignore any email messages that claim to require
> you to provide such information.
> ----
>
> William Cattey
> Linux Platform Coordinator
> MIT Information Services & Technology
>
> N42-040M, 617-253-0140, wdc@mit.edu
> http://web.mit.edu/wdc/www/
>
>
>
