Bug 355231 - stopping irqbalance failed message always appears during shutdown
Summary: stopping irqbalance failed message always appears during shutdown
Alias: None
Product: Fedora
Classification: Fedora
Component: irqbalance
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
: 377581 380371 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-27 14:15 UTC by Brian G. Anderson
Modified: 2008-11-26 17:36 UTC (History)
13 users (show)

Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-26 17:36:48 UTC

Attachments (Terms of Use)

Description Brian G. Anderson 2007-10-27 14:15:07 UTC
Description of problem:
I have a Dell D620 which starts with no unusual messages (it stays in graphics
mode).  However when I shutdown,  I get a FAIL message when trying to stop

Sure enough, when I start my machine and log in:  service irqbalance reports
"irqbalance dead but subsys locked".  However, if I stop irqbalance and restart
it, it seems to work fine.  I can't find anything in /var/log/messages from
irqbalance: no startup, stop or fail messages.

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

How reproducible:
every shutdown.

Steps to Reproduce:
1.start system
2.shut it down.
Actual results:

Expected results:

Additional info:

Comment 1 Ulrich Drepper 2007-10-31 23:44:17 UTC
The reason for this message is that irqbalance almost immediately terminates
itself when the system has less than two cores or only one cache domain.

I.e., for instance, a simple dual core Intel processor will not see irqbalance
running.  An Intel quad core machine will since the two groups of dual cores
share no caches.  All SMP machines will have irqbalance running, too.

So, the termination is no problem but I also very much dislike the error message
on shutdown.  What irqbalance should do is to write out the PID into a file. 
The file is removed when the program exits.  So, if the exit happens voluntarily
the PID file is gone and the stop routine in the /etc/init.d/irqbalance file
could check for that.  If the file is not available anymore, don't do anything.

Comment 2 Neil Horman 2007-11-02 20:06:26 UTC
I've placed a test srpm on http://people.redhat.com/nhorman with a fix for this.
 If you could confirm that its solves the problem for you Brian, I would
appreciate it.  Thanks!

Comment 3 Brian G. Anderson 2007-11-02 22:11:46 UTC
I get an error trying to "rpmbuild -bb SPEC/irqbalance.spec after installation".
 Am I doing something wrong?

cc -g -Os -D_FORTIFY_SOURCE=2 -Wall -W `pkg-config --cflags glib-2.0`    -c -o
irqbalance.o irqbalance.c
irqbalance.c: In function 'main':
irqbalance.c:94: warning: comparison between signed and unsigned
In function 'open',
    inlined from 'main' at irqbalance.c:89:
/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared
with attribute error: open with O_CREAT in second argument needs 3 arguments
make: *** [irqbalance.o] Error 1

Comment 4 Ulrich Drepper 2007-11-02 23:20:52 UTC
Add a third parameter 0666 to the open call.

Comment 5 Brian G. Anderson 2007-11-03 18:19:59 UTC
I fixed the patch file to do the proper open call and it worked fine.  No more
FAILED message.

Comment 6 Neil Horman 2007-11-05 11:40:44 UTC
odd, open has a variant that allows you to call it without explicit permissions.
 It builds fine for me with out the additional permissions setting.  In any
case, I'm checking this into the devel branch.  Thanks!

Comment 7 Ulrich Drepper 2007-11-05 15:28:24 UTC
(In reply to comment #6)
> odd, open has a variant that allows you to call it without explicit permissions.
>  It builds fine for me with out the additional permissions setting.

This is because you use an older build system.  In F8 we have more fortification
functionality.  One of the features is to test for missing open arguments and
this is your code:

        pidf = open("/var/run/irqbalance.pid",O_RDWR|O_CREAT|O_EXCL);

Yes, open can in some situations be used with only two arguments.  But if
O_CREAT is passed the third argument is mandatory.  This is what the new
functionality enforces.  Failing to provide the third parameter can lead to
security problems.

BTW, the third argument should in reality be S_IRUSR|S_IWUSR and not 0666 as I
suggested earlier.  That was without looking at the sources, just to keep things

Another nit: you can make the code more compact: instead of the snprintf and
subsequent write call just use

  if (dprintf (pidf, "%ld", (long) getpid ()) < 0) {
    error(EXIT_FAILURE, errno, "cannot create PID file");

Note, I also added an error message.  The key is to use dprintf which is like
fprintf but prints to a file descriptor.

Comment 8 Mike Cohler 2007-11-10 22:41:41 UTC
In the meantime before a fixed version is pushed to updates
service irqbalance off
for uniprocessor f8 machines gets rid of the shutdown message.

Comment 9 Mike Cohler 2007-11-10 22:42:31 UTC
I should have said in #8
chkconfig irqbalance off

Comment 10 Ulrich Drepper 2007-11-10 23:18:04 UTC
(In reply to comment #8)
> for uniprocessor f8 machines gets rid of the shutdown message.

This is not advisable for all uni-processor machines.  For some quad cores
(e.g., Intel's Merom quad cores) irqbalance is needed since the two sets of two
cores each have no common cache.

Comment 11 Olivier Baudron 2007-11-12 16:57:49 UTC
*** Bug 377581 has been marked as a duplicate of this bug. ***

Comment 12 William Lovaton 2007-11-12 20:08:41 UTC
Ok, according to what Ulrich said in comment #1, it's not weird that I see this
bug on my Dell XPS M1210 laptop, my old Athlon XP 2000+ home desktop and my new
HP Celeron desktop at work.

I hope the updated package hit updates soon.


Comment 13 Will Woods 2007-11-13 22:03:47 UTC
*** Bug 380371 has been marked as a duplicate of this bug. ***

Comment 14 Steve Alexander 2007-11-26 19:06:21 UTC
There appear to be several related bugs in irqbalance.init

The network test
   26   # Check that networking is up.
   27   if [ "$NETWORKING" = "no" ]
   28   then
   29           exit 0
   30   fi
seems to be a cut&paste-ism.   irqbalance should not be dependent on the
network.  Should be removed.

The test in start:
   48   start() {
   49           if [ -n "$ONESHOT" -a -f /var/run/irqbalance.pid ]; then
   50                   exit 0
   51           fi

means that a duplicate start is only prevented when both ONESHOT is specified
AND the daemon is running.  This makes no sense.  I believe the first test term
[ -n "$ONESHOT ] is incorrect and the second term [ -f /var/run/irqbalance.pid ]
 duplicates the test that is now performed in the new patch where the file is
opened with "O_CREAT|O_EXCL".   I believe the entire "if ... fi" clause should
be removed.

Comment 15 Bug Zapper 2008-04-04 14:18:59 UTC
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 16 Bug Zapper 2008-11-26 08:07:06 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 17 Jon Stanley 2008-11-26 17:36:48 UTC
As this bug is in MODIFIED, Fedora believes that a fix has been committed that resolves the problem listed in this bug report.

If this is not the case, please re-open this report, noting the version of the package that you reproduced the bug against.

Thanks for the report!

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