Comment 73 for bug 376145

I've been looking at what we think is the cause of this and other bugs tonight
with Chris.

I've been using gdu-notification-daemon, but we think it is the same root cause,
a timeout on the GetAll call in the gnome-disk-utility code.

Based on Chris' idea we added sleep(5) call to devicekit-disks-daemon as the
first thing it does. This makes the issue more reproducible. Given that at startup
the system is loaded it makes sense that longer time to execute causes the issue.

This sleep is under the 25 seconds timeout that the activation has (different
to the call timeout), so that's not likely to be kicking in (barring accounting
bugs), and even if it does it should give an error response, not cause a call
timeout client-side.

This reliably gives a client-side timeout with the default timeout. We tweaked
that timeout to see what happens.

  * On my machine it is around a 20.15 second timeout that you get the switch.
    Less than this and it times out, more and it works.
  * The time taken to get the timeout error, and the time taken to get the call
     return are ~about equal at 5.something seconds, nowhere near the actual
     timeout specified.
  * Reducing the sleep to 3 seconds doesn't have a linear effect on the issue.
    You have to reduce the timeout by a lot more than 2 seconds to see the failures
    there. I haven't investigated this relationship further or looked for discontinuities.

My current suspicion is that this is a D-Bus bug. Some sort of error means that
when it gets the real response it instead returns the timeout response when the
specified timeout is less than some threshold. I'm not sure why there seems to
be a relationship between that threshold and the amount of time that it takes to
start the service though.

Please bear in mind that this is just my blind pokings, and that nothing I say
should be taken as fact. It may well be that this is the wrong tree to be barking
up in some way.

Thanks,

James