Hi all,
Still haven't been able to solve the F9 locking problem (email below),
part of the delay being that I don't know what exactly triggers it (so
can't easily test it, and have to wait some time (~ 1 day) before it
falls into this lock-able state...).
But, in case it's of any help to anyone who's seen anything like this
or has any thoughts about it, I notice that the problem seems to arise
sometime after the ~ 4 AM cron tasks (cron.hourly, daily, etc.).
Here's what's in the hourly and daily (i.e., minimally at the frequency
of occurrence of this problem):
cron.daily
cron.daily/mlocate.cron
cron.daily/0anacron
cron.daily/readahead.cron
cron.daily/makewhatis.cron
cron.daily/cups
cron.daily/certwatch
cron.daily/texlive.cron
cron.daily/logrotate
cron.daily/0logwatch
cron.daily/prelink
cron.daily/000-delay.cron
cron.daily/00webalizer
cron.daily/tmpwatch
cron.daily/rpm
cron.deny
cron.hourly
cron.hourly/drupal
cron.hourly/mcelog.cron
(Much of this is unnecessary (like drupal) for
most of the workstations, but my approach in constructing a kickstart
for these has been to create rather fat clients and then trim down to
get the final kickstart config...)
Also, I just reproduced the problem for today:
1) Actively logged-in to a GNOME session as root
2) Navigate to the menu bar -> logout
3) Screen freezes black, with the mouse pointer still active (and the
blue elliptical "actively working" graphic circulating about the
pointer)
Remotely log-in to the frozen machine via ssh, see the dbus-related
zombie:
[root@struc12 etc]# ps waux |grep Z
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
gdm 28654 0.0 0.0 0 0 ? Zs 10:30 0:00
[dbus-launch] <defunct>
It seems to be a gdm thing, as I can switch to a terminal -- for
example, ctrl-alt-F6 works.
...only remedy is to re-boot.
Any thoughts, advice, or tips on how to go about troubleshooting this
would be greatly appreciated.
With best regards,
Cameron
=== Cameron Mura wrote (on 08/10/2008 03:05 PM): ===
Hello,
I'm experiencing a problem on both F8 and F9 (mostly playing on F9 now)
that I can't seem to get to the bottom of: In several different
instances of vanilla installations of both F8 and F9 on Dell
workstations (Precision 490, T3400, etc.), I find that the machine
works fine for about 1 day, then -- the next day -- hangs at a black
screen when a user tries to login. This is with both i386 and x86_64
installs.
Gnome is the default disp. manager, and if I remotely access the
machine (ssh as root) while it's in this frozen state, I see that
dbus-launch (user 'gdm') has fallen into a zombie state. Re-booting
solves the problem, but then it arises again the next day. I should
mention that the regular (non-root) user accounts are set-up via
NIS/NFS. (I ran across some things online regarding problems with
pulseaudio and nfs users, but this doesn't seem to be it.). Other
suspicious behavior that seems to (maybe) be correlated is that
launching into a bash shell (for, say, a tcsh-based user) results in a
stream of infinite /dev/null errors (don't have the exact output string
in front of me, but can provide that later if helpful)... This can be
interrupted (ctrl-c) to yield the shell. Further inspection shows that
the perms on /dev/null are only rw for root (not 0666 or whatever they
ought to be...?). I don't know if these two things (1: login screen
locking/zombie process 2: screwy /dev/null perms) are related.
I'm wondering if anyone's seen anything like this, or might have some
idea as to what's causing it? If so, please let me know, or feel free
to redirect me to any info about this online (I've spent many hours
google'ing for it, tweaking config files, applying different sets of
updates, etc...).
Thanks for any help,
Cameron
PS. This is also at
http://forums.fedoraforum.org/showthread.php?p=1061369 . Any help /
tips / advice would be most gratefully appreciated.
--
Cameron Mura
|
