Bug 242494 - kdmrc: FaceSource=PreferUser, potentially takes a long time
kdmrc: FaceSource=PreferUser, potentially takes a long time
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kde-settings (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-04 11:17 EDT by Tomasz Kepczynski
Modified: 2017-01-27 10:35 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:25:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomasz Kepczynski 2007-06-04 11:17:35 EDT
Description of problem:
Default kdm configuration has:
UserList=true
On my system, which is located on a network with over 700 accounts
in NIS kdm needs over 6 minutes to show login screen. This is
probably related to a fact that it tries to get users' faces from
NFS homes.
GDM on the same PC needs only a few seconds, KDM with UserList=false
also needs only a few seconds.
This is "just installed from scratch" system.

Version-Release number of selected component (if applicable):
kdebase-3.5.6-12.fc7

How reproducible:
always
 
Actual results:
Login screen appers after 6 minutes.

Expected results:
Login screen apperas just after boot is finished.

Additional info:
Default configuration should be changed so that networked systems
with lots of users respond in timely maner.
Comment 1 Kevin Kofler 2007-06-04 16:03:03 EDT
GDM also defaults to showing user lists now, doesn't it do so for you? Or does 
it do it faster?

If GDM is no faster, then sorry, this is NOTABUG, it is an intentional change. 
Unfortunately, one can't please everyone. User lists aim at making the login 
experience nicer for desktop users. Those are typically systems with few users, 
usually all local, not hundreds of NIS accounts. The Fedora desktop team 
decided to default to user lists, and the artwork designer designed the default 
theme around it (with a black space explicitly reserved for a user list), so we 
(the Fedora KDE Special Interest Group) decided to match this default in KDM. I 
agree that user lists make no sense whatsoever in your setup, but that's why it 
can be turned off. (You may also want to change the KDM theme to FedoraDNA so 
you don't have that black space where the user list is supposed to be.)

If on the other hand GDM _is_ faster at displaying long userlists, then the 
real bug is the slowness, which is a KDM, KDE or Qt bug (KDM bug if it's the 
retrieving of user images which is too slow, KDE or Qt bug if it's the 
displaying in the list widget), not a configuration issue.
Comment 2 Tomasz Kepczynski 2007-06-04 16:16:19 EDT
GDM shows user list, and as I wrote it - it does it faster
(time to show login screen is measured in seconds while KDM
needs minutes). GDM was configured as in stock - I haven't
touched it (I even don't know where it keeps all its config
files, I just refuse to use gnome).
I guess the difference might be in user faces - I am quite
sure KDM is configured to look for photos in home directories
which are located on NFS share. I don't know what GDM does.
It might not display photos, it may only look for photos
for users which will be shown in a window and KDM might look
for all of them.
For your notes about configuration change and defaults - I
understand but I think it might justify inclusion in Release Notes.
I was quite sure that I've hit a bug in KDM (it just showed
black screen, I needed to go somewhere else and when I came back
I saw that it works).
Comment 3 Kevin Kofler 2007-06-04 16:19:09 EDT
Where KDM looks for user faces depends on the FaceSource setting, if it's set 
to AdminOnly, it will only look in the system-wide directory, not in user home 
directories.
Comment 4 Tomasz Kepczynski 2007-06-04 16:22:45 EDT
I found that and I am quite sure it defaults to home first and
admin second. Now the question is what is the default for GDM?
Comment 5 Tomasz Kepczynski 2007-06-05 03:45:24 EDT
I've checked that:
- GDM takes faces from local filesystem (and probably
  does not support home directories at all)
- KDM by default queries home directories
- KDM performance is comparable to GDM's when
  FaceSource=AdminOnly.

So the real culprit is NFS filesystem and/or automounter.
I would reconsider default setting for KDM to direct it to
home directories for faces or at least I would write about
performance penalty in Relese Notes.
Comment 6 Kevin Kofler 2007-06-05 07:46:42 EDT
The idea behind defaulting to PreferUser was that the user should be able to 
set his/her own image, however we weren't aware that this doesn't scale 
performance-wise when this was discussed.

But as far as I know, GDM _is_ supposed to support faces in home directories 
too. I haven't looked at its code though, so maybe it has explicit heuristics 
to exclude network-mounted directories.
Comment 7 Tomasz Kepczynski 2007-06-05 09:23:33 EDT
As I wrote - I don't know for sure what GDM does (it looks to me
like it does not use home directories for faces but I may be
terribly wrong here).
As for KDM my guess is that it tries to get _ALL_ users' faces before
showing login screen and this causes long wait. There are two
possible solutions if this is a problem:
- show login screen and continue looking for faces and filling
  list after that;
- look only for faces which are to be displayed on screen (I would
  prefer this one).
Comment 8 Rex Dieter 2007-10-18 09:59:36 EDT
Tomasz, your suggestions are good, but that's for upstream, not something we can
implement here.

Our only option is to consider turning off searching of users' homedirs for face
icons.

For now, I'm inclined to leave things as-is, and make mention of this potential
issue via Release Notes (per comment #5)
Comment 9 Tomasz Kepczynski 2007-10-19 00:49:32 EDT
That's also the way to deal with it - let others know, so they
don't waiste time trying to deal with this problem.
As I don't know the way KDE deals with problems - are they aware
and if not - could you file a bug for them?
Comment 10 Bug Zapper 2008-05-14 08:47:03 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Kevin Kofler 2008-05-14 11:45:42 EDT
I think this affects at least F8 too (maybe also F9), bumping version unless 
proven wrong.
Comment 12 Tomasz Kepczynski 2008-05-14 15:41:57 EDT
I've seen this very recently and I am quite sure that was on Fedora 8.
Comment 13 Bug Zapper 2008-11-26 02:17:14 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Rex Dieter 2008-11-26 10:36:15 EST
Further kde-sig discussion ongoing, I'll rebase this to rawhide for now.

I'm still inclined to leave things as is, and document it, per comment #8
Comment 15 Charlie Wyse 2009-03-12 20:19:36 EDT
Hrm, still seeing this in Fedora 10.  As far as I know, after 2.22 gdm got rid of gdmsetup and really any kind of useful customization, which is probably why more and more people are switching to kdm.  Regardless, gdm does not search home directories for faces, rather /usr/share/pixmap/faces for <username>.png, or so say the documents from gnome.org.  Anyone can resolve the issue with the AdminOnly option in kdmrc, I'm sure there are craftier ways.  But this is just how KDM runs as far as I know.  Which is great for personal systems but a total fail for larger environments.  I would recommend to the all mighty KDM upstream maintainers to possibly set the default to AdminOnly or set a default faces directory similar to GDM so that users have to actually enable the face files in there home directories.  That way they will notice that things only break when it's enabled and will hopefully spend less time troubleshooting.  Putting this warning in release notes is also good, per comment #8 :)
Comment 16 Tomasz Kepczynski 2009-03-13 02:16:15 EDT
I would bet that not looking for all photos but only for that needed currently for display would make HUGE difference. And then probably no changes to defaults are needed.
Comment 17 Kevin Kofler 2009-03-13 03:04:27 EDT
That would probably need KDM to get ported from QListWidget to the model-view-controller QListView.
Comment 18 Charlie Wyse 2009-03-13 14:57:44 EDT
Actually when I was creating a fix patch for our enterprise deployment I realized something.  This issue is probably in the fedora package itself and can very easily be fixed.  Here is the current section in the kdmrc file that is causing the problem.

# Allow users to set their own user images.
# If UserList is enabled, this specifies where kdm gets the images from:
# AdminOnly (default): from <FaceDir>/$USER.face[.icon]
# UserOnly: from the user's $HOME/.face[.icon]
# PreferAdmin: prefer <FaceDir>, fallback on $HOME
# PreferUser: ... and the other way round
FaceSource=PreferUser

As you can see AdminOnly is the default.  So if we just put a comment in front of FaceSource=PreferUser (#FaceSource=PreferUser), it defaults to AdminOnly and works for large NFS home dir based deployments.  In other words, the fedora package is not sticking with the defaults but forcing this on the user.  We should probably change this back to a commented variable so everything works at an enterprise level by default, especially if this package is going to wind up in RHEL.

Oh a comment #16 makes a lot of sense to, but is something the KDM upstream maintainers would probably need to code in.  In other words, won't be fixed in the immediate future.  Making the "#" change to the fedora package would at least stop people from running into this and make KDM a sexier option.
Comment 19 Kevin Kofler 2009-03-13 15:07:44 EDT
We know AdminOnly is the upstream default. The problem is that this prevents users from setting their own image, so it's definitely not the ideal solution. And it especially breaks things for those least likely to be able to fix it (home/family installations), whereas setting it to AdminOnly shouldn't be hard for a sysadmin of an enterprise deployment.
Comment 20 Bug Zapper 2009-06-09 05:14:48 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 Bug Zapper 2010-04-27 07:43:22 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Bug Zapper 2010-06-28 06:25:09 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 23 Rex Dieter 2017-01-27 10:35:14 EST
clearing release note flag for old bug

Note You need to log in before you can comment on or make changes to this bug.