...

Watching the log, I noticed the whole thing hangs on importing some (random?) modules and the hangs last from 20-30 secs up to several minutes. After that, it imports some more modules and hangs again on importing something else ... and so on.

Are they really random, hanging on different places in different runs of the same command?

Nah, I shouldn't have used "random" word. It always hangs in the same place with the same command ('import Arch' with 'yast sysconfig', for example), but in a different place with a different command.

...

Watching strace output, lines like this scroll by for ages:

[pid 8194] read(7, "b", 1) = 1 [pid 8194] read(7, "u", 1) = 1 [pid 8194] read(7, "s", 1) = 1 [pid 8194] read(7, ";", 1) = 1

Argh, unbuffered reads like this distort the strace quite a lot, we must get rid of them. You can work around it by redirecting the strace output to a file so that it does not have to scroll :-/

Redirect with '>' ? I tried 'strace -ff -o log ... ' but with lot of created log files all over the place, I found it hard to locate the one where the hang can be observed. I will file a bug, of course, I guess with Y2DEBUG logs. Nothing much can be observed with standard logging, just the long pauses while importing various stuff I described above :( fB. -- \\\\\ Katarina Machalkova \\\\\\\__o OOo developer __\\\\\\\'/_ & hedgehog painter

On streda 11 August 2010 11:08:53 Katarina Machalkova wrote:

...

...

OK, so obviously the more YCP files it has to parse, the longer it takes to launch. Comparing y2-users (lots of YCP files) with y2-inst_release_notes (relatively few YCP files), the former takes ~5 minutes to launch, while the latter needs only 5 seconds.

Soo - this can't be a secret YaST feature, can it? :) Am I doing anything wrong? Did upgrade mess something up? If so, what? Has anyone seen something like this before (in bugzilla etc.)? If needed, I can make my laptop available if someone wants to play with it Greetings

Please file me a bug, with y2logs, without strace, and I'll fix the unbuffered reads to make stracing more useful.

For the record: I've installed yast2-core 2.19.3 with buffered read patch from YaST:Head repository. It seems that buffering the reading of #includes did the trick.Using y2-users as a benchmark again, the patch reduces start-up time from 4.5 minutes to 12 seconds.

Now someone can come up with a conspiration theory, why it might have been *that* bad with unbuffered reads (it felt like pkg management in 10.1 again)

Related ticket: http://bugzilla.novell.com/show_bug.cgi?id=629882 Thanks to Martin for prompt fixing

Shouldn't it go out as maintenance update for 11.3? Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

* Stanislav Visnovsky [Aug 19. 2010 09:42]:

...

...

Related ticket: http://bugzilla.novell.com/show_bug.cgi?id=629882 Thanks to Martin for prompt fixing

Shouldn't it go out as maintenance update for 11.3?

Absolutely !

The fix of this issue is harmless (TM), so no objections against releasing online update, but ... I still seem to be the only one affected by the slowdown. I took my time to research bugzilla (YaST, Installation & Update problems) to find out no similar issue has been reported yet.

Though the more pressing question is why this fix is needed at all ? What changed ? And why ? And when (what other distributions are affected) ?

My laptop is fairly standard Lenovo ThinkPad T500. I've been using 11.1 on it since the purchase 1.5 ys ago and had (apart from yast2-gtk) no hand-compiled stuff on it. Things went downhill after upgrade to 11.3 and with YaST only, I observed no slowdowns with other apps. And, the weirdest thing was that calling y2base directly (ie. not via /sbin/yast2 bash script) made YaST work with its normal speed. No clue what might have changed and where. It can be anything from bash through glibc up to kernel, even faulty hardware. B. -- \\\\\ Katarina Machalkova \\\\\\\__o OOo developer __\\\\\\\'/_ & hedgehog painter