RH 7.2 GNOME issue.

[Reply] [View by Thread] [Help]
[Back To Operating System Issues]

LtKer ins0mni0n

Hi all. This is gonna be a fun one; are you ready?

In running a test of some disaster recovery software, it looks like some things got b0rked in the recovery, but I can't tell which. The main issue is that the Default session for gdm is whacked out for root (yes, we are at runlevel 5, don't ask me why)... essentially what happens is, gdmlogin passes through, starts up gnome-session and gnome-smproxy, then sawfish.... then hangs. This behavior only affects root login, and not any of the users. comparing $HOME/.gnome/session between my regular user and root, here's what i have:

ins0m:
keyboard-properties
background-properties-capplet
screensaver-properties-capplet
sound-properties
mouse-properties-capplet
gnome-smproxy
sawfish
magicdev
panel
nautilus

root:
gnome-smproxy
sawfish

It would seem that some essential things are missing; however, most of those calls in my session file pass along a --sm-client-id flag with values that I have no clue how to find for root, should I decide to recreate root's session file from mine. Is there a way of finding those client id's, or am I just gonna have to shoot blindly on this one?

The other thing I encountered was that logging in on Failsafe worked; when I then ran gnome-session from the prompt, I was greeted with some nasty msg's on stderr from xscreensaver being initialized (which would make sense, the hang on Default login occurs right after sawfish loads and xscreensaver is supposed to be the next process fired up)... setuid to root, plus being root already, can be a bit of a mess security-wise... again, this isn't my call, but my boss's (he is picky about havin to use su whenever he wants admin, apparently). I would think this might be a problem, but since it was working fine pre-archive recovery, I'm more inclined to some form of file corruption.

I could just lay down the hard line with him to log in as himself and su when needed, but I'm taking this as a proof-of-concept exercise in case it should happen on another recovery to a regular user account. Anyone have any ideas, or am I totally off in left field on my assumptions thus far? Thanks.

There are no replies to this post yet.

Guest:
Subject:
Message:	On 2003-03-14 18:18:29, ins0mni0n wrote >Hi all. This is gonna be a fun one; are you ready? > >In running a test of some disaster recovery software, it looks like some things got b0rked in the recovery, but I can't tell which. The main issue is that the Default session for gdm is whacked out for root (yes, we are at runlevel 5, don't ask me why)... essentially what happens is, gdmlogin passes through, starts up gnome-session and gnome-smproxy, then sawfish.... then hangs. This behavior only affects root login, and not any of the users. comparing $HOME/.gnome/session between my regular user and root, here's what i have: > >ins0m: >keyboard-properties >background-properties-capplet >screensaver-properties-capplet >sound-properties >mouse-properties-capplet >gnome-smproxy >sawfish >magicdev >panel >nautilus > >root: >gnome-smproxy >sawfish > > >It would seem that some essential things are missing; however, most of those calls in my session file pass along a --sm-client-id flag with values that I have no clue how to find for root, should I decide to recreate root's session file from mine. Is there a way of finding those client id's, or am I just gonna have to shoot blindly on this one? > >The other thing I encountered was that logging in on Failsafe worked; when I then ran gnome-session from the prompt, I was greeted with some nasty msg's on stderr from xscreensaver being initialized (which would make sense, the hang on Default login occurs right after sawfish loads and xscreensaver is supposed to be the next process fired up)... setuid to root, plus being root already, can be a bit of a mess security-wise... again, this isn't my call, but my boss's (he is picky about havin to use su whenever he wants admin, apparently). I would think this might be a problem, but since it was working fine pre-archive recovery, I'm more inclined to some form of file corruption. > >I could just lay down the hard line with him to log in as himself and su when needed, but I'm taking this as a proof-of-concept exercise in case it should happen on another recovery to a regular user account. Anyone have any ideas, or am I totally off in left field on my assumptions thus far? Thanks.
Signature:
Optional Image Link:
http://

CyberArmy::Forum v0.6
Generated In 0.02271 seconds