https://bugzilla.novell.com/show_bug.cgi?id=856476 https://bugzilla.novell.com/show_bug.cgi?id=856476#c0 Summary: font cache should never be regen'd in foreground while user is waiting Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Major Priority: P5 - None Component: Usability AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: suse@tlinx.org QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 This has gone from bad to worse. One hopes things will get better, but this is one thing that has not. To generate 1 font-cache takes over 4 minutes: # time gvim -c q 279.20sec 0.06usr 0.02sys (0.02% cpu) --- Worse -- it does it "by surprise" the next time an admin tries to edit a file. It forces them to wait, at almost 5 minutes to over 10 minutes if they have not gone through and uninstalled the entire 32-bit font tool chain (which I did because I don't use or need it). There are multiple issues here. 1) why are there 2 arch-dependent caches for *arch-independent* data (another but is already filed on this but has been ignored. 2) the Fonts are regenerated at the worst time in the worst way -- while the user is waiting and they are blocking the user's next task. I'm not sure why the fonts are regenerating now...oh , I know why I ran a dup-check on the font dir and was meaning to run a redundant name check (but the dup-check which found 2 new duplicate files caused this, I'm sure). I made a special inquiry into what fontconfig needed for it to rerun its cache update -- so I could run it manually ***in background*** while I did other things. It took about 5 minutes (didn't time it).. . But later I had to make a 2 line change to a config file as root -- and got hit with the 5 minute regen again. It's not like you have a choice to put it in background or put it off. It forces the reconfig on you -- stopping all work for the next 5-10 minutes. This reconfig is unacceptably long. What makes it worse (besides it's bad timing), is that if you have the default installs, you spend 10 minutes/font x ~100+ font updates = 1000 minutes or almost 17 hours just to install the fonts in an update. I can't be low key about this -- it is one of the most broken systems I've ever seen in font management. Those same font updates could all be done in 1 batch with out regenerating the cache between each one. When the install is complete, a batch job could be started to regenerate the font cache -- It's likely the user wouldn't even notice the slowdown. The caveat to the user is they can't use newly installed fonts until the reconfig (which will take 5-10+ minutes for the 100 fonts (same time it takes for 1 font). But they could still edit with the old fonts. The major take-away in this bug -- the users should never get a "*surprise*!" 10 minute wait when trying to update a text file. That is an unacceptable system response time to bring up a text editor. (that the font generation takes so long (even for 1 arch (32v.64) is another another problem but likely needs it's own bug. Reproducible: Always Steps to Reproduce: 1.write a cron job to touch /usr/share/fonts/TTF. 2. Notice how root gets completely locked out of the editor -- FOREVER. 3. This is a great way to create a denial of service that locks root out from invoking an editor. Actual Results: Root is locked out of editing. Denial of service. Expected Results: No delay in root bringing up an editor. This is a borderline security issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.