Mailing List Archive

kdm-4.10.5-r1 - 2+ minute login delay
Hi,
From previous concersations I assume a lot of folks here use KDE. I
run mostly stable and just updated to kde-4.10.5 which included an
update to kdm. It now seems that I'm plagued by a more than 2 minute
delay from entering my password until KDE flashes up the box showing
that KDE is starting up. Once KDE is up and running everything seems
normal. There are no messages in /dev/log/message that identify any
problems. Just a 2+ minute delay before much of anything occurs.

Here's a small snippet of message showing the basic delay:

Aug 4 15:40:22 c2RAID6 polkitd[2447]: Started polkitd version 0.110
Aug 4 15:40:22 c2RAID6 polkitd[2447]: Loading rules from directory
/etc/polkit-1/rules.d
Aug 4 15:40:22 c2RAID6 polkitd[2447]: Loading rules from directory
/usr/share/polkit-1/rules.d
Aug 4 15:40:22 c2RAID6 polkitd[2447]: Finished loading, compiling and
executing 1 rules
Aug 4 15:40:22 c2RAID6 dbus[2013]: [system] Successfully activated
service 'org.freedesktop.PolicyKit1'
Aug 4 15:40:22 c2RAID6 polkitd[2447]: Acquired the name
org.freedesktop.PolicyKit1 on the system bus
Aug 4 15:40:22 c2RAID6 dbus[2013]: [system] Successfully activated
service 'org.freedesktop.ConsoleKit'
Aug 4 15:40:22 c2RAID6 kdm: :0[2350]: pam_unix(kde:session): session
opened for user mark by (uid=0)
Aug 4 15:40:22 c2RAID6 kdm: :0[2350]: pam_ck_connector(kde:session):
nox11 mode, ignoring PAM_TTY :0
Aug 4 15:42:35 c2RAID6 dbus[2013]: [system] Activating service
name='org.freedesktop.UPower' (using servicehelper)
Aug 4 15:42:35 c2RAID6 dbus[2013]: [system] Successfully activated
service 'org.freedesktop.UPower'
Aug 4 15:42:35 c2RAID6 dbus[2013]: [system] Activating service
name='org.freedesktop.UDisks2' (using servicehelper)


I Googled around for a while and got curious about whether this was
really a KDE problem so I emerged xfce4. It has the same 2 minute
issue so this appears to me more of a kdm issue as best I can tell
right now.

It's not anything obvious (to me) with networking delays as I can
sit in the console and ping web sites. No delays there. I got back to
the GUI and it's just waiting. I ran iotop in a console and there's
nothing going on. The machine is just hung for a couple of minutes.

This just started in the last couple of days with this month's KDE release.

Thanks,
Mark
Re: kdm-4.10.5-r1 - 2+ minute login delay [ In reply to ]
Mark Knecht posted on Sun, 04 Aug 2013 16:46:22 -0700 as excerpted:

> From previous concersations I assume a lot of folks here use KDE. I
> run mostly stable and just updated to kde-4.10.5 which included an
> update to kdm. It now seems that I'm plagued by a more than 2 minute
> delay from entering my password until KDE flashes up the box showing
> that KDE is starting up. Once KDE is up and running everything seems
> normal. There are no messages in /dev/log/message that identify any
> problems. Just a 2+ minute delay before much of anything occurs.
>
> Here's a small snippet of message showing the basic delay:

[Snip log showing, indeed, a two minute delay...]

> I Googled around for a while and got curious about whether this was
> really a KDE problem so I emerged xfce4. It has the same 2 minute issue
> so this appears to me more of a kdm issue as best I can tell right now.
>
> It's not anything obvious (to me) with networking delays as I can
> sit in the console and ping web sites. No delays there. I got back to
> the GUI and it's just waiting. I ran iotop in a console and there's
> nothing going on. The machine is just hung for a couple of minutes.
>
> This just started in the last couple of days with this month's KDE
> release.

While I run kde, I don't run a *dm, preferring to login at the text
console and run startx with XSESSION pointed at kde. Additionally, I
have USE=-policykit and USE=-consolekit (policykit was showing up in the
log before the delay) set and don't have either one even on my system at
all. Similarly USE=-udisks and USE=-upower (those showed up after the
delay), so I don't have those to worry about either. So I have no direct
help for you from that angle.

However, what you report sounds very much like a timeout problem,
something expected to already be running not being there, especially
since both xfce and kde have the same two-minute delay and there's no I/O
activity going on.

You mentioned running iotop in a text console and it showing no i/o to
speak of. What about CPU activity as shown by regular top/htop , and/or
load as shown by uptime? If it's a timeout issue as I expect, that won't
show any significant activity either.

What I think is happening is that the system's waiting for a response,
doing nothing but waiting for two minutes, until some timeout, after
which it gives up and either starts it on its own or does without,
depending on what it is that's missing.

I don't know for sure what that might be, but I'd suggest checking to see
if you have a system dbus running (dbus initscript), and if not, start
that before you try a kde/xfce login, and see if your delay disappears.

Another thing to check, since upower was the first thing logged after the
delay, is your power profiles, and/or especially if you're on a
wall-powered machine anyway, try setting USE=-upower and doing an
emerge --newuse @world, and see if that helps. (It's quite possible that
upower/powerdevil are entirely innocent and have nothing to do with the
problem; that it just happens that they're the first thing logged after
the timeout, but it never hurts to check that, just to be sure.)


When you do figure out the problem, please post what it was, as I'm
curious, now.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: kdm-4.10.5-r1 - 2+ minute login delay [ In reply to ]
On Sun, Aug 4, 2013 at 10:16 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Mark Knecht posted on Sun, 04 Aug 2013 16:46:22 -0700 as excerpted:
>
>> From previous concersations I assume a lot of folks here use KDE. I
>> run mostly stable and just updated to kde-4.10.5 which included an
>> update to kdm. It now seems that I'm plagued by a more than 2 minute
>> delay from entering my password until KDE flashes up the box showing
>> that KDE is starting up. Once KDE is up and running everything seems
>> normal. There are no messages in /dev/log/message that identify any
>> problems. Just a 2+ minute delay before much of anything occurs.
>>
>> Here's a small snippet of message showing the basic delay:
>
> [Snip log showing, indeed, a two minute delay...]
>
>> I Googled around for a while and got curious about whether this was
>> really a KDE problem so I emerged xfce4. It has the same 2 minute issue
>> so this appears to me more of a kdm issue as best I can tell right now.
>>
>> It's not anything obvious (to me) with networking delays as I can
>> sit in the console and ping web sites. No delays there. I got back to
>> the GUI and it's just waiting. I ran iotop in a console and there's
>> nothing going on. The machine is just hung for a couple of minutes.
>>
>> This just started in the last couple of days with this month's KDE
>> release.
>
> While I run kde, I don't run a *dm, preferring to login at the text
> console and run startx with XSESSION pointed at kde. Additionally, I
> have USE=-policykit and USE=-consolekit (policykit was showing up in the
> log before the delay) set and don't have either one even on my system at
> all. Similarly USE=-udisks and USE=-upower (those showed up after the
> delay), so I don't have those to worry about either. So I have no direct
> help for you from that angle.
>
> However, what you report sounds very much like a timeout problem,
> something expected to already be running not being there, especially
> since both xfce and kde have the same two-minute delay and there's no I/O
> activity going on.
>
> You mentioned running iotop in a text console and it showing no i/o to
> speak of. What about CPU activity as shown by regular top/htop , and/or
> load as shown by uptime? If it's a timeout issue as I expect, that won't
> show any significant activity either.
>
> What I think is happening is that the system's waiting for a response,
> doing nothing but waiting for two minutes, until some timeout, after
> which it gives up and either starts it on its own or does without,
> depending on what it is that's missing.
>
> I don't know for sure what that might be, but I'd suggest checking to see
> if you have a system dbus running (dbus initscript), and if not, start
> that before you try a kde/xfce login, and see if your delay disappears.
>
> Another thing to check, since upower was the first thing logged after the
> delay, is your power profiles, and/or especially if you're on a
> wall-powered machine anyway, try setting USE=-upower and doing an
> emerge --newuse @world, and see if that helps. (It's quite possible that
> upower/powerdevil are entirely innocent and have nothing to do with the
> problem; that it just happens that they're the first thing logged after
> the timeout, but it never hurts to check that, just to be sure.)
>
>
> When you do figure out the problem, please post what it was, as I'm
> curious, now.
>
> --
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman
>
>

Duncan,
It's a great set of ideas. I'll work on that when i get a chance later today.

If you get a chance could you please post whatever script you run
to start X this way. I haven't done this in years and it will save me
some time researching it.

Thanks,
Mark
Re: Re: kdm-4.10.5-r1 - 2+ minute login delay [ In reply to ]
Mark Knecht <markknecht@gmail.com> skribis:
> If you get a chance could you please post whatever script you run
> to start X this way. I haven't done this in years and it will save me
> some time researching it.

You can just turn off the kdm and put ‘exec startkde’ in ~/.xinitrc
Then when you run startx you get KDE. That is how I do it.
Re: Re: kdm-4.10.5-r1 - 2+ minute login delay [ In reply to ]
On Mon, Aug 5, 2013 at 10:50 AM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Mark Knecht <markknecht@gmail.com> skribis:
>> If you get a chance could you please post whatever script you run
>> to start X this way. I haven't done this in years and it will save me
>> some time researching it.
>
> You can just turn off the kdm and put ‘exec startkde’ in ~/.xinitrc
> Then when you run startx you get KDE. That is how I do it.
>

Thanks. I'll give it a try after the markets close today.

Cheers,
Mark
Re: Re: kdm-4.10.5-r1 - 2+ minute login delay [ In reply to ]
On Mon, Aug 5, 2013 at 10:50 AM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Mark Knecht <markknecht@gmail.com> skribis:
>> If you get a chance could you please post whatever script you run
>> to start X this way. I haven't done this in years and it will save me
>> some time researching it.
>
> You can just turn off the kdm and put ‘exec startkde’ in ~/.xinitrc
> Then when you run startx you get KDE. That is how I do it.
>

OK, got a chance to try this. No delays starting up KDE from a console
using startx so it is looking like a KDM issue to me, or at least I'll
assume that in the short run.

I've not tried rebuilding any packages yet ala Duncan's USE flag
suggestions. It seems I don't have as many options as he does. Of the
4 flags he suggested it seems that consolekit & policykit are forced
on for some packages and kept that way no matter what I put in
/etc/portage/make.conf. I presume that is either driven by my choice
of the KDE profile or the ebuild itself? Not sure if Duncan builds
using portage or from code. Anyway, only kdelibs will get rebuilt with
-upower & -udisks. Worth a try I suppose, but as I suspect this is a
KDM issue I'm not confident it will help.

Anyway, thanks to all for the inputs.

Cheers,
Mark
Re: Re: kdm-4.10.5-r1 - 2+ minute login delay [ In reply to ]
Mark Knecht <markknecht@gmail.com> skribis:
> I've not tried rebuilding any packages yet ala Duncan's USE flag
> suggestions. It seems I don't have as many options as he does. Of the
> 4 flags he suggested it seems that consolekit & policykit are forced
> on for some packages and kept that way no matter what I put in
> /etc/portage/make.conf. I presume that is either driven by my choice
> of the KDE profile or the ebuild itself? Not sure if Duncan builds
> using portage or from code. Anyway, only kdelibs will get rebuilt with
> -upower & -udisks. Worth a try I suppose, but as I suspect this is a
> KDM issue I'm not confident it will help.

You could try a different display manager (xdm, etc.) and see what
happens, I suppose.