Bug 819234 - systemd should not start ipmitool's ipmievd until the OpenIPMI driver has been installed
systemd should not start ipmitool's ipmievd until the OpenIPMI driver has bee...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ipmitool (Show other bugs)
16
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jan Safranek
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-05 16:38 EDT by Andrew J. Schorr
Modified: 2013-02-13 20:23 EST (History)
2 users (show)

See Also:
Fixed In Version: ipmitool-1.8.11-9.fc16 ipmitool-1.8.11-11.fc17 ipmitool-1.8.11-11.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 20:23:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch ipmievd.service to start after ipmi.service (317 bytes, patch)
2012-05-22 09:29 EDT, Andrew J. Schorr
no flags Details | Diff
Patch ipmievd.service to work properly (462 bytes, patch)
2012-08-02 10:49 EDT, Andrew J. Schorr
no flags Details | Diff

  None (edit)
Description Andrew J. Schorr 2012-05-05 16:38:58 EDT
Description of problem:
In Fedora 16, the OpenIPMI rpm installs /etc/rc.d/init.d/ipmi to load the driver.
But the ipmitool rpm uses a new systemd ipmievd.service unit that fails to
declare a dependency on this driver.  As shipped, systemd is starting ipmievd 
before loading the driver, so it fails.

Version-Release number of selected component (if applicable):
ipmitool-1.8.11-8.fc16.src.rpm

How reproducible:
chkconfig --add ipmi
systemctl enable ipmievd.service

Steps to Reproduce:
1. chkconfig -add ipmi
2. systemctl enable ipmievd.servide
3. reboot
  
Actual results:
ipmievd fails to start and gives an error: Could not open device at /dev/ipmi0 or /devipmi/0 or /dev/ipmidev/0: No such file or directory

Expected results:
Should start properly

Additional info:
Comment 1 Jan Safranek 2012-05-22 09:15:16 EDT
I don't have IPMI enabled Fedora machine at hand, so I'll do it just blindly. Please create following /etc/systemd/system/ipmievd.service and let me know if it gets better:

[Unit]
After=ipmi.service

.include /lib/systemd/system/ipmievd.service



I'll update the package when you confirm this workaround helps. Thanks in advance.
Comment 2 Andrew J. Schorr 2012-05-22 09:29:26 EDT
Created attachment 586036 [details]
Patch ipmievd.service to start after ipmi.service

The attached patch fixed the problem for me.  I hope that provides the
necessary information.

Thanks,
Andy
Comment 3 Fedora Update System 2012-05-22 10:57:54 EDT
ipmitool-1.8.11-9.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/ipmitool-1.8.11-9.fc16
Comment 4 Fedora Update System 2012-07-24 19:32:52 EDT
Package ipmitool-1.8.11-9.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ipmitool-1.8.11-9.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11068/ipmitool-1.8.11-9.fc16
then log in and leave karma (feedback).
Comment 5 Fedora Update System 2012-08-01 18:26:49 EDT
ipmitool-1.8.11-9.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 6 Andrew J. Schorr 2012-08-02 10:48:45 EDT
Hi,

I just installed the updated package ipmitool-1.8.11-9.fc16, but it 
does not work properly.  I see that the following patch was applied
to the ipmievd.service file:

--- old/ipmievd.service 2011-12-13 08:04:37.000000000 -0500
+++ new/ipmievd.service 2012-05-22 10:29:25.000000000 -0400
@@ -1,10 +1,13 @@
 [Unit]
 Description=Ipmievd Daemon 
 After=syslog.target
+After=ipmi.service
 
 [Service]
 EnvironmentFile=-/etc/sysconfig/ipmievd
 ExecStart=/usr/sbin/ipmievd $IPMIEVD_OPTIONS
+Type=forking
+PIDFile=/var/run/ipmievd.pid0
 
 [Install]
 WantedBy=multi-user.target

Why was the Type set to forking, etc.?  Only the first change was required.
The service now fails to start intermittently, and a restart fails after
hanging for 90 seconds:

[root@ti18 ~]# systemctl status ipmievd.service
ipmievd.service - Ipmievd Daemon
          Loaded: loaded (/lib/systemd/system/ipmievd.service; enabled)
          Active: failed since Thu, 02 Aug 2012 10:33:06 -0400; 6min ago
         Process: 2986 ExecStart=/usr/sbin/ipmievd $IPMIEVD_OPTIONS (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/ipmievd.service

[root@ti18 ~]# time systemctl restart ipmievd.service
Job failed. See system logs and 'systemctl status' for details.

real    1m30.051s
user    0m0.000s
sys     0m0.001s

Removing those other changes fixes the problem.  Can you please revert
that part of the patch?

Thanks,
Andy
Comment 7 Andrew J. Schorr 2012-08-02 10:49:44 EDT
Created attachment 601974 [details]
Patch ipmievd.service to work properly

This patch removes the "Type=forking" and PIDFile lines that were added to the ipmievd.service file.  It works again after removing those lines.
Comment 8 Jan Safranek 2012-08-03 04:50:34 EDT
(In reply to comment #6)
> +++ new/ipmievd.service 2012-05-22 10:29:25.000000000 -0400
> @@ -1,10 +1,13 @@
>  [Unit]
>  Description=Ipmievd Daemon 
>  After=syslog.target
> +After=ipmi.service
>  
>  [Service]
>  EnvironmentFile=-/etc/sysconfig/ipmievd
>  ExecStart=/usr/sbin/ipmievd $IPMIEVD_OPTIONS
> +Type=forking
> +PIDFile=/var/run/ipmievd.pid0
>  
>  [Install]
>  WantedBy=multi-user.target
> 
> Why was the Type set to forking, etc.?  Only the first change was required.
> The service now fails to start intermittently, and a restart fails after
> hanging for 90 seconds:

The change was fix for bug #807757, with type=simple systemd doesn't report failure when ipmievd is starting on system without /dev/ipmi.

Question is, why it takes so much time on your system. can you please look what takes so long, e.g. using strace -ttt /usr/sbin/ipmievd sel daemon pidfile=/var/run/ipmievd.pid ? I don't have IPMI machine with Fedora with systemd at hand.
Comment 9 Jan Safranek 2012-08-03 09:13:18 EDT
I finally found some machine.

Indeed, the type=forking does not work, systemd does not understand the way how ipmievd forks. I am sorry I broke running system.

I implemented Type=notify support to ipmievd, now I am waiting for upstream acceptance at http://thread.gmane.org/gmane.comp.hardware.ipmitool.devel/2079
Comment 10 Fedora End Of Life 2013-01-16 17:51:55 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. 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 '16'.

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 16'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 16 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, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

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
Comment 11 Fedora End Of Life 2013-02-13 20:23:10 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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