Have examined thread beginning with post “Very Slow SLAB Loading” by IntelliJani on 15th April 2008 leading to a reference to “resolved” bug report 348183 and including suggestions along the way including removing ~/.thumbnails, running SuSEconfig, etc, etc. None of the suggestions help. I notice the bug report is marked “resolved”. Resolved how?
Tested the notion that there might be something in the user’s home directory that was causing the problem. Created new user. On first login, the disk thrashing (both HD and USB disk) occurred for approx 2 min before pressing the chameleon. On subsequent logins the delay occurred only after pressing the chameleon.
Am puzzled that this problem was allegedly “resolved” nearly 2 years ago but is still occurring. I’d appreciate hearing from anyone who has a solution to this irritating problem.
Thanks very much for the response. I believe that the problem is unrelated to Beagle. I’ve tried deleting it, and also running with it. My worry was that Beagle indexing might actually be trying to speed up menu loading.
As far as Beagle itself is concerned, I’d love to read some discussion about what value it provides and at what resource costs. I never use Beagle Search for anything. Is there a downside to disabling it?
My guess is that somebody needs to look at the code executed when the chameleon is pressed. Likely somebody put some really bad code in there, and he knows who he is.
The menu has a search bar at the top. I’m guessing that some sort of index cache is being built, once per boot (or login), to facilitate searching from the menu. I’d gladly sacrifice this search feature to get rid of the symptom. Alternatively, possibly the cache should be made persistent and maintained by Beagle on an ongoing basis–rather than being completely rebuilt on first pressing the chameleon.
OK, thanks for the suggestions and for continuing to help me sleuth this issue. My favorite theory is still that an index cache is being built on first clicking the chameleon, in order that future use of the menu search bar is facilitated.
It appears that the menu search locates just about anything, anywhere, that appears to be executable–not just those executables that appear in the menu entries themselves. I can imagine that an index cache would be needed and that, depending on disk size and number of mounted volumes, building that cache could take a fair amount of time. Did I mention that if I have a USB disk plugged in when first pressing the chameleon–it also thrashes for about 1 minute after the main disk thrashes for about 1 minute, making the total thrash/delay time 2 minutes.
I can’t let go the theory that all mounted volumes are scanned for some reason on first chameleon click. It seems to me most likely that the purpose of disk scanning is to build an index.
Anyway, I’m going to start reading code associated with kicker and allies…
I’ve done the experiments you suggested. I booted up and logged-in under my usual login ID, clicked the chameleon and endured a 60 delay while the disk thrashed. Next, I created the new user, logged out and re-logged-in to it without rebooting. Clicked on the chameleon and there was no delay.
Then I did the reverse: After shutting down and rebooting I first logged in to the new user and clicked the chameleon. A 60 delay ensued. Then logged out and re-logged in with my usual ID, clicked on the chameleon and there was no delay.
Thus, it appears that the delay occurs once per boot/initial login and that subsequent logins (with no intervening rebooting) receive no delay.
I occasionally have a USB disk drive (My Passport) plugged in. When I do, the menu start delay is 2 minutes rather than one. I can see one of the disks thrash for 60 seconds, then it goes quiescent while the other disk thrashes for 60 seconds.
I also have a NTFS (windows/C) and a VFAT (windows/D) volume. I’m thinking of marking the fstab entries for these as NOEXEC and see if this stops the local disk thrashing.
I also notice the thrashing behavior if I simply plug in the USB disk sometime after booting. The OS obviously scans the USB disk (busy light indicating access) for some purpose, and is more or less unresponsive until the scanning is completed.
I did as you suggested, with no effect on thrashing/delays in any of the circumstances I described. I actually prefer to leave the line uncommented, though, so that with a link to the device on the desktop I have explicit control over both mounting and unmounting.
I believe the entry is correct in that I get the behavior I want from the desktop. If you see a specific problem, though, I’d love to hear more.
There is a bug IMO in the mounting of ntfs partitions/devices in particular and I started report on it
For me it’s a delay while the device mounts, about 60 seconds
But there is no problem at boot, just a delay in the mount when clicking the device in Dolphin’s Places.
It turns out that this thrashing behavior is not unique to clicking the chameleon. I happened to be using YaST to install some additional software (qt4 in this case). Right at the beginning of the installation, the hard disk light went on steady for about 60 seconds, then the plugged-in USB disk busy light went on for an additional 60 seconds. Meanwhile there was no progress in the installation. Installation resumed normally after the thrashing on both disks stopped. So this is not just a kicker problem.