Bug 133451

Summary: /etc/init.d/xfs buildfontlist(): fc-cache is not run when necessary
Product: [Fedora] Fedora Reporter: Hans Ecke <hansecke>
Component: xorg-x11Assignee: Mike A. Harris <mharris>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-08 10:13:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 74398, 136450, 136451    
Attachments:
Description Flags
Fix for this problem
none
Patch none

Description Hans Ecke 2004-09-24 02:18:03 UTC 
Description of problem:

The shell function buildfontlist() has a logical flaw. In the "for d
in $()" loop, the variable REGEN_FONTS_DIR is reset each time to "no"
and set to "yes" if that particular directory needs to be regenerated.
fc-cache is run afterwards if _any_ directory was regenerated. But
what happens if the very first iteration of the loop regenerated the
directory, but all subsequent ones didn't? The test [ 
$REGEN_FONTS_DIR" = "yes" ] will not trigger because the later
iteration of the loop reset the variable to "no".

Version-Release number of selected component (if applicable):

All from RH9 through the latest

Actual results:

fc-cache is only run if the last iteration of the loop encountered a
directory that needs to be regenerated.

Expected results:

Any regenerated directory should trigger fc-cache

Additional info:

See attached patch.
Comment 1 Hans Ecke 2004-09-24 02:18:51 UTC 
Created attachment 104242 [details]
Fix for this problem
Comment 2 Hans Ecke 2004-09-24 06:33:36 UTC 
Actually, it might be cleaner to change the above patch to have the "REGEN_ANY=yes" be in only one place: after 
   if [ "$REGEN_FONTS_DIR" = "yes" ]; then

This way, it should be easier to maintain
Comment 5 Søren Sandmann Pedersen 2005-03-09 22:35:46 UTC 
Created attachment 111826 [details]
Patch

This patch is an attempt at fixing both 133451 an 133453, plus generally
speeding up the xfs initscript. What it does is

 - Always run fc-cache whether or not anything changed. If the fontconfig cache

   is already uptodate, fc-cache is very fast - basically it only stat()s the
   directories and the fonts.cache files, so no point trying to be clever.

 - Check the mtime of font directories and the fonts.dir files, and only 
   regenerate the fonts.* files in that case. 

 - Whenever we do generate the fonts.dir file, set the mtime of fonts.cache-*,
   fonts.dir and the font directory to the same value. A cheesy hack to
   make sure the various metadata generators don't step on each other's toes. 

This should fix both bugs, and avoid the find/grep/ls statting every font
file on startup.

Note that the shell "-nt" test returns true both if mtime is newer and if the
second file does not exist.
Comment 6 Søren Sandmann Pedersen 2005-03-10 15:02:59 UTC 
I believe this patch also fixes bug 74398.

(Also, I realized that it probably isn't going to make any real
performance difference since find/ls/grep is not actually stat()ing
the individual files - it only reads the directories).
Comment 7 Mike A. Harris 2005-04-04 23:51:28 UTC 
Me and Soeren discussed this bug, and his proposed patch today for
a while, and ran through different scenarios.  I decided to
simplify the initscript as much as possible, to reduce complexity
without changing operation extensively, and at the same time trying
to avoid introducing new regressions or other issues.

This basically removes all of the REGEN_FONTS_DIR stuff by putting
that logic directly in the if statement which was the main use.

We now run fc-cache always, since it runs very fast anyway, and fonts
may have been added/removed/changed in fontconfig configured directories
which are not even configured in xfs.  fc-cache internally searches
the directories fontconfig is configured to use, rather than the dirs
xfs is configure to use, which is what we were attempting to do before.
For dirs fontconfig is configured to use, fc-cache will regen the
fonts.cache* files only if necessary, which achieves what we really
were wanting to begin with, but in a more sensible manner.

A couple of other cleanups I made should speed up xfs initscript a slight
bit also in some cases.

The end result, should be that this bug is no longer present, fc-cache
is now ran to ensure all fontconfig configured font directories have their
cache files updated, wether or not mkfontdir et al. were ran, and this
will have more likelyhood of improving the performance of client side
fonts as well.

I have not committed the new initscript to CVS yet, as I'd like you to
test it with your setup first:  ftp://people.redhat.com/mharris/xfs.init

Please test that, and update the bug report to indicate if you see any
regressions or other problems.

Thanks in advance.


Setting status to "NEEDINFO", awaiting test results.
Comment 10 Mike A. Harris 2005-04-08 10:13:33 UTC 
Feedback from the Fedora community indicates this issue seems to be
resolved.

Setting status to RAWHIDE.
Comment 11 Fedora Update System 2005-09-16 21:25:19 UTC 
From User-Agent: XML-RPC

xorg-x11-6.8.2-1.FC3.45 has been pushed for FC3, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.