Bugzilla – Bug 105507
Yast produces 100% CPU loop processes
Last modified: 2006-11-14 12:05:33 UTC
Not sure when exactly this happens, but I experienced it quite often. After reinstalling some software, not sure when this is triggered exactly, y2base process(es) run with 100% CPU load in the background. Top output: 7597 root 15 0 178m 109m 15m S 49.9 22.1 40:12.12 y2base 6646 root 15 0 203m 133m 15m S 48.9 27.0 62:28.32 y2base strace of both process gave the same tight loop: munmap(0x2aaab027a000, 4096) = 0 write(9, "*", 1) = 1 read(6, "\0", 1) = 1 uname({sys="Linux", node="weissichgradnich", ...}) = 0 stat("/var/log/YaST2/y2log", {st_mode=S_IFREG|0644, st_size=575872, ...}) = 0 open("/var/log/YaST2/y2log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 12 fstat(12, {st_mode=S_IFREG|0644, st_size=575872, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab027a000 fstat(12, {st_mode=S_IFREG|0644, st_size=575872, ...}) = 0 lseek(12, 575872, SEEK_SET) = 575872 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 write(12, "2005-08-19 16:43:03 <2> weissich"..., 171) = 171 close(12) = 0 munmap(0x2aaab027a000, 4096) = 0 write(9, "*", 1) ... Seems as if there is a broken pipe or something?: weissichgradnich:~ # ls /proc/7597/fd/ -al total 12 dr-x------ 2 root root 0 Aug 19 17:58 . dr-xr-xr-x 5 root root 0 Aug 19 16:21 .. lrwx------ 1 root root 64 Aug 19 17:58 0 -> /dev/pts/6 (deleted) lr-x------ 1 root root 64 Aug 19 17:58 1 -> /var/log/YaST2/y2log-9 (deleted) l-wx------ 1 root root 64 Aug 19 17:58 10 -> /var/log/YaST2/y2log-9 (deleted) lrwx------ 1 root root 64 Aug 19 17:58 11 -> socket:[28498] lr-x------ 1 root root 64 Aug 19 17:58 2 -> /var/log/YaST2/y2log-9 (deleted) lrwx------ 1 root root 64 Aug 19 17:58 3 -> /dev/pts/6 (deleted) lr-x------ 1 root root 64 Aug 19 17:58 4 -> /dev/pts/6 (deleted) l-wx------ 1 root root 64 Aug 19 17:58 5 -> /dev/pts/6 (deleted) lr-x------ 1 root root 64 Aug 19 17:58 6 -> pipe:[28410] l-wx------ 1 root root 64 Aug 19 17:58 7 -> pipe:[28410] lr-x------ 1 root root 64 Aug 19 17:58 8 -> pipe:[28411] l-wx------ 1 root root 64 Aug 19 17:58 9 -> pipe:[28411]
Please attatch y2logs where those processes are running. The logs even contain the pid.
The yast logs contain these lines and some more thousand of these: 2005-08-19 18:03:55 <2> weissichgradnich(6646) [YCP] clients/menu.ycp:268 Event or widget ID no t handled: $["EventSerialNo":345514, "EventType":"CancelEvent", "ID":`cancel] 2005-08-19 18:03:55 <2> weissichgradnich(6646) [YCP] clients/menu.ycp:268 Event or widget ID no t handled: $["EventSerialNo":345515, "EventType":"CancelEvent", "ID":`cancel] 2005-08-19 18:03:55 <2> weissichgradnich(6646) [YCP] clients/menu.ycp:268 Event or widget ID no t handled: $["EventSerialNo":345516, "EventType":"CancelEvent", "ID":`cancel] 2005-08-19 18:03:55 <2> weissichgradnich(6646) [YCP] clients/menu.ycp:268 Event or widget ID no t handled: $["EventSerialNo":345517, "EventType":"CancelEvent", "ID":`cancel] 2005-08-19 18:03:55 <2> weissichgradnich(6646) [YCP] clients/menu.ycp:268 Event or widget ID no t handled: $["EventSerialNo":345518, "EventType":"CancelEvent", "ID":`cancel] 2005-08-19 18:03:55 <2> weissichgradnich(6646) [YCP] clients/menu.ycp:268 Event or widget ID no t handled: $["EventSerialNo":345519, "EventType":"CancelEvent", "ID":`cancel] 2005-08-19 18:03:55 <2> weissichgradnich(6646) [YCP] clients/menu.ycp:268 Event or widget ID no t handled: $["EventSerialNo":345520, "EventType":"CancelEvent", "ID":`cancel] 2005-08-19 18:03:55 <2> weissichgradnich(6646) [YCP] clients/menu.ycp:268 Event or widget ID no t handled: $["EventSerialNo":345521, "EventType":"CancelEvent", "ID":`cancel]
Seems like an endless loop in menu.ycp.
Actually the same happens if you quit yast (ncurses) with just closing the xterm. y2base hangs then with 99 % CPU
Jiri, please, take a look what's going on.
Thomas/Marcel, could you provide a way to reproduce a problem? I wasn't successful with it. What yast module did you run? What does it mean "reinstalling some software"? Additionally, please provide whole y2log.
This one is running (ps aux|grep y2base): root 8920 76.7 3.4 77396 17648 ? Sl 11:00 0:18 /usr/lib/YaST2/bin/y2base menu ncurses It is enough to simply call yast and quit again. No need to invoke any other further module. I also noticed this on one of olh's PPCs, but haven't digged in any further, just killed the annoying process. But it's probably the same bug. I wonder why others don't see this?!? Still this is a blocker. Will try next Beta, but I be sure it still exists if nobody looked at it.
Investigated a bit further: This only happens if you call yast in a console. Invoking yast2 (graphical mode) in the shell works OK. Invoking yast (text mode) and quit again, produces the 100% y2base process and kills the shell with all its running apps. This also does not happen if I use one of the tty(0-x) consoles. It is 100% reproducable when opening yast in konsole (KDE console). If I open xterm in konsole, then opening yast and quit -> no process looping. If I open xterm in konsole, then opening yast and closing the whole xterm window -> busy loop (as outlined by Marcel). You can try to reproduce this on my machine. Maybe you get it by ssh -X opening konsole and invoking yast in text mode? -> machine: *weissichgradnich*
I expect missing signal handling? Or inproper detaching of the console? No idea ... If it's only happening in text mode one can discuss whether this is a blocker, I keep this severity so that project managers get attention, at least it's a really sever bug and should happen on all machines on all architectures.
Maybe we should add an expert in console internals and signal handling to CC, to solve this properly, not sure who also knows a bit about yast, kkaempf?
The expert is already in CC, but he's on the vacation.
I'm not able to reproduce it neither on my machines nor on your (!) one.
Thomas, did you see it on beta 1? Is your current beta freshly installed or upgraded? Could you reproduce it on some fresh beta2? As written before, I didn't reproduced it on your machine, using ssh -X. I've started konsole, than 'xterm -e yast' from konsole, closed xterm: nothing strange. I've tried it on beta2 on our test machines: neither i386 nor x86-64 reproduced it. Mayby I still don't understand you way-to-reproduce. UPDATE: Well, now I added some new check to manu.ycp no your machine, could you please test it again?
Give me time to finish some work and I install a fresh Beta this afternoon.
How to reproduce: start KDE konsole (or xterm) su - yast Close the window of the konsole (do not exit YaST by the menue). On my machine it's 100% reproducable
Created attachment 46863 [details] patch for /usr/share/YaST2/clients/menu.ycp Marcel, could you patch your /usr/share/YaST2/clients/menu.ycp with attached patch and try again?
Seems to fix the problem, thanks.
Thomas, what about you? I've patched menu.ycp on your machine already...
Thanks -> works fine. I let the bug open, please close it yourself when it's checked in.
Wait, the y2base loop process is gone, but the konsole still dies, my editor is gone...damn it.
Konsole dies when you close it? I don't understand.
With konsole you could already trigger the loop by just opening yast and quit again. The loop is gone, but the konsole is still shutdown/exited (as if you hit the X button in the right up corner) and all apps that where opened inside this shell/konsole are also killed.
You wrote in comment #8: "If I open xterm in konsole, then opening yast and quit -> no process looping." I'm not able to reproduce the loop without killig xterm/konsole. Could you describe the way to do it once more?
invoke konsole (or just use the one you work in). open yast and close it again. The konsole is gone ...
I can't reproduce this after patching menu.ycp, but there is indeed still a problem: 1. Open Konsole, start YaST 2. Open new tab 3. Switch back to tab with YaST -> yast has died 4. Nevertheless Konsole is still alive and both tabs work This bug is not 100% reproducable, but ca. 50%
wow, I can reproduce behaviour from last comment. UI::WaitForEvent() got the event with ID cancel when switching the tab. Stefan, any idea?
I have no clue. There might be some strange signal (as in signal(2)) that is sent to NCurses that needs to be handled. But I don't know enough about NCurses to give very good advice about that.
As for closing the xterm, this will probably send a SIGHUP to that process - which might be caught and handled the wrong way.
It's the KDE konsole, xterm is behaving correctly.
I also don't know about ncurses. As this behaviour is really rare, I would postopone it after 10.0.
later
I'm still wondering: isn't it konsole that sends some strange signal in case of switching its tabs? (I cannot reproduce it in gnome-terminal.) KDE-maint: look at comment #25 to see the strange behaviour (/usr/share/YaST2/clients/menu.ycp must be patched before using the patch https://bugzilla.novell.com/attachment.cgi?id=46863)
don't know what signals that could be either.
Reopening for reassign.
Seems to be no longer reproducible with 10.2 and SLE 10 (new KDE and thus Konsole version - don't know either). Closing as 'worksforme' then. @everyone: Please reopen, if you see such behaviour again ...