Bug 15188 – kdm (kdm_greet) takes very long time with USE=xft - KDE 3.1

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Grant McDorman 2003-02-05 17:10:25 UTC]

See also bug #10947; the description in there is different, however, and may be
referring to an unrelated problem with KDE 3.0.5; it is not clear from the
description therein.

On a 1.8 GHz P4, the time from the gray stippled X screen to the appearance of
the  login window (kdm_greet) is approximately a minute. In addition,
directories with names consisting of 10-digit random strings of digits are
created in /tmp on each run and never cleaned up.

Investigation with strace revealed that kdm_greet was enumerating all of the X
fonts on the system on each startup. Further inspection revealed the following
code in kdm_greet.c:

    /* for QSettings */
    srand( time( 0 ) );
    for (i = 0; i < 10000; i++) {
	sprintf( qtrc, "/tmp/%010d", rand() );
	if (!mkdir( qtrc, 0700 ))
	    goto okay;
    }
    LogPanic( "Cannot create $HOME\n" );
  okay:
    if (setenv( "HOME", qtrc, 1 ))
	LogPanic( "Cannot set $HOME\n" );

This code is creating a fake $HOME in /tmp with the described name each time
kdm_greet is run. However, when Xft2 is active, it looks for a font cache in
$HOME, and if not found scans all the fonts; in kdm_greet, of course, the cache
is never there.

As a temporary workaround, I replaced the above code with
  strcpy(qtrc, "/home/xdm");
(and of course created the above directory). The startup time went from 60
seconds to 2 to 3 seconds once Xft had created its cache file.

The above code exists as quoted in the current KDE CVS
(http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdm/kfrontend/kdm_greet.c) at
line 649 and following. I have not determined if this problem exists in versions
prior to 3.1.

I would suggest that kdm_greet have a configuration item for the configuration
files; it may be desirable to create subdirectories within there using the value
of $DISPLAY.

[Comment 1 Artur Brodowski 2003-02-06 07:27:59 UTC]

this might be the same issue as in bug #15161, just as i suspected this 
is xft related problem (slowdown happens also to gnome/gdm). does 
anyone know what should one do to fix gnome startup?
regards,
artb.

[Comment 2 Seemant Kulleen (RETIRED) 2003-02-06 17:33:18 UTC]

*** Bug 15161 has been marked as a duplicate of this bug. ***

[Comment 3 Dan Armak (RETIRED) 2003-02-09 13:58:35 UTC]

OK. I've talked to ossi, the kdm maintainer, and he'll imlpement a fix upsteam and drop us a  
note to put a patch in our ebuilds. We'll have a static cache file in e.g. /var/cache/kdm and  
when kdm creates its temp HOME dir, it'll create a link there to that cache file.  
  
ossi says that beacuse of some braindamage in qt, the temporary dirs with their random  
names are necessary and cannot be replaced with say a static dir whose contents are  
removed between runs.  
  
gdm btw handles this by setting HOME to point to a static dir since (/var/lib/gdm) since it  
doesn't have that qt issue to deal with. 

[Comment 4 SpanKY 2003-02-23 04:29:33 UTC]

*** Bug 16212 has been marked as a duplicate of this bug. ***

[Comment 5 Joshua 2003-04-24 13:54:29 UTC]

This is to confirm that I and a friend have the same problem. Things are fine when 
using xdm with kde. But as soon as I change DISPLAYMANAGER to kdm it takes a 
couple of minutes to get the login box. 

[Comment 6 Paul de Vrieze (RETIRED) 2003-04-24 14:53:57 UTC]

*** Bug 19349 has been marked as a duplicate of this bug. ***

[Comment 7 Caleb Tennis (RETIRED) 2003-06-13 13:41:36 UTC]

Anyone know if this is still a problem with more recent kde versions?  Should we get a patch 
into our system somewhere? 

[Comment 8 Paul de Vrieze (RETIRED) 2003-07-25 13:38:42 UTC]

Try running fc-cache -f -v as root

[Comment 9 Caleb Tennis (RETIRED) 2003-10-02 07:58:59 UTC]

resolving as patches have been applied upstream