There is a rather serious bug in chkfontpath, which executes as part of an
attempt to send SIGUSR1 to xfs to force it to reload it's config file.  The bug
causes SIGUSR1 to also be sent to PID 2.  Here is the releavant broken code:
 
void restartXfs()
{
  struct stat st;
  /*  pid_t pid, wst;*/
 
  /* Stat /proc/version to see if /proc is mounted. */
  if (stat("/proc/version", &st) == 0) {
 
    /* It's there, we can do the pidof w/o fear of mounting /proc. */
    system("kill -USR1 `/sbin/pidof xfs` 2&1>/dev/null");
  }
}
 
system() above evaluates to:
 
kill -USR1 `/sbin/pidof xfs` 2  &  1>/dev/null
 
Which has the effect of USR1'ing PID 2 along with xfs, and running it in the
background.  PID 2 is almost certainly always going to be a kernel thread, which
means a random kernel thread is getting sent SIGUSR1 every single time
chkfontpath is executed.  This could potentially cause all sorts of problems
depending on how the receiving kernel thread handles SIGUSR1.
 
PID 2 on some of my machines here is:
 
 2 ?        SW     0:00 [migration_CPU0]
 2 ?        SW     0:00 [kflushd]

<pknirsch> root         2  0.0  0.0     0    0 ?        SW   May05   0:01 [keventd]
 
There is no knowing what if any problems may have been caused on live systems
because of this bug, but in my opinion it is serious enough to warrant an
erratum release of chkfontpath on all supported OS platforms that are affected.