Bug 16037

Summary:	System freeze on access to /usr/share/fonts directory
Product:	Mageia	Reporter:	Len Lawrence <tarazed25>
Component:	Release (media or process)	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Normal	CC:	sysadmin-bugs, thierry.vignaud
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	fontconfig?	CVE:
Status comment:

Description Len Lawrence 2015-05-25 00:40:40 CEST

Description of problem:
For a while now I have been experiencing what seemed to be random freezes of the desktop soon after installation but it has become apparent that the freezes (no mouse or keyboard response) occur only when there is access to the fonts directories in /usr/share.  As far as I can tell, generalising from two other share directories everything else is normal.  One of my housekeeping tasks after an install is to populate the fonts/default/ghostscript directory with a number of Type1 files for use with Postscript, usually via a tar file operating as root.  The cp or tar xf commands appear to work and then the freeze happens.  Crash reboot and the journal file is wiped out.  Nothing in dmesg.  Logged back in the user can see the new file(s).  To find out how widespread this behaviour is I copied a dummy text file to /, /usr, /usr/share and /usr/share/fonts.  Only the last one caused the freeze and after reboot removing it also caused the freeze.

My guess is that Cauldron is enforcing some kind of censorship at a level users do not know about, although it is puzzling that the action succeeds and then the system falls over.  The fault occurs with su or sudo. 

Version-Release number of selected component (if applicable):
5 final, but rc versions as well

How reproducible:
Every time there is a write or removal in the /usr/share/fonts tree.

Steps to Reproduce:
1. Copy any file to /usr/share/fonts/....
2.
3.


Reproducible: 

Steps to Reproduce:

Comment 1 Len Lawrence 2015-05-25 00:57:04 CEST

This happens with drakfont also.  A whole folder-full of TTFs installed and the system froze.  Using drakfont with a single file install had the same result.

This does not occur in Mageia 4.

Now, I should test this on other machines.

Comment 2 Thierry Vignaud 2015-05-25 08:52:28 CEST

Corrupted font...?

CC: (none) => thierry.vignaud

Comment 3 Len Lawrence 2015-05-25 11:20:05 CEST

No.  All the newly installed fonts come up correctly in X.  The sort of errors which came out of ttf2pt1 on Mageia 4 installs also show up in Cauldron but the fonts are usable.  type1inst works and the dummy text file I used has nothing to do with fonts but still caused the freeze.  The procedure I use has not varied over many dozens of installations going back years.

Comment 4 Thierry Vignaud 2015-05-25 11:25:31 CEST

Then the latest fontconfig doesn't like what happens.
Are you sure you do not overwrite some files?
fontconfig historically doesn't like it

Source RPM: (none) => fontconfig?

Comment 5 Len Lawrence 2015-05-25 12:07:57 CEST

Aha!  Yes, the tar file is a snapshot of the ghostscript directory including the fonts installed by the system.  It looks like I need to prune the tar file or maybe install a few fonts at a time via drakfont or copying on a virgin install.

Comment 6 Thierry Vignaud 2015-05-25 12:43:40 CEST

overwritting font files mapped by fontconfig is a known crasher...

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Comment 7 Len Lawrence 2015-05-25 13:06:37 CEST

So fontfig lurks in the background and expects any new file to be something to do with fonts?  I wonder how it interprets dummy.txt?  That certainly does not overwrite any font files.

Resolution: INVALID => FIXED

Comment 8 Len Lawrence 2015-05-25 13:51:33 CEST

What would be preferable would be to use the processed fonts (*.afm *.pfb) from the user directory.  Initially I tried that with GS_FONTDIR pointing to my local font files but they were not seen even after type1inst.  Don't know what else has to be done.

Comment 9 Len Lawrence 2015-05-25 16:45:51 CEST

Since this problem is caused by a known (and accepted) behaviour of fontconfig this bug should be closed as invalid.

Comment 10 Thierry Vignaud 2015-05-25 17:34:50 CEST

Which I did but you reversed it...

Resolution: FIXED => INVALID