By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 690

Summary:	kdm_greet uses too much CPU
Product:	TDE	Reporter:	Timothy Pearson <kb9vqf>
Component:	tdebase	Assignee:	Timothy Pearson <kb9vqf>
Status:	RESOLVED FIXED
Severity:	blocker	CC:	bugwatch, kb9vqf, russell, slavek.banko
Priority:	P5
Version:	R14.0.0 [Trinity]
Hardware:	All
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:
Attachments:	Second fix kdm_greet high CPU usage Add option useKDMCTL to kdmrc.

Description Timothy Pearson 2011-11-25 20:06:02 CST

kdm_greet uses too much CPU when idling waiting for login.

Comment 1 Timothy Pearson 2012-01-17 21:21:44 CST

Fixed in GIT hash 1e2983a.

Comment 2 Slávek Banko 2012-02-27 08:56:54 CST

Several users report that they are the problem persists. Added usleep is clearly not a reliable solution.

On one computer patch help initially, but after a while - and after restarting KDM - CPU climbed again to 100%. I therefore conclude that it is not dependent on hardware.

Comment 3 Slávek Banko 2012-02-27 20:21:11 CST

I was strange that on the same machine in some cases KDM consumes CPU at 100% and in some cases it was at rest. So I researched again and I have one observation.

KDM creates a socket in /tmp/ksocket-global/kdm and then listens to it. KDM to correctly create the folder /tmp/ksocket-global/kdm. But there does not check the /tmp/ksocket-global as such. That probably makes only "tsak". But when do it late or not at all (when disabled SAK) and the folder /tmp/ksocket-global does not exist, then KDM will not create its socket and consumes the CPU to 100%.

Comment 4 Slávek Banko 2012-02-29 16:50:48 CST

Created attachment 447 [details]
Second fix kdm_greet high CPU usage

Comment 5 Timothy Pearson 2012-03-03 15:09:42 CST

There are two places in v3.5.13 that are affected by this bug, one in sakdlg.cc and one in kgreeter.cpp.  The kgreeter.cpp bug was partially fixed earlier in GIT, whereas the sakdlg.cpp bug has not been touched at all.

There is a second problem that you seem to have fixed, and that is the possibility of missing FIFO parent directories.  This is not related to the CPU usage bug, but should be committed to both files anyway.

I'll get these fixes into GIT ASAP.

Comment 6 Timothy Pearson 2012-03-03 15:27:35 CST

Fixed in GIT hash 5486d8e.

Thanks for reporting, and for finding the other location of the bug!

Comment 7 Slávek Banko 2012-03-03 18:11:20 CST

I would point out that the correction for the second problem (missing FIFO parent folder) also directly related to CPU load. If the folder is missing and so will not create the FIFO, it also leads to the CPU load.

Comment 8 Russell Brown 2013-01-25 06:28:40 CST

The loop reading input from the kdmctl FIFO still burns CPU.  Not a problem on a single machine/single desktop but significant for multi-user environments.

The attached patch allows admins to turn off the reading of the kdmctl FIFO and avoid the excess CPU cycles by setting useKDMCTL to false in kdmrc.

This does have the side effect of disabling kdmctl altogether but for me the tradeoff is fine (never used kdmctl!).

Comment 9 Russell Brown 2013-01-25 06:30:11 CST

Created attachment 1086 [details]
Add option useKDMCTL to kdmrc.

Patch to add useKDMCTL option.

Comment 10 Timothy Pearson 2013-04-06 16:59:24 CDT

The issues in TDM should be resolved in GIT hash aa0b92c via a major rework of the control socket system.  However, I would like to leave this bug open for now because kdesktop_lock likely suffers from the same problem.

Comment 11 Timothy Pearson 2013-04-06 20:50:01 CDT

kdesktop_lock fixed in GIT hash dc41de9; CPU of both tdm and kdesktop_lock is less than 2% in idle (waiting) states on my slowest test box.

Comment 12 Slávek Banko 2013-04-06 21:02:19 CDT

Note: Latest patches to rework of the control socket system cannot be backported to v3.5.13-sru branch, because qt-3.3 does not contain TQEventLoopThread.

Comment 13 Timothy Pearson 2013-04-06 21:03:41 CDT

(In reply to comment #12)
> Note: Latest patches to rework of the control socket system cannot be
> backported to v3.5.13-sru branch, because qt-3.3 does not contain
> TQEventLoopThread.

The Qt3 branch in GIT contains the exact equivalent QEventLoopThread; would this be enough to backport these patches?

Comment 14 Slávek Banko 2013-04-06 21:11:44 CDT

(Odpověď na komentář #13)
> (In reply to comment #12)
> > Note: Latest patches to rework of the control socket system cannot be
> > backported to v3.5.13-sru branch, because qt-3.3 does not contain
> > TQEventLoopThread.
> 
> The Qt3 branch in GIT contains the exact equivalent QEventLoopThread; would
> this be enough to backport these patches?

For TDE v3.5.13-sru branch is used qt-3.3 (also v3.5.13-sru branch) to maintain maximum compatibility with KDE3. Therefore TQEventLoopThread / QEventLoopThread cannot be used.

Comment 15 Timothy Pearson 2013-04-06 21:30:03 CDT

(In reply to comment #14)
> (Odpověď na komentář #13)
> > (In reply to comment #12)
> > > Note: Latest patches to rework of the control socket system cannot be
> > > backported to v3.5.13-sru branch, because qt-3.3 does not contain
> > > TQEventLoopThread.
> > 
> > The Qt3 branch in GIT contains the exact equivalent QEventLoopThread; would
> > this be enough to backport these patches?
> 
> For TDE v3.5.13-sru branch is used qt-3.3 (also v3.5.13-sru branch) to maintain
> maximum compatibility with KDE3. Therefore TQEventLoopThread / QEventLoopThread
> cannot be used.

OK, I guess this is just another good reason to move to R14. :-)  I do not intend to implement special hacks for older TDE versions, so the patch in this report should be completely ignored.