Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 176444 - chkfontpath should check for running xfs before killing it
Summary: chkfontpath should check for running xfs before killing it
Alias: None
Product: Fedora
Classification: Fedora
Component: chkfontpath
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: Ben Levenson
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2005-12-22 21:17 UTC by Ralf Ertzinger
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 1.10.1-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-16 14:03:12 UTC

Attachments (Terms of Use)

Description Ralf Ertzinger 2005-12-22 21:17:47 UTC
Description of problem:
I yesterday updated a whole bunch of packages and thus had run yum in single
user mode (to reduce the number of running programs). Every time chkfontpath was
run a message popped up explaining the usage of "kill". I think this is due to
the following line from chkfontpath (extracted with strings):

kill -USR1 `/sbin/pidof xfs` 2>&1 >/dev/null

This of course fails if no xfs is actually running. Maybe using "killall -q -s
USR1 xfs" would have the same effect?

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

How reproducible:

Steps to Reproduce:
1. Update any package calling chkfontpath in it's %scripts without xfs running
Actual results:
Message about invalid "kill" usage

Expected results:
no error messages

Additional info:

Comment 1 Mike A. Harris 2006-02-01 02:23:26 UTC
Hrm...   Perhaps checking for the pid file, parsing it, and then testing
the pid would work better.  That would be a bit racey though, and there's
no guarantee that the pid pointed to by the pid file is actually still
xfs (ie: xfs crashes, some other app runs and gets the same pid)

Adding to FC5Target for closer review for FC5.

Thanks for the report.

Comment 2 Mike A. Harris 2006-02-16 13:52:46 UTC
"kill -q" does not exist, at least not on FC1 or FC4 on my systems, neither
in the manpage nor usage() info for kill

Here is the current code:

void restartXfs(void)
  struct stat st;
  FILE *pidfile;
  pid_t pid;
  char buf[MAXPIDBUF];

  /* Make sure /proc is mounted, and /sbin/pidof exists */
  if ((stat("/proc/version", &st) == 0) && (stat("/sbin/pidof", &st) == 0)) {
    system("kill -USR1 `/sbin/pidof xfs` 2>&1 >/dev/null");
  /* If not, then test if xfs subsystem is locked, and there is a pid file */
  } else if ((stat(XFS_SUBSYSLOCK, &st) == 0) && (stat(XFS_PIDFILE, &st) == 0)) {
    if (NULL != (pidfile = fopen(XFS_PIDFILE, "r"))) {
      fgets(buf, sizeof(buf), pidfile);
      if(NULL != buf)
        pid = (pid_t) atol(buf);
      if(pid > 1)
        kill(pid, SIGUSR1);

The current method favours invoking the kill command if /proc is mounted,
so that it's getting the PID of a running xfs server, but falls back to
using the xfs pid file if /proc is not mounted, so it seems it already can
do what I suggested in comment #1, but only if /proc isn't there.

It appears the problem is due to the ordering of the commandline passed
to kill:

    system("kill -USR1 `/sbin/pidof xfs` 2>&1 >/dev/null");

should instead be:

    system("kill -USR1 `/sbin/pidof xfs` >/dev/null 2>&1");


pts/7 mharris@laser:/tmp/xfs-1.0.1/os$ ls io.c sdfasdf
/bin/ls: sdfasdf: No such file or directory
pts/7 mharris@laser:/tmp/xfs-1.0.1/os$ ls io.c sdfasdf 2>&1 >/dev/null
/bin/ls: sdfasdf: No such file or directory
pts/7 mharris@laser:/tmp/xfs-1.0.1/os$ ls io.c sdfasdf >/dev/null 2>&1
pts/7 mharris@laser:/tmp/xfs-1.0.1/os$

I'm committing this change to chkfontpath CVS, and it'll be in the next build.

Comment 3 Mike A. Harris 2006-02-16 14:03:12 UTC
Fixed in 1.10.1-1 and built in rawhide.

Comment 4 Ralf Ertzinger 2006-02-16 14:09:15 UTC
The "-q" is valid for killall only. But if a simple reordering of output
redirections has the same effect that's fine, too.

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