https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c1 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Component|X.Org |Other AssignedTo|bnc-team-xorg-bugs@forge.pr |bnc-team-screening@forge.pr |ovo.novell.com |ovo.novell.com QAContact|xorg-maintainer-bugs@forge. |qa@suse.de |provo.novell.com | --- Comment #1 from Stefan Dirsch 2012-01-10 23:08:06 UTC --- Not sure, whethe this issue is related to X at all. Therefore reassigning to Other component for now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c3 Klaus Slott changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |Network --- Comment #3 from Klaus Slott 2012-02-12 21:28:27 UTC --- Bug 740620 (and maybee 743969) is most likely the same problem. System locks up and cant even shut down. This is valid even if NFS is soft mounted. I agree with Stefan that this is not related to X and note that a patch to nfs-utils is suggested (see link to Debian bug above). Therefore reassigning to network as I guess that is where nfs belongs? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c5 Jan Engelhardt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED CC| |jengelh@medozas.de Component|Network |KDE4 Workspace Resolution|NORESPONSE | AssignedTo|bnc-team-screening@forge.pr |kde-maintainers@suse.de |ovo.novell.com | --- Comment #5 from Jan Engelhardt 2012-03-10 08:33:56 UTC --- (Revert bogus close.) Certain display managers/login screens attempt to read /home/user/.dmrc. That fails in your case. Normally that is not an issue, so do you see anything else on the server side regarding file accesses? Is it perhaps attempting to look at all users and this just taking time? If a console login is all fine, time to blame the DM :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c7 Jan Engelhardt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Component|KDE4 Workspace |Kernel Resolution| |DUPLICATE AssignedTo|kde-maintainers@suse.de |kernel-maintainers@forge.pr | |ovo.novell.com --- Comment #7 from Jan Engelhardt 2012-03-11 13:13:08 UTC --- The Debian link most certainly is worth something. *** This bug has been marked as a duplicate of bug 705470 *** http://bugzilla.novell.com/show_bug.cgi?id=705470 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c9 --- Comment #9 from Klaus Slott 2012-05-08 05:48:10 UTC --- Using xdm will only partially solve the problem. The underlaying problem is still that ANY attempt to access a nfs share depending on a expired ticket will block the tread - and any subsequent nfs access. Removing expired ticket might help (have not tried) but in my case I also have to deal with users leaving a session open. I have build a test version including the Debian patch described above and this does indeed solve the login problem. But nfs performance still sucks when the system is under pressure. http://download.opensuse.org/repositories/home:/Mr_Manor:/branches:/openSUSE... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c11 Joschi Brauchle changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joschibrauchle@gmx.de --- Comment #11 from Joschi Brauchle 2012-05-08 08:46:28 UTC --- Hello Klaus, I strongly disagree that patching gssd is the correct solution! What the patch does is report an EACCESS error, once the ticket expires. This is not correct behavior in my opinion! The NFS mount should "hang" when the KRB ticket is expires, cecause it gives the user the ability to resume all it's processes, once he acquires a *new* ticket. What you should look at, is *not* to patch gssd, but rather change the display managers configuration, such that is places its user ".dmrc" file outside the user's home. Because your login problems relates from the DM trying to read the /home/<username>/.dmrc file, once you click on it's name in the login window. As the read access to the user home is not available before the user acquires a KRB ticket, this ".dmrc" file must be places elsewhere. There is a directive "DmrcDir=<dir>" for KDM in it's config file "/usr/share/kde4/config/kdm/kdmrc". In our configuration, we placed these files on a NON-KRB-secured NFS share, such that the DM can read without a ticket! So make it short: Yes, patching gssd fixes the problem, BUT changes kerberized NFS behaviour (in a bad way -- my opinion). Instead, one should change the DM configuration to prevent accessing the user home before the user acquires a ticket! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c13 --- Comment #13 from Klaus Slott 2012-05-08 09:10:33 UTC --- (In reply to comment #11)

So make it short: Yes, patching gssd fixes the problem, BUT changes kerberized NFS behaviour (in a bad way -- my opinion). Instead, one should change the DM configuration to prevent accessing the user home before the user acquires a ticket!

Well I might agree with your opinion, if the NFS blocking only hit the task trying to access the users home drive. But that is not so. When a a ticket expires then all NFS access hangs hitting every user on the affected workstation. Other users have no way of escaping as they are not able to issue a new ticket for the user blocking NFS. This might be related to the performance problem I also see. I suspect that NFS+kerberos access is single treaded. But I have not yet found time to investigate further into this. On top of that there are other programs which may try to look in the a users home during login. As an example ssh tries to access .ssh/authorized key and is blocked to. This effectively disables ssh login completely. So patching gssd might not be the correct solution, but replacing KDM is only fixing a small part of the problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c15 --- Comment #15 from Joschi Brauchle 2012-05-08 12:31:53 UTC --- Hello Klaus, I completely agree with you, that this problem is bad, because it affects all Nfs users on the machine, not only the user with the expired ticket! My point comes from what I read on some NFS mailling list: returning EACCESS in the situation of an expired ticket is a BIG change in the behavior of kerberized NFS. As long as there is a switch to turn this on or off (as there is in your patch), then that is ok! But personally, I think that there must be a different problem deep inside the gssd, that causes the blockage for all users! I would like to see someone investigate deeper and see if the workflow inside gssd can be adapted, such that the problem is fixed + the current behavior is kept the same. Because currently, one has to either A) live with the problem, if you want to stick with the current behavior, or B) accept the change in behavior of kerberized NFS if you want to fix the problem. The current patch only fixes the problem if you are willing to accept that change. If not, the problem is still there! Hence, I think the bug is not "resolved" at all, rather it's "circumvented" for some users. By the way, i would be happy to help debug the problem... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

I think that there must be a different problem deep inside the gssd, that causes the blockage for all users! Amen. As mentioned above I have a suspicion that all NFS access is serialized somewhere in the client. In my setup (using the Debian patch) I see severe

https://bugzilla.novell.com/show_bug.cgi?id=740620 https://bugzilla.novell.com/show_bug.cgi?id=740620#c17 --- Comment #17 from Klaus Slott 2012-05-08 13:07:30 UTC --- (In reply to comment #15) performance issues when some program generates a lot of NFS traffic, in effect taking the workstation several minutes to react to something like ls command. Unfortunately I'am not a programmer myself, I merely took the Debian patch and verified that it looked plausible - and applied it. I really hope someone more skilled would look into this! (should we reopen this, make a new, or settle for 705470?) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.