openipmi startup script removes kernel modules
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openipmi (Ubuntu) |
Fix Released
|
High
|
Nish Aravamudan | ||
Trusty |
Fix Released
|
High
|
Unassigned |
Bug Description
I need some IPMI kernel modules, so I load them during startup. This worked quite well until I upgraded to Ubuntu 14.04.
As you can see I have the modules in /etc/modules:
# grep ipmi /etc/modules
ipmi_watchdog
ipmi_devintf
ipmi_poweroff
ipmi_si
Right after reboot, the modules are there:
# lsmod |grep -i ipm
ipmi_si 53257 2
ipmi_poweroff 14366 0
ipmi_devintf 17572 0
ipmi_watchdog 24912 0
but disappear after a few seconds/minute. I found out, that the cause is the /etc/init.
I loaded the modules manually using modprobe:
ipmi_si 53257 2
ipmi_poweroff 14366 0
ipmi_devintf 17572 0
ipmi_watchdog 24912 0
when I execute:
# service openipmi stop
the module ipmi_devintf gets removed:
ipmi_si 53257 2
ipmi_poweroff 14366 0
ipmi_watchdog 24912 0
starting the service again with:
# service openipmi start
will remove ALL IPMI kernel modules:
# lsmod |grep -i ipm
#
One of the reasons seems to be the module ipmi_msghandler. This is already integrated and causes some of the problems.
When I remove it from /etc/init.
65,66c65
< #MODULES_
< MODULES_BASE=""
---
> MODULES_
325,326c324,325
< # modprobe ipmi_msghandler > /dev/null 2>&1
< # modules_loaded ipmi_msghandler
---
> modprobe ipmi_msghandler > /dev/null 2>&1
> modules_loaded ipmi_msghandler
stoping and starting the service works again. But restarting the service will still remove all modules and will not load them anymore.
[Impact]
Issuing `service openipmi {start,
[Test Case]
On an OpenPower machine (this also happens on an appropriately configured (meaning without IPMI support) Intel qemu instance), load IPMI modules (in particular, ipmi_devintf, but any of them can be affected). Attempt to start the openipmi service with `service openipmi start`. Without the fix proposed, here, the ipmi_devintf module is unloaded. With the fix, the module stays loaded.
[Regression Potential]
The primary risk of regression is if an end-user was relying on the behavior of an error during openipmi initialization resulting in disabling of all IPMI functionality. I don't think that is reasonable behavior to rely on, though (and is not clearly documented anywhere as expected).
Changed in openipmi (Ubuntu): | |
assignee: | nobody → Taco Screen team (taco-screen-team) |
Changed in openipmi (Ubuntu): | |
importance: | Undecided → High |
Changed in openipmi (Ubuntu): | |
assignee: | Taco Screen team (taco-screen-team) → Nish Aravamudan (nacc) |
Changed in openipmi (Ubuntu): | |
milestone: | none → ubuntu-16.04 |
description: | updated |
Changed in openipmi (Ubuntu Trusty): | |
status: | New → Triaged |
importance: | Undecided → High |
This affects me, too. After boot, the necessary ipmi_{si,devintf} modules aren't loaded, so ipmitool and related monitoring doesn't work.
However this bug cannot possibly be in the "ejabberd" package, so I'm reassigning it to "openipmi".