I think we kind of lost the OP's problem.
John Austin wrote, On 07/14/2008 03:39 PM:
On Mon, 2008-07-14 at 08:06 -0430, Patrick O'Callaghan wrote:
On Mon, 2008-07-14 at 13:07 +0100, Anne Wilson wrote:
On Monday 14 July 2008 12:47:25 Tom Horsley wrote:
On Mon, 14 Jul 2008 11:21:28 +0200
David Jansen <jansen@xxxxxxxxxxxxxxxxxx> wrote:
Has anyone else seen this?
OP summary:[
/var/log/messages shows
kernel: dbus-daemon[22141]: segfault at 1c ip
7fa454a5f2e0 sp 7fff5ca79fa8 error 6 in dbus-daemon[7fa454a31000+4c000]
after gdm login of users on NFS.
]
I have noticed some kind of problem with logging in
via GDM when I use a user with an NFS home, but never
investigated exactly what the problem was because it
is usually only by accident that I try it.
Do you [or the OP] use soft mounts?
I have seen enormous problems, no matter which OS/version is acting as the
server, if the clients are soft mounting home with nfs, and it is worse if the
home directories are being automounted.
hard,intr solved most of the problems we had, and I make a practice of having
the home directory NFS mounted at boot (which I know is not an option for many
admins).
the reason I went to mounting the home directory at boot instead of auto
mounting, is that when gnome can't find one of it's config files it tries to
create the default set and I would see some strange results** from that, but I
never tried to separate the soft/auto mount problem, so it might have been
solved by hard,intr.
Could the OP's problem be that some part of gnome/kde/gdm/kdm is attempting to
have dbus look at something in the users home dir which is an auto/soft
mounted dir and either not finding the file or getting an IO error causes
dbus-daemon to seg fault? [if the answer is yes, then we have narrowed down
the problem, and an appropriate bug needs to be put in the system about dbus
as being a daemon it should never die with segfault.]
** strange results = gnome/netscape tried to create directories and got files.
I have no problem just getting a ssh shell for an NFS
user, but trying to do the full blown GUI session
login, something always seems to go wrong, and all or part
of the expected interface never comes up.
My solution is to avoid NFS like the plague - it always
seems to screw up if you try to write any data across
it. It can almost do reads reliably (except when it can't).
I can only agree with this comment if the client machines are soft mounting or
they are working in a network that is incredibly busy. soft mounts will cause
data loss in a busy network before hard mounts, but if you can ping flood -s
1400 the server and not get any loss, then hard,intr UDP NFS should be still
be _reasonably_ reliable (as NFS goes) and TCP NFS should be fine.
see the following thread entries
http://linux.kernel.org/pipermail/autofs/2004-April/001115.html
http://linux.kernel.org/pipermail/autofs/2004-April/001120.html
http://linux.kernel.org/pipermail/autofs/2004-April/001121.html
I've never tried using an nfs mount as my home directory, but I do have an nfs
mount to my remote /home in fstab. All important stuff is on there, so I
read and write files regularly. I've had no problems whatsoever with this.
For years I ran a lab of 30-50 workstations all mounting /home from a
couple of NFS servers. This was on several generations of NFS in the
original Sun versions, and though we did consider alternatives such as
AFS or even Coda from time to time, none of them ever looked like
realistic alternatives in our environment. IIRC the problems tended to
be much more with NIS (Yellow Pages) than NFS.
poc
I have been using NFS for many years for /home at least
as long ago as Redhat 9
Currently using
autofs, NIS, NFS for /home on F9 x86-64 and F8 i386 and x86-64
Often logged in on several different machines using the same account !
No problems
I just don't believe that NFS is the problem !!
BUT
I'm using kdm and not gdm
and NetworkManager is not involved !!
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
