This happened a lot recently (several days or weeks): when launching MageiaUpdate, /etc/X11/X eats 80% of the CPU for more than a minute, leaving the system mostly unresponsive. This means MageiaUpdate is totally unresponsive, with no packages listed in its window, and no button enabled. I wanted to launch GIMP to give you a screenshot of the MageiaUpdate window, but GIMP didn't start while /etc/X11/X was using a lot of CPU. Once the CPU usage decreased, GIMP was able to start and MageiaUpdate could list updated packages. So there is something really wrong here. In case this is useful, the command eating a lot of CPU was: /etc/X11/X :0 vt8 -nr -nolisten tcp -auth /var/run/xauth/A:........
Severity: normal => major
maybe there is something in /var/log/Xorg.0.log
CC: (none) => thierry.vignaud
Source RPM: (none) => mgaonline
@ Frédéric Is this bug still valid for current cauldron?
Keywords: (none) => NEEDINFOCC: (none) => marja11
(In reply to comment #2) > Is this bug still valid for current cauldron? Unfortunately, yes. This bug makes me crazy. And the problem is that it's not 100% reproducible (I would say the bug happens in 50% of cases). I wonder if it freezes when something else is interacting with MageiaUpdate which prevents it to complete its task.
Keywords: NEEDINFO => (none)
(In reply to comment #3) > (In reply to comment #2) > > Is this bug still valid for current cauldron? > > Unfortunately, yes. This bug makes me crazy. And the problem is that it's not > 100% reproducible (I would say the bug happens in 50% of cases). I wonder if it > freezes when something else is interacting with MageiaUpdate which prevents it > to complete its task. (In reply to comment #0) > In case this is useful, the command eating a lot of CPU was: > > /etc/X11/X :0 vt8 -nr -nolisten tcp -auth /var/run/xauth/A:........ so you never have a problem when logging in to a text terminal instead of graphic and updating from there?
I meant booting into run level 1 and then updating
However, it is interesting, too, what happens when you're in X, go to a konsole and update from there (# urpmi --auto-update) It was never with another application that your memory was eaten? (In reply to comment #1) > maybe there is something in /var/log/Xorg.0.log I saw you never replied to that question, can attach that log, or the old log, if it didn't happen again after the old log was made. I'll try to remember to use the graphical tool to update cauldron, next time. The only thing I can find about " /etc/X11/X :0 vt8 -nr -nolisten tcp -auth /var/run/xauth/A... ", is a Mandriva bug report https://qa.mandriva.com/show_bug.cgi?id=59673, where someone says kdm caused it. Would it be possible, that the update tool sometimes first tries to display the updates on a different video terminal than where you really are? On ctrl + alt + F"what" are you when it happens, and on ctrl + alt + F"what" are you when it doesn't happen?
I had too much imagination: I just updated updated cauldron and one, using the applet. cauldron was on vt 7: no problems 1 was on vt 8: no problems so which vt you're on doesn't seem to make any difference
@ Frédéric Which version of x11-server src.rpm are you using? If you're not yet using version 1.11.2-3, please try whether upgrading helps. (this question is because of bug 2600, where one user reported upgrading from x11-server-1.10.4.mga2.src.rpm to x11-server-1.11.2-3.mga2.src.rpm solved his problem of X using too much CPU)
(In reply to comment #4) > so you never have a problem when logging in to a text terminal instead of > graphic and updating from there? I never tried that and didn't really plan to do this. :) (In reply to comment #6) > However, it is interesting, too, what happens when you're in X, go to a konsole > and update from there (# urpmi --auto-update) I think it always worked fine. > It was never with another application that your memory was eaten? The same problem exists with rpmdrake. > > maybe there is something in /var/log/Xorg.0.log > I saw you never replied to that question I see nothing special in this file. (In reply to comment #8) > Which version of x11-server src.rpm are you using? x11-server-xorg-1.11.2-3.mga2
Because of bug 2600, and because lebarhon said that in cauldron his X was on "alt ctrl F1", in this thread https://forums.mageia.org/en/viewtopic.php?f=15&t=1609&start=50, i'd again like to know where you're X is when this happens. Just in case it matters, anyway ;) rpmdrake-5.27-1.mga2.src.rpm is the version you use? (it contains MageiaUpdate, too, btw) what is the output of: lspcidrake -v | fgrep Card ?
Source RPM: mgaonline => rpmdrake-5.27-1.mga2.src.rpm, x11-server-1.11.2-3.mga2.src.rpm
What would be interesting would to log from a remote connection then run "strace -p <pid_of_Xorg>" while starting rpmdrake.
Created attachment 1564 [details] do not flush more than 3 times a second Also does this patch help? as root, just run the following commands in a terminal to apply it: cd / patch -p0 < /where/it/was/downloadd/less-flushing.diff we could also try to call XFlush() instead of gdk_flush() (which is more costly)
Keywords: (none) => NEEDINFO, PATCH
Testing that now...
Ping?
I wanted to wait a few days before reporting back to you, just to get better data. Since you applied your patch, the freeze time disappeared, so it seems the problem is indeed fixed. Thank you! :)
Closing then
Status: NEW => RESOLVEDResolution: (none) => FIXED
*** Bug 3480 has been marked as a duplicate of this bug. ***
CC: (none) => zen25000
I have just tested this in a clean LXDE installation of i586 Cauldron Beta, fully updated. After opening rpmdrake via mcc using all GUI from the task bar icon the problem is still there. I booted this installation over 30 mins ago, and went almost immediately into rpmdrake to test. It's still sat there with the cpu at 95% and no package menu displayed. Here's the state of play :- [baz@jackodesktop ~]$ rpm -q rpmdrake rpmdrake-5.30-1.mga2 [baz@jackodesktop ~]$ top top - 18:37:11 up 4 min, 1 user, load average: 1.01, 0.85, 0.40 Tasks: 101 total, 2 running, 98 sleeping, 0 stopped, 1 zombie Cpu(s): 95.7%us, 3.3%sy, 0.0%ni, 1.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1030124k total, 409268k used, 620856k free, 19292k buffers Swap: 4095468k total, 0k used, 4095468k free, 168732k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1368 root 20 0 69124 14m 8904 R 93.6 1.4 2:37.94 X 1941 root 20 0 99.3m 78m 16m S 2.0 7.8 0:10.76 rpmdrake 1982 baz 20 0 211m 12m 9.9m S 1.3 1.2 0:00.37 lxterminal 28 root 20 0 0 0 0 S 0.3 0.0 0:00.30 kworker/0:2 283 root 20 0 0 0 0 S 0.3 0.0 0:00.25 kworker/0:3 852 root 20 0 5864 1248 1052 S 0.3 0.1 0:00.05 hald-addon-inpu 1854 baz 20 0 51224 32m 11m S 0.3 3.2 0:01.73 net_applet 1 root 20 0 5372 3372 1868 S 0.0 0.3 0:00.72 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/0 4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0 5 root 20 0 0 0 0 S 0.0 0.0 0:00.21 kworker/u:0 6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset 8 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper 9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs 10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Created attachment 1740 [details] sample of strace of X during hang A few seconds of strace output of X pid
Created attachment 1741 [details] A sample of strace of rpmdrake during hang A few seconds of strace out put of rpmdrake pid
I just discovered that collapsing and re-opening the mcc window by clicking it's taskbar item twice clears the hang and the rpmdrake left panel immediately fills. Thierry - if there is anything else that I can supply in relation to this please ask as this really needs fixing before mga2 release. This i586 test system seems to exhibit the problem about 50% of the time and while it's hung I can still run Firefox, top, strace etc.
I have just clean installed Beta 2 x86_64 full KDE and the issue is still there. Rpmdrake is useless like this. Increasing to high priority - but really it should be release blocker.
Priority: Normal => High
Assigning to maintainer @ Thierry Is it OK to use the same bug report, btw, I suppose the cause can't be the same?
Keywords: NEEDINFO => (none)Assignee: bugsquad => thierry.vignaud
No it's not OK. Yes it's probably another issue
That specific issue is fixed. Please do not mix different issues. Open a new bug report.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
I was not aware that it is a different issue, but if you really want me to copy / paste all the above into another bug I will.
NO hang on - my original bug was Bug 3480 which *you* marked as a duplicate of this one. That's how I ended up here in the first place. I already did all this twice - so I'm not doing it again.
In that case, reopen bug 3480, not this one.
@ Barjac I'll clone 3480 and copy what you posted here, just give me some time
(In reply to comment #29) > @ Barjac > > I'll clone 3480 and copy what you posted here, just give me some time it is bug 5000