Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 469190 - Error upgrading fonts packages. %post script failed
Error upgrading fonts packages. %post script failed
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: fontconfig (Show other bugs)
All Linux
high Severity medium
: rc
: ---
Assigned To: Marek Kašík
Desktop QE
: 248125 (view as bug list)
Depends On:
Blocks: 719046 743405 668957
  Show dependency treegraph
Reported: 2008-10-30 10:41 EDT by Alexander Todorov
Modified: 2012-07-20 09:14 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-12-23 10:25:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch based on upstream git commit db6f19f1 (10.82 KB, patch)
2010-10-05 07:26 EDT, Olivier Fourdan
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Legacy) 41094 None None None Never

  None (edit)
Description Alexander Todorov 2008-10-30 10:41:35 EDT
Description of problem:
During upgrade from 5.2 to 5.3 snap #1 with Anaconda several font packages produced errors:

Upgrading fonts-tamil-2.3.1-1.el5.noarch
error: %post(fonts-tamil-2.3.1-1.el5.noarch) scriptlet failed, exit status 1
Upgrading fonts-bengali-2.3.1-1.el5.noarch
error: %post(fonts-bengali-2.3.1-1.el5.noarch) scriptlet failed, exit status 1
Upgrading fonts-gujarati-2.3.1-1.el5.noarch
error: %post(fonts-gujarati-2.3.1-1.el5.noarch) scriptlet failed, exit status 1
Upgrading fonts-punjabi-2.3.1-1.el5.noarch
error: %post(fonts-punjabi-2.3.1-1.el5.noarch) scriptlet failed, exit status 1
Upgrading fonts-kannada-2.3.1-1.el5.noarch
error: %post(fonts-kannada-2.3.1-1.el5.noarch) scriptlet failed, exit status 1
Upgrading fonts-oriya-2.3.1-1.el5.noarch
error: %post(fonts-oriya-2.3.1-1.el5.noarch) scriptlet failed, exit status 1
Upgrading fonts-hindi-2.3.1-1.el5.noarch
error: %post(fonts-hindi-2.3.1-1.el5.noarch) scriptlet failed, exit status 1
Upgrading fonts-malayalam-2.3.1-1.el5.noarch
error: %post(fonts-malayalam-2.3.1-1.el5.noarch) scriptlet failed, exit status 1
Upgrading fonts-telugu-2.3.1-1.el5.noarch
error: %post(fonts-telugu-2.3.1-1.el5.noarch) scriptlet failed, exit status 1

They all have the following scriptlets:

postinstall scriptlet (using /bin/sh):
[  -x /usr/bin/fc-cache ] && HOME=/ /usr/bin/fc-cache /usr/share/fonts 2> /dev/null

postuninstall scriptlet (using /bin/sh):
if [ "$1" = "0" ]; then
    [  -x /usr/bin/fc-cache ] && HOME=/ /usr/bin/fc-cache /usr/share/fonts 2> /dev/null

/usr/bin/fc-cache is provided by fontconfig which is installed several packages later.

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

How reproducible:

Steps to Reproduce:
1. Install RHEL 5.2 Server @everything
2. Upgrade to 5.3 snap #1 using anaconda
3. Inspect upgrade.log
Actual results:
%post scriptlet fails

Expected results:
No failures

Additional info:
From bash manual page:

command1 && command2
  command2 is executed if, and only if, command1 returns an exit status of zero.

In this case the test for /usr/bin/fc-cache fails because there's no such file and subsequent commands are not executed. The exit code from the test is non zero and rpm thinks it failed. Use if then instead.
Comment 2 Alexander Todorov 2008-11-10 03:14:32 EST
Now I see we were doing an upgrade. This means that fc-cache should be already present on the system.
Comment 3 Ben Levenson 2008-11-12 14:10:45 EST
The scripts in the new packages did not change.  Something else must be going on.
Comment 4 Rahul Bhalerao 2008-11-18 02:47:07 EST
I am trying to reproduce the bug. The odd is that, first, the fontconfig should have been present as it is an upgrade, second even if  it was not, each of these font packages have a dependency for fontconfig.So, it should be able to pull it in any case. Also the scripts have been used since last two updates. Unless there is a problem with the binary path or the cached files. Need to investigate further, as a general update via yum did not reproduce the problem(with and without fontconfig).
Comment 13 Rahul Bhalerao 2009-01-15 07:45:54 EST
The above test reveal that the bug is not only affecting fonts-indic subpackages. It seems its a generic bug concerned with fontconfig or something else. I am not sure what can be written in the release notes for 5.3. But certainly not a bug for fonts-indic.
Comment 14 Lawrence Lim 2009-01-15 07:49:04 EST
Reassign component.
Comment 16 RHEL Product and Program Management 2009-02-17 13:55:36 EST
This bugzilla was reviewed by QE as a non-FasTrack request.
It has since been proposed for FasTrack. The qa_ack has 
been reset. QE needs to re-review this bugzilla for FasTrack.
Comment 18 Alexander Todorov 2009-06-08 09:24:01 EDT
I'm seeing the following error with latesr builds:

Error(s): Installing fontconfig-2.4.1-7.el5.i386
/usr/share/fonts: failed to write cacheerror: %post(fontconfig-2.4.1-7.el5.i386) scriptlet failed, exit status 1

It seems related but the error message is a bit different.
Comment 20 Alexander Todorov 2009-08-21 10:15:27 EDT
Can someone confirm that bug #248125 is a duplicate of this one or not?
Comment 23 Olivier Fourdan 2010-10-05 07:26:40 EDT
Created attachment 451645 [details]
Proposed patch based on upstream git commit db6f19f1

How reproducible:

Always with the reproducer below

Steps to Reproduce:

1. Set the mtime in the future on the font directory:

    # touch -mt 202011050000 /usr/share/fonts/bitstream-vera 

2. Run "fc-cache -f" just like the %post scriptlet does

    # fc-cache -f 

Actual results:

    fc-cache fails with: /usr/share/fonts/bitstream-vera: failed to write cache 

Expected results:

    No failure

Additional info:

The following analysis comes from a strace captured on one of the system where the issue occurred (provided by our customer).

Here follows the relevant part:

  13824 stat("/usr/share/fonts/bitstream-vera", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
  13824 open("/var/cache/fontconfig/e3ead4b767b8819993a6fa3ae306afa9-x86-64.cache-2", O_RDONLY) = 3
  13824 fstat(3, {st_mode=S_IFREG|0644, st_size=10136, ...}) = 0
  13824 close(3)                          = 0
  13824 open("/root/.fontconfig/e3ead4b767b8819993a6fa3ae306afa9-x86-64.cache-2", O_RDONLY) = -1 ENOENT (No such file or directory)
  13824 write(2, "/usr/share/fonts/bitstream-vera: failed to write cache\n", 55) = 55

The message "failed to write cache" comes from scanDirs() if FcDirCacheValid returns FcFalse.

All of this code is conveniently located in a single source file fontconfig/src/fccache.c

FcDirCacheValid() returns the value from FcDirCacheValidConfig() which calls FcDirCacheProcess() using FcDirCacheValidateHelper() as callback.

FcDirCacheProcess() will return FcFalse if:

- stat ((char *) dir, &dir_stat) < 0

  Not the case as seen in the strace.
- FcStrListCreate() returns no list

  Not the case, because we do open/stat files (see below)!
- FcDirCacheOpenFile() will do a open() and fstat(), I think this is what we see here in the trace:

  13824 open("/var/cache/fontconfig/e3ead4b767b8819993a6fa3ae306afa9-x86-64.cache-2", O_RDONLY) = 3
  13824 fstat(3, {st_mode=S_IFREG|0644, st_size=10136, ...}) = 0

  Since the open() succeeded and fstat() returns 0, it is safe to assume that FcDirCacheOpenFile worked.
- (*callback) (fd, &file_stat, closure) returns FcFalse

  Here callback == FcDirCacheValidateHelper and the first thing that function does is a read() and we have no trace of that in the strace, so it's clear that the callback has not been called.

Let's take a look at FcDirCacheProcess() again, from src/fccache.c:

136 static FcBool
 137 FcDirCacheProcess (FcConfig *config, const FcChar8 *dir,
 138                    FcBool (*callback) (int fd, struct stat *stat, void *closure),
 139                    void *closure, FcChar8 **cache_file_ret)
 157     while ((cache_dir = FcStrListNext (list)))
 158     {
 159         FcChar8 *cache_hashed = FcStrPlus (cache_dir, cache_base);
 160         if (!cache_hashed)
 161             break;
 162         fd = FcDirCacheOpenFile (cache_hashed, &file_stat);
 163         if (fd >= 0) {
 164             if (dir_stat.st_mtime <= file_stat.st_mtime)

Here ^^^

 165             {
 166                 ret = (*callback) (fd, &file_stat, closure);
 167                 if (ret)
 168                 {
 169                     if (cache_file_ret)
 170                         *cache_file_ret = cache_hashed;
 171                     else
 172                         FcStrFree (cache_hashed);
 173                     close (fd);
 174                     break;
 175                 }
 176             }
 177             close (fd);
 178         }
 179         FcStrFree (cache_hashed);
 180     }
 181     FcStrListDone (list);
 183     return ret;
 184 }

So *if* the modification time on the directory is the same or later than the modification time on the cache file, then, the callback is not even called. The ret value being initialised to FcFalse, it's the value returned to the caller, thus causing the error.

I believe this is git commit db6f19f1 upstream: 


The attached patch is a (pretty straightforward) backport of this commit upstream.

With this patch, the test case does not fail anymore:

    # touch -mt 202011050000 /usr/share/fonts/bitstream-vera
    # fc-cache -f 
Comment 28 Alexander Todorov 2011-05-25 04:18:03 EDT
*** Bug 703141 has been marked as a duplicate of this bug. ***
Comment 29 Pravin Satpute 2011-06-22 02:59:36 EDT
I have given patch for this issue in Bug 703141, i think better to proceed for Bug 703141 even errata is ready for same.  built with fix is fonts-indic- please test and check is it working or not
Comment 40 RHEL Product and Program Management 2011-12-20 13:37:23 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 42 RHEL Product and Program Management 2011-12-23 10:25:04 EST
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Comment 43 Marek Kašík 2012-07-20 09:14:02 EDT
*** Bug 248125 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.