[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Get list of restarted services during upgrade



Denis Witt wrote:
> Bob Proulx wrote:
> > I assume from this that services are being monitored.  If they are
> > restarted and during the restart the monitoring detects that the
> > service is offline then it triggers an alert.  And whatever the
> 
> First it will try to restart the service, if this fails the service
> will be migrated to another node.

Ah...  And so the plot thickens!  Quick monitoring, sense a failure,
trigger a restart on a different node.  And of course I think that
would all work fine but it would generate a lot of noise to wade
through when there are upgrades that restart daemons.

> > setting of "Maintenance-Mode" does basically tells the monitoring to
> > ignore any problem for that time period.  Is that about right?
> 
> Yes. But it will disable the monitor for all services on all nodes,
> which isn't always needed. 

Hmm...  (Thinking...  No ideas.)

> > > At the moment I try out update-rc.d to avoid any service to be
> > > restarted during upgrade, but I wonder if there might be a better
> > > solution.
> 
> > > It's policy-rc.d, of course, not update-rc.  
> 
> > That is an idea.  Every use of a postinst script to restart a daemon
> > should be gated by policy-rc.d.  And you could always approve the
> > restart but that script could at that time put the node into your
> > maintenance-mode right then.  Don't know what you would use to return
> > it to regular service afterward.  Perhaps after a timeout.
> 
> That is a nice idea, thanks.

Another idea.  There is probably an apt post hook (untried) such as
APT::Update::Post-Invoke-Success that could be used at the very end to
return the node back to normal service.  I know that apt-show-versions
uses it to run an update script after apt has finished.

> At the moment policy-rc.d just exit with 101.

The problem I see with that is that you won't actually ever restart
the daemon when it needs to be restarted.  In some cases it simply
means that you won't have the security upgrade.  That would be typical
of a production host running Debian Stable.  So that may be acceptable
for you.  (But in other cases such as Unstable/Testing a restart is
often required in order to complete the upgrade.  In some other cases
the running daemon really needs to be restarted in order to work with
the new environment around it.)

If you are doing this then you really want to run 'checkrestart' (from
the debian-goodies package) on a regular basis and deal with what it
reports.  Because otherwise the daemons may be vulnerable to security
vulnerabilities that were fixed by the upgrade and installed but never
restarted to take effect.

Good luck!
Bob

Attachment: signature.asc
Description: Digital signature


Reply to: