[PlanetCCRMA] Pam, Perms, a plan?

[Fernando Pablo Lopez-Lezcano]

On Tue, 2004-10-12 at 21:20, Matt Barber wrote:
> Relatively low-level question/bug here.  We have a set of problems that
> seems to involve the same process, but I'm not sure what it is:
> 
> 
> Right now we're not quite on the edge - we're currently using
> 2.6.7-1.437.1.ll.rhfc2.ccrmasmp, since cd burning generally hardlocks
> our machine (dual-opteron, 32-bit fedora2) in the kernels after this one
> (haven't tried the newest planetedge).  Sometimes when a user logs out
> of Gnome, X sort of freezes.  It's not a hard freeze - you can move the
> mouse cursor around, and click on things, but clicking does nothing. 
> Right-clicking still opens up a menu.  It doesn't matter whether or not
> there are running windows or processes - sometimes it happens and
> sometimes it doesn't, and I can't find a way to reproduce the behavior
> consistently.  We're using an nvidia video card, and I thought that
> maybe the nvidia module was doing this, but it seems to be happening
> with the xorg nv module.  When this happens, we have to
> ctrl-alt-backspace to finish the logout and get back to the greeter. 
> Most of the time when this happens (not every time, as far as I can
> tell), gdm does not relinquish device ownership.  /var/run/console.lock
> remains the same, and a file for the user in /var/run/console/ remains. 

Yes, I have seen this happening every once in a while. Very annoying as
Matt said. 

> An ssh login and running who shows the user still logged into :0, and
> they still have ownership of /dev/console, and all of the console.perms
> devices that get chowned to the owner.  Then, curiously, when someone
> else logs in, pam_console.so does not give device ownership to the new
> user.  Temporarily we changed console.perms to have write permissions to
> important devices for our audio group, but this is a little too open
> maybe.  As far as I know we are not running selinux
> (/etc/sysconfig/selinux shows it as disabled).  

selinux is disabled and this happens to me in rh9, so it is not fc2
specific either. 

> I can't get xorg.conf to keep the 'Load "dri" ' line to stay out, either. 

This one is news to me. Strange. 

> Every time I take it
> out or comment it out, something puts that line back in, and then I get
> some errors in /var/log/gdm/\:0.log about dri not working right (as far
> as I understand, you wnat to get rid of the dri stuff when using the
> nvidia modules).  

That something is (probably) kudzu, the automatic hardware detection
system. But it does sound strange. You could try disabling kudzu
temporarily to see if it is the culprit (/sbin/chkconfig --del kudzu).

> Another annoying problem:  most of the time, unless
> gnome-terminal logins to pts/* are specifically exited with "exit," they
> persist as long as the computer is running - according to "who" anyway. 

I have also seen this...

> I remember once that `who` saw a week-old gnome-terminal login.  So I'm
> wondering where to start troubleshooting. 

For the gdm problem, if you can get it to repeat (it never happens to
me, always to somebody else :-), I would switch to a text console
(ctr-alt-1, for example), login as root and list all existing processes
at this point (and save the list to a file). And compare that with what
that user normally has when logged in. Just to see if it is possible to
see what process is hanging during the logout sequence. See /etc/X11/gdm
and the Session, PreSession and PostSession scripts there. 

> I don't know the sequence of
> events for a gdm login/logout, how much xdm is involved (if at all),
> etc. 

I think xdm is not involved at all, gdm replaces it. I used to know the
sequence but I have forgotten... there's a meeting I have to go to,
maybe latter I'll dig up what happens in the login/logout sequence. 

> Often pam_console_apply is kaput as well - it won't reset
> ownership on some of the things it should.  I don't know how
> pam_console.so runs, and whether it runs a discrete chown process or
> handles all of that in its binary process.  I notice a difference in
> gdm.conf from my RH9 gdm.conf at home:  at home the "KillInitClients" is
> on, and on the FC2 machine it is off.  I'm not quite sure what it does,
> or if it's involved, but I thought I'd ask.
> 
> Any ideas?  Sorry for the density of the post.

That's fine. Maybe we can get to the bottom of this. I've never had time
to properly debug this. 

-- Fernando