deferred restarts provide incorrect charm status after machine reboots
Bug #1934521 reported by
Adam Dyess
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Neutron Gateway Charm |
New
|
Undecided
|
Unassigned | ||
| OpenStack Neutron Open vSwitch Charm |
New
|
Undecided
|
Unassigned | ||
| OpenStack RabbitMQ Server Charm |
New
|
Undecided
|
Unassigned | ||
| charm-ovn-central |
New
|
Undecided
|
Unassigned | ||
| charm-ovn-chassis |
New
|
Undecided
|
Unassigned | ||
| charm-ovn-dedicated-chassis |
New
|
Undecided
|
Unassigned | ||
Bug Description
The use of charm specific files in /etc/policy-rc.d/ to prevent services from restarting during a package upgrade (or other charm services) also prevents those from starting up when the machine is rebooted.
Combined with LP#1934406, the charm presents a very friendly "active/idle" when in reality there are necessary services not running requiring the restart actions to be run.
Can you conceive of some way to monitor or signal that there are vital services not running after a reboot, or even better ensure services are running after a machine reboot?
| description: | updated |
| description: | updated |
Revision history for this message
| Adam Dyess (addyess) wrote | #1 |
| summary: |
- deferred restarts prevent a rebooted machine from starting services + deferred restarts provide incorrect charm status after machine reboots |
Revision history for this message
| Drew Freiberger (afreiberger) wrote | #2 |
To post a comment you must log in.
After an analysis of the logs at /var/log/
The normal 'service' nagios checks were showing the service up and running, but the charms indicated that there were actions needing to be run on the charm.
is this status still correct even if the machine reboots?
"Hooks skipped due to disabled auto restarts: configure_ovs, install"