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 irqbalance. 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): irqbalance-0.55-6.fc8 How reproducible: every shutdown. Steps to Reproduce: 1.start system 2.shut it down. 3. Actual results: Expected results: Additional info:
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.
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!
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
Add a third parameter 0666 to the open call.
I fixed the patch file to do the proper open call and it worked fine. No more FAILED message.
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!
(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 rolling. 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) { close(pidf); unlink("/var/run/irqbalance.pid"); 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.
In the meantime before a fixed version is pushed to updates service irqbalance off for uniprocessor f8 machines gets rid of the shutdown message.
Apologies I should have said in #8 chkconfig irqbalance off
(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.
*** Bug 377581 has been marked as a duplicate of this bug. ***
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. Thanks.
*** Bug 380371 has been marked as a duplicate of this bug. ***
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.
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 rawhide. (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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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!