There seems to be a bug in the script which starts X font server -
/etc/init.d/xfs. The bug reveals itself when root's umask does not give
other users read permission (i.e. 027). More specifically, after a
function buildfontlist() makes font directory it should
chmod a+r fonts.dir
chmod a+r fonts.scale ( if present )
Alas, it only does chmod +r, which is not enough, since man chmod reads:
If none of the letters 'ugoa' are given, the effect is as if `a' were
given, but bits that are set in the umask are not affected.
In effect, xfs in -droppriv mode is unable to access aforementioned files
and does not start at all. What makes thing worse is that in -daemon mode
it still returns success regardless of what happened. So the poor novice
who tampered with root's umask sees:
Starting X Font Server: [ OK ]
The only symptom is that X refuses to start:
Could not init font path element unix/:7100, removing from list!
Fatal server error:
could not open default font 'fixed'
Ouch! But there is more to come.
# xfs -droppriv
FontCacheInitialize: hi=1048576, lo=786432, bal=70
xfs error: Element #1 (starting at 0) of font path is bad or has a
Nothing strange, except that /usr/X11R6/lib/X11/fonts/misc/ is OK in this
case. It's just the message that always points to element #1. Needless to
say, this makes debugging a bit more frustrating.
In case these bugs were unreported up to date, you owe me a T-shirt.
Steps to Reproduce:
1. set root's umask to 027
2. add a new font file or whatever so that buildfontlist() is needed
3. run service start xfs
Actual Results: see description
Expected Results: see description
gosh, it is supposed to be EASY bug form. Instead of sending one email I
had to create new account, and wade through a plethora of webpages. I know
it is all supposed to make developers' life easier, but for god's sake,
hadn't I been determined to report a bug I would give up ages ago.
Update: and all that to fill in simple form...
This has been fixed long ago, sorry no tee shirt. ;o)