|
Bugzilla – Full Text Bug Listing |
| Summary: | long delay when activating /usr/lib/powersave/do_screen_saver | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Harald Koenig <koenig> |
| Component: | Mobile Devices | Assignee: | Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | behlert, dkukawka, kde-maintainers, m.camen |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Any ideas by our KDE gurus why
/opt/kde3/bin/dcopfind kdesktop
takes 14 seconds if no KDE is running? And if we should go for
xwininfo -all -root | grep -q "kdesktop"
instead?
(In reply to comment #1) > if we should go for > > xwininfo -all -root | grep -q "kdesktop" > > instead? please note that all the quotes in my examples above have been used deliberately. your example will match and give a "false positive" KDE runnning e.g. for xemacs kdesktop & Why not just check for $KDE_FULL_SESSION = true which is defined in startkde? http://lxr.kde.org/search?v=3.4-branch&filestring=&string=KDE_FULL_SESSION (In reply to comment #3) > Why not just check for > $KDE_FULL_SESSION = true > which is defined in startkde? The scripts are not running as the logged in user, and not from the logged in session. Powersaved's environment does not get $KDE_FULL_SESSION from init. > The scripts are not running as the logged in user, and not from the logged in
> session.
/me RTFscript... ...ah, ok.
Just a comment:
I think what happens is the following: dcopfind tries to open
$HOME/.DCOPserver_`hostname`__0 (for $DISPLAY=:0.0).
On a stock 10.0 this file exists and has 'valid content' when running KDE. Thus
dcopfind returns immediately. When running xfce this file does not exist and
dcopfind also returns immediately.
Let's say for whatever reason a user is not running KDE but the .DCOPserver*
file exists nevertheless. Well, there you have the long delay.
Judging from a few 'real world' homedirectories orphaned .DCOPserver* files seem
to be not too uncommon (maybe because of crashing KDE sessions?). So, although
you won't see this bug on a fresh 10.0 installation I assume you will see users
running into it from time to time.
(In reply to comment #5) > I think what happens is the following: dcopfind tries to open > $HOME/.DCOPserver_`hostname`__0 (for $DISPLAY=:0.0). > On a stock 10.0 this file exists and has 'valid content' when running KDE. Thus > dcopfind returns immediately. When running xfce this file does not exist and > dcopfind also returns immediately. indeed! today, after a fresh reboot, I cannot reproduce the long timeout for dcopfind with xfce4 right now. too bad I did not run strace that time to figure out why/where it did hang:-( I'll try again later... > you won't see this bug on a fresh 10.0 installation I assume you will see users > running into it from time to time. yep Holger, let's discuss / incorporate the fixes from the bug description for 10.1, there was no objection from the KDE team. (In reply to comment #7) > Holger, let's discuss / incorporate the fixes from the bug description for > 10.1, there was no objection from the KDE team. last weekend I updated my notebook to 10.1 -- and realized that this fix didn't make it into 10.1 :-(( 10.1 get_x_users() in x_helper_functions still calls dcopfind and hangs :-( Anything new here, this bug is now inactive for quite some time. Is this fixed for 10.2? fixed in the sense of "the code will not be used anymore" I still have the same problem even when using plain xlock. Well, this code will not be used in 10.2 anymore. Only kpowersave or gnome-power-manager users will get "Lock X before suspend" functionality, so this code will never be executed again. (In reply to comment #14) > Well, this code will not be used in 10.2 anymore. Only kpowersave or > gnome-power-manager users will get "Lock X before suspend" functionality, so > this code will never be executed again. and for all other desktops (e.g. xfce4, fvwm2, ...) the xlock-on-suspend will silently be removed in 10.2 ??? IMHO that would be very pitty!! well, to suspend you will need to call "powersave -{U,u}" anyway, so you can also call "xlock&powersave -u".
There will not be much left of powersave after we transition to pm-utils.
|
/usr/lib/powersave/do_screen_saver uses get_x_users() from /usr/lib/powersave/scripts/x_helper_functions (powersave-0.10.15-5) to check, if KDE is running with /opt/kde3/bin/dcopfind kdesktop on my idle notebook with xfce4 this takes 13-14 seconds, so there is a huge delay before xlock gets started (you may consider this a 13 secs security risk if it helps to change that code in 10.0 ;-). what about the following possibilties to check for a running KDE su ${X_USERS[$i]} -c "DISPLAY=${DISPS[$i]} xlsclients -al | grep -q '^ Name: kicker' " && ... or su ${X_USERS[$i]} -c "DISPLAY=${DISPS[$i]} xwininfo -all -root | grep -q grep "\"Kdesktop\" && ... su ${X_USERS[$i]} -c "DISPLAY=${DISPS[$i]} xwininfo -all -root | grep -q grep "\"kdesktop\" && ... su ${X_USERS[$i]} -c "DISPLAY=${DISPS[$i]} xwininfo -all -root | grep -q grep "'"kdesktop": ("kdesktop" "Kdesktop")' && ... these all are _much_ faster if KDE is not running... right now I'm happilyusing the last of those tests,