Bug 14251 - Since the last update of dbus, Mageia is really slow
Summary: Since the last update of dbus, Mageia is really slow
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 4
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
Whiteboard: MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32...
Keywords: validated_update
: 14250 (view as bug list)
Depends on: 14102 14249
  Show dependency treegraph
Reported: 2014-10-08 19:00 CEST by Olivier Delaune
Modified: 2014-12-15 21:52 CET (History)
17 users (show)

See Also:
Source RPM: dbus-1.6.18-1.4.mga4
Status comment:

Errors on slow startup (42.69 KB, text/plain)
2014-11-04 15:14 CET, Herman Viaene

Description Olivier Delaune 2014-10-08 19:00:02 CEST
Hello, I do not whether the problem comes from the dbus update. Anyway, the problem I have for now matches well wih the yesterday update.
So when I start Mageia, it takes a really long time from the time I push the power button and the time where the menu bar appears (between 5 and 10 minutes)
And even when the menu bar is there, everything is not working fine. For example it seems that pulseaudio is not running. Another example is that firefox freezes during a long time when flash is used. The freeze terminates when flash has crashed. And so on

I do not what information do you need to identify my problem so please ask.


Steps to Reproduce:
Olivier Delaune 2014-10-08 19:00:29 CEST

Depends on: (none) => 14102, 14249

Comment 1 Olivier Delaune 2014-10-08 19:22:12 CEST
Hmmm, it seems that the problem was also related to https://bugs.mageia.org/show_bug.cgi?id=14249 (cpupower). I say "it was" because it disappeared. I decided to install all the updates in the Testing repos and after a reboot, it worked. (pulseaudio is gone back, flash does not crash any more, ...)
Comment 2 David Walser 2014-10-08 20:22:37 CEST
As with the other bug, have you rebooted since installing the update?
Comment 3 Olivier Delaune 2014-10-08 20:29:29 CEST
Yes I rebooted after installing the update. But before updating Mageia, I rebooted three or four times and it did not change anything (Mageia was still very slow). So rebooted several times seem to not solve the problem before I installed the updates.
Comment 4 José Jorge 2014-10-09 07:40:09 CEST
As indicated in #14449, for me the problem was gone without any new updates applied, even from testing.

CC: (none) => lists.jjorge

Comment 5 Olivier Delaune 2014-10-09 18:54:08 CEST
Hmmm, I spoke too fast.
I just rebooted my computer and the slowness is gone back. For now, I tried to reboot only once without any change.
Comment 6 David Walser 2014-10-09 21:23:59 CEST
*** Bug 14250 has been marked as a duplicate of this bug. ***

CC: (none) => christian-maryse.fischer

Comment 7 christian fischer 2014-10-10 09:11:12 CEST
Y have 4 Mageia4 on 3 conputers.
When boot is in text mode , and then login and startx , all work fine.
New dbus is good, but loading has a problem.
Comment 8 rexy 2014-10-10 10:25:28 CEST
The problems appear only on some computers (laptop, old PC, etc.) but not on others (new PC).
If you install the previous RPM of dbus (dbus-1.6.18-1.3.mga4), the problems disappear.
explanations :

With the last RPM of dbus dbus-1.6.18-1.4.mga4), some computers become very slow with the following errors (command used : 'journalctl /usr/bin/dbus-daemon'):
-- Reboot --
oct. 09 14:37:35 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
oct. 09 14:37:35 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
oct. 09 14:37:35 localhost dbus[1203]: [system] Successfully activated service 'org.freedesktop.login1'
oct. 09 14:37:46 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.ColorManager': timed out
oct. 09 14:37:52 localhost dbus[1203]: [system] Activating systemd to hand-off: service name='org.freedesktop.UPower' unit='upower.service'
oct. 09 14:38:00 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
oct. 09 14:38:17 localhost dbus[1203]: [system] Failed to activate service 'org.freedesktop.UPower': timed out
oct. 09 14

You can install the previous RPM like that :
- download on the répository the previous rpm (dbus-1.6.18-1.3.mga4.x86_64.rpm) for your architecture in the uptdate section
- install it with the command : 'rpm -Uhv ./dbus-1.6.18-1.3.mga4.x86_64.rpm --force'
- reboot

The errors have disappeared :
-- Reboot --
oct. 09 17:10:12 localhost dbus[1192]: [system] Successfully activated service 'org.freedesktop.systemd1'
oct. 09 17:10:13 localhost dbus[1192]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service'
oct. 09 17:10:13 localhost dbus[1192]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
oct. 09 17:10:13 localhost dbus[1192]: [system] Successfully activated service 'org.freedesktop.ColorManager'
oct. 09 17:10:13 localhost dbus[1192]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
oct. 09 17:10:22 localhost dbus[1192]: [system] Activating via systemd: service name='org.freedesktop.UDisks2' unit='udisks2.service'
oct. 09 17:10:25 localhost dbus[1192]: [system] Successfully activated service 'org.freedesktop.UDisks2'

CC: (none) => richard

Comment 9 christian fischer 2014-10-10 12:12:07 CEST
conputers AMD ( prosessors A4 and E1 ) are working properly with new dbus.
only my old "core2duo" have to download to the old dbus.
with :
urpmi --downgrade dbus-1.6.18-1.3.mga4 lib64dbus1_3-1.6.18-1.3.mga4 dbus-x11-1.6.18-1.3.mga4 
now boot is good on that old computer.
Comment 10 rexy 2014-10-10 13:39:16 CEST
Thank you Christian for the "downgrade" option. It's easier like that.
Comment 11 Thomas Andrews 2014-10-10 15:26:41 CEST
Seeing the same problem with 32-bit desktop machines, both an Intel P4 and an AMD Sempron 3100+. The first uses the desktop kernel, the other uses the server kernel. 

Repeated boots do not solve the problem. I have discovered that booting into safe mode and using the [control-D] command to continue DOES fix things, but only for about three boots.

I only just discovered this bug report, and will not have the time to look into downgrading dbus until later today. When I do, I will report back here with the results.

CC: (none) => andrewsfarm

Comment 12 James Kerr 2014-10-10 16:13:47 CEST
On a 32 bit system you will need to downgrade libdbus1_3... and not lib64dbus1_3...
Comment 13 Herman Viaene 2014-10-11 10:38:51 CEST
To add my 2c (or to increase the confusion): in contrary to Christian, my desktop and laptop (both Mageia4) are affected by the new dbus.
The desktop has AMD FX(tm)-6100 Six-Core Processor, and the laptop has AMD Phenom II N950 Quad core.

CC: (none) => herman.viaene

Florian Hubold 2014-10-11 16:31:50 CEST

CC: (none) => doktor5000, lmenut
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=14249

Comment 14 Thomas Andrews 2014-10-11 22:02:40 CEST
Downgrading dbus seems to eliminate the problem, just as with everybody else.

Another symptom: When the problem manifests, my customized power management settings are ignored. Also, the computer is very slow to shut down.
Comment 15 Lew Molina 2014-10-12 17:18:17 CEST

I also encountered this problem and hounded me for days. I thought I messed up the system because I was trying to configure conky.What I did was to reformat my laptop and install Gnome3. After all the updates, I also noticed the same pattern but to a lesser extent. At one point, I boot my laptop and it gets stucked for a very long time (like waiting for 5 minutes) and I just have to restart by doing CTRL + ALT + F2 and then CTRL + ALT + DEL. The system would reboot and then it proceeds to my login screen. It seems to happen every other reboot / shutdown-power on.

Since the preferred desktop of Mageia is KDE, I will reformat back to KDE and just follow the advice given here.

My Laptop is MSI CX41
Intel i5 Ivy Bridge Processor 3210m
Dual graphics - HD4000 Graphics and AMD Radeon 7670m

I'm not sure if this helps. When I was still on KDE, I noticed that when I get into my desktop to a working state (which takes at around 15 minutes) my conky is running but lacked some details. I am specifically referring to a program (hddtemp) to display information on my conky. Running it manually (via terminal) produces an error something with permissions and polkitd.

CC: (none) => lewmail101-mailbox

Comment 16 claire robinson 2014-10-14 14:01:56 CEST
Experienced this myself on my mums laptop. The only difference with this machine was it updated dbus and kernel at the same time. I suspect this might have something to do with it.

I had to boot runlevel 3 to get to a login. After downgrading dbus and rebooting it was back to normal. Updating dbus again caused no regression.

I have the journal if it's needed.

CC: (none) => tmb

claire robinson 2014-10-14 18:40:48 CEST

CC: (none) => eeeemail

Bill Wilkinson 2014-10-16 16:18:39 CEST

CC: (none) => wrw105

Comment 17 Ole Reier Ulland 2014-10-17 23:07:55 CEST
(In reply to christian fischer from comment #9)

> urpmi --downgrade dbus-1.6.18-1.3.mga4 lib64dbus1_3-1.6.18-1.3.mga4
> dbus-x11-1.6.18-1.3.mga4 
> now boot is good on that old computer.

These packages made huge problems for my Dell Dimension 8300, but now that I downgraded the packages according to this command everything was solved.

I also made the following additions to /etc/urpmi/skip.list:




CC: (none) => ole.reier

Comment 18 José Jorge 2014-10-21 16:06:15 CEST
I have submitted to core/updates_testing a dbus that fixed the boot problem on my 2 systems : to workaround a CVE, the timeout was changed from 30s to 5s, which triggered timeout bugs on some systems.

I have found that a 10s timeout both is better than 30s, and does not trigger timeouts anymore. Please, test dbus-1.6.18-1.5.mga4 and report if it fixes your systems, so that we can push it into regular updates.


Comment 19 Olivier Delaune 2014-10-21 18:56:15 CEST
I installed dbus, dbus-x11, lib64dbus-devel, libdbus1_3, lib64dbus1_3 (with 1.6.18-1.5.mga4 at the end of the package name) and I have still the problem: Mageia is really slow.
I will now test the procedure given by Thomas Backlund (https://bugs.mageia.org/show_bug.cgi?id=14249#c37) and I come back
Comment 20 Ole Reier Ulland 2014-10-22 04:45:23 CEST
Since there is so much writing about the computer being slow I believe I should add my experience. I am talking about a Dell Dimension 8300, a 32-bit computer. The problems was that, yes, KDE took 20 times longer to load, but the screens were messed up, that was worse.

I have a dual screen system with a DVI 1920x1080 and a VGA 1680x1050. My system then shows a screen of almost 3600x1080. (1920+1680=3600) Because of the dbus-1.6.18-1.4 packages the VGA screen became only a clone of the DVI screen, and just the upper left part of the DVI screen which has more pixels. The VGA screen was also not present in the System Settings - Display Configuration.

But when I started the machine in safe mode and press ctrl-D when I am asked to do so or give the root password, the machine started as it used to with no display problems. I also tried to start the machine in normal mode after safe mode, but it made no difference for the normal mode situation.
Comment 21 Thomas Backlund 2014-10-22 08:44:57 CEST
OK, there is now a dbus-1.6.18-1.6.mga4 in updates_testing so both i586 and x86_64 users can test
Comment 22 Thomas Andrews 2014-10-22 18:03:15 CEST
New 32-bit packages worked OK with a Dell Dimension E310 (P4 processor, desktop kernel) but did not work with a machine with an AMD Sempron 3100+ processor and the server kernel. With the latter machine I got two reboots before failure, and as before booting into safe mode and continuing using Control-D avoids the problem.

Please post the procedure for downgrading from the test packages. I get a message that the ***.3 versions aren't in the database.
Comment 23 Thomas Andrews 2014-10-22 20:53:57 CEST
Inability to downgrade was solved by changing from MIRRORLIST to the specific US kernel.org mirror.
Comment 24 Olivier Delaune 2014-10-23 20:06:46 CEST
Installation of dbus-1.6.18-1.6.mga4 and cie solves the problem of slowness here. Mageia boots as before. Thank you.
Comment 25 rexy 2014-10-24 09:03:51 CEST
On a laptop and a Desktop PC which have had the issue with 1.6.18-4, all is ok now with the version "1.6.18-1.6" of dbus and lib64dbus
Comment 26 Herman Viaene 2014-10-24 10:28:56 CEST
Confirm dbus-1.6.18-1.6.mga4 update on 64-bit laptop (AMD- Phenom N950) with KDE desktop works OK , no slowness seen.
Comment 27 Bernd Deinzer 2014-10-25 08:57:14 CEST
dbus-1.6.18-1.6.mga4 update works on a 64bit i5 system npw. Booting fast and reliable to KDE, Mate or Cinnamon now. Thanky you!

CC: (none) => bernd.deinzer

Comment 28 Rémi Verschelde 2014-10-25 10:35:09 CEST
@Thomas: Do you want QA to get started with this one, or do you plan to investigate some more?

CC: (none) => remi

Comment 29 Thomas Backlund 2014-10-25 11:52:52 CEST
Note to testers, the procedure to test is easy, install the update,
reboot and check that everything still works. Now if you didn't have
an issue with the dbus released in MGASA-2014-0395, you shouldnt see
any issue with this update either as the only change is an added
15s to the default auth_timeout.

Now the -1.6.mga4 had 15s timeout, but some issues still remained,
so I bumped it to 20s in -1.7.mga4 wich is now handed over to QA

And even if no "official bug-report" has showed up against mga3
yet, we do the same there to "be safe" as it simply might mean
it has less users with affected systems nowdays...


Updated dbus backages fixes a regression with default auth_timeout

As part of the earlier security update for dbus (MGASA-2014-0395)
default auth_timeout was changed from 30s to 5s to make it harder
to abuse on systems with no auth_timeout defined.

As it turns out it 5s is not enough for some systems to boot up and
activate services properly, so they ended up with services failing
to start up, leading to slow or unusable systems.

This update changes the default auth_timeout to 20s wich
appears to be enough to fix the issue.








Hardware: x86_64 => All
Assignee: bugsquad => qa-bugs
Whiteboard: (none) => MGA3TOO

Comment 30 José Jorge 2014-10-25 14:16:06 CEST
Tested OK for MGA4_32

Whiteboard: MGA3TOO => MGA3TOO MGA4-32-OK

Comment 31 Bill Wilkinson 2014-10-25 14:25:28 CEST
Been running mga4 32 and 64 with this for a few days, no problems to report.  Indeed, I had an issue with MCC not starting after the previous update and that's been resolved as well.

Whiteboard: MGA3TOO MGA4-32-OK => MGA3TOO MGA4-32-OK mga4-64-ok

Comment 32 James Kerr 2014-10-25 14:46:43 CEST
(In reply to Bill Wilkinson from comment #31)
Are you sure? dbus-1.6.18-1.7.mga4 only became available today.
Comment 33 Thomas Backlund 2014-10-25 14:54:47 CEST
I guess he means dbus-1.6.18-1.6.mga4 released on 2014-10-22 

The dbus-1.6.18-1.7.mga4 only added 5 more seconds to the auth_timeout, so if the 1.6 works good, so will 1.7
Comment 34 Thomas Andrews 2014-10-25 15:18:30 CEST
Just tried the newest one on the machine that failed with the .6 version, and all seems OK now. Did five reboots with no problems. Could only get 1 or 2 before.
Comment 35 Thomas Backlund 2014-10-25 15:42:24 CEST
(In reply to Thomas Andrews from comment #34)
> Just tried the newest one on the machine that failed with the .6 version,
> and all seems OK now. Did five reboots with no problems. Could only get 1 or
> 2 before.

Awesome :)

Your report in comment 22 was one of the reasons I added an additional 5s in the .7 version
Comment 36 Marc Lattemann 2014-10-25 17:20:12 CEST
tested updated packages on my affected mediacenter (mga4-64bit) and performed several reboots: everything is fine. Tested same update on my laptop (also mga4-64bit), which is not affected and after several reboots no regression detected.

CC: (none) => marc.lattemann

Marc Lattemann 2014-10-25 17:20:50 CEST

CC: marc.lattemann => (none)

Comment 37 Thomas Andrews 2014-10-26 01:16:54 CEST
(In reply to Thomas Backlund from comment #35)
> Your report in comment 22 was one of the reasons I added an additional 5s in
> the .7 version

Glad to be of help. I guess these two creaky old systems can still be useful after all.
Comment 38 Otto Leipälä 2014-10-26 09:33:08 CET
I tested Mageia 3 64&32 ok i added whiteboard it.

CC: (none) => ozkyster
Whiteboard: MGA3TOO MGA4-32-OK mga4-64-ok => MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK

Comment 39 Rémi Verschelde 2014-10-26 10:55:19 CET
Advisory uploaded. Validating the update, please push dbus to 3 & 4 core/updates.

Keywords: (none) => validated_update
Whiteboard: MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK => MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK advisory
CC: (none) => sysadmin-bugs

Rémi Verschelde 2014-10-27 18:36:39 CET

Source RPM: (none) => dbus-1.6.18-1.4.mga4

Comment 40 Mageia Robot 2014-10-28 12:34:04 CET
An update for this issue has been pushed to Mageia Updates repository.


Resolution: (none) => FIXED

Comment 41 Herman Viaene 2014-11-03 11:31:49 CET
After applying the latest updates, the problem appears again. I downgraded dbus as stated above, and restarted. Now the computer is running well.
Comment 42 James Kerr 2014-11-03 12:52:38 CET
In comment #13, you report a laptop and a desktop that both experienced the bug. 
In comment #26 you report having tested the update successfully only on your laptop.
Can you confirm that you did not test the update on your desktop and that it is that system that is now experiencing the bug.
Comment 43 christian fischer 2014-11-03 15:12:26 CET
for mi all is good
Comment 44 Herman Viaene 2014-11-03 17:25:46 CET
I did not test the 1.6 version on the desktop, but a soon as the 1.7 version appeared on the repository, I did this update. So I reverted back from 1.7 to 1.3, and running it now.
In fact, I had two laptops with Mageia4 affected, I checked the one I tested in comment 26, and that one is running 1.7 without problems.
Should I reinstall the latest updates to check if the problem replicates?
Comment 45 José Jorge 2014-11-04 08:13:45 CET
(In reply to Herman Viaene from comment #44)
> I did not test the 1.6 version on the desktop, but a soon as the 1.7 version
> appeared on the repository, I did this update. So I reverted back from 1.7
> to 1.3, and running it now.

I had the bug this morning on a system that worked nicely with 1.7. A single reboot fixed it. So:
- it looks like 20s timeout is not enough for everyone
- I think you should try again 1.7 and, with several boots, report if it fails often.
Comment 46 Herman Viaene 2014-11-04 09:14:45 CET
OK, I reinstalled 1.7 and rebooted, all OK for now. I'll keep an eye on it.
Comment 47 Thomas Andrews 2014-11-04 10:37:05 CET
I too had one boot with the AMD machine that 1.6 didn't fix where it appeared to have the problem resurface. I'm not sure about the slow boot, as I had started it and then was called away and so didn't see it. But when I got back I had no audio, which was one of the symptoms. It went away on another reboot.
Comment 48 Herman Viaene 2014-11-04 15:05:19 CET
To me this problem is not solved.
Reinstalled 1.7, made sure the PC is fully updated.
First reboot was OK (mentioned in comment 46)
Second reboot was again very slow. I let it go through and then tried (as recommended above) to reboot. But that gave a lot of problems.

1. I choose "Leave - Restart" from the menu, but that made KDE only unresponsive, but did not close it. The screeb remained at the normal KDE with splash and panel, but did not react to any mouse action. After some minutes, I recurred to Ctrl-Alt-Backspace, and that brought me back to the login screen. There I choose again for "Shutdown - Restart" and that removed the splash, but leaves me again with a hanging system. The last messages on the screen (5 or 6 of them) all refer to "rpc.mountd: could not open connection for udp6 (or tcp6)". I had to use the reset button on the PC to get anything happening.

2. The third reboot was also slow, especially starting up KDE. It took about 8 minutes to get to a workable state, the login screen appeared a but slower than usually, then splash appeared after about 5 min, but then another 3 min. passed before the bottom panel appeared and KDE became usable.
One of the QA testers suggested that .xsession_errors might give injformation, so I attach it. In case you wonder at that file: I have firefox and thunderbird and 4 files to be opened with Kwrite in Autostart.

3. Once KDE is on, some things like Kmahjongg start in a jiffy, but dolphin from the "Home" button on the desktop takes 6 min to open its (then still blank) window. Starting it from the CLI gives
[herman@xxxx ~]$ dolphin
Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString)
Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QString)
Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QDBusObjectPath)
dolphin(29443)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed:  "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." 

Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.TimedOut" 
 "Activation of org.freedesktop.UDisks2 timed out" 
Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.TimedOut" 
 "Activation of org.freedesktop.UDisks2 timed out" 
Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.TimedOut" 
 "Activation of org.freedesktop.UDisks2 timed out" 
Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.TimedOut"
and more of these UDisks timeouts.
The messages at the top on QDBusAbstractInterface are the same as in the .xsession_errors file.

I'll defintely revert back to dbus 1.3 till more positive news.
Comment 49 Herman Viaene 2014-11-04 15:14:08 CET
Created attachment 5574 [details]
Errors on slow startup
claire robinson 2014-11-04 16:07:30 CET

Attachment 5574 mime type: application/octet-stream => text/plain

Comment 50 Herman Viaene 2014-11-04 17:02:44 CET
Comment 48 was on my desktop, now my laptop has the issue again.I'll check if there is more/other info in its .xsession_errors. And BTW, this lpatop has nothing in its Autostart.
Comment 51 Herman Viaene 2014-11-05 17:05:05 CET
Tested on the same desktop (6Core AMD with 8Gb mem) and with another user than my usually own.
Reinstalled dbus 1.7
3 reboots were OK, 4 and 5 were again very slow, 6 and 7 again OK.
Comment 52 José Jorge 2014-11-05 18:59:29 CET
The more I read, the more I think we should go back to 30 seconds timeout : lots of us are experiencing at least 10% boot errors with 20 seconds timeout. I've just got it again.
Comment 53 Thomas Andrews 2014-11-09 15:51:46 CET
I have now experienced the problem twice more on my AMD desktop with the 1.7 dbus in place. It's happening with much less frequency than before, at least. I haven't counted successful vs. slow boots, but my impression is that 10% slow is about right.
Comment 54 Thomas Backlund 2014-11-10 21:47:24 CET
Can you try dbus-1.6.18-1.8.mga4

And report your findings in bug:
Comment 55 Simon McVittie 2014-11-18 12:30:31 CET
Reported upstream, <https://bugs.freedesktop.org/show_bug.cgi?id=86431>.

Mageia security / D-Bus maintainers: please report regressions upstream, particularly if they are regressions in security updates. We can't fix bugs we don't know about.

CC: (none) => simon.mcvittie
See Also: (none) => https://bugs.freedesktop.org/show_bug.cgi?id=86431

Comment 56 Simon McVittie 2014-11-18 19:29:59 CET
If you have had this bug in the past, can you help me fix it for everyone by providing more information, or doing some testing for me? Please see <https://bugs.mageia.org/show_bug.cgi?id=14249#c54> for details.
Comment 57 Simon McVittie 2014-12-15 21:52:15 CET
> The more I read, the more I think we should go back to 30 seconds timeout

FYI, I did this in 1.6.28 and 1.8.12 upstream.

Note You need to log in before you can comment on or make changes to this bug.