Red Hat Bugzilla – Bug 133451
/etc/init.d/xfs buildfontlist(): fc-cache is not run when necessary
Last modified: 2007-11-30 17:10:49 EST
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
fc-cache is only run if the last iteration of the loop encountered a
directory that needs to be regenerated.
Any regenerated directory should trigger fc-cache
See attached patch.
Created attachment 104242 [details]
Fix for this problem
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
Created attachment 111826 [details]
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.
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).
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.
Feedback from the Fedora community indicates this issue seems to be
Setting status to RAWHIDE.
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.