7

How can I issue apt upgrades without automatically stopping/starting daemons? I'd like to manually restart services.

To cite a specific example:

I'll revisit a long-running machine and run sudo apt-get update && time sudo apt-get dist-upgrade. This is a very straight-forward means of seeing all available upgrades, followed by a simple Enter keypress to get the systems fully patched.

If I see postgresql-9.1 in the upgrade list, I abort the upgrade. In that case, apt would stop the service early in the process, apply several non-critical operations, then restart the service much later. A routine upgrade could cause minutes of downtime.

I'd like to say "yes" to the upgrade to get all patches applied, then manually restart the service at a convenient time.

3 Answers 3

13
+50

You can prevent service restarts with the Debian policy layer which works on Ubuntu as well.

Example: Create a file named /usr/sbin/policy-rc.d with following content (don't forget to make the file executable):

#!/bin/sh

exit 101

No service¹ would be automatically started/stopped/restarted anymore. See /usr/share/doc/sysv-rc/README.policy-rc.d.gz for details and how to adjust it to just ignore a single service.

1. as long as the installation scripts follow the Debian guidelines and use invoke-rc.d for service restarts

3
  • Sounds credible, but does this still apply to Upstart in Ubuntu? (Debian is still with SysV-Init) And is this independent of starting/stopping at boot?
    – gertvdijk
    Feb 13, 2013 at 16:54
  • 1
    I checked some services like postfix on 12.04 which use invoke-rc.d. It depends only on the installation scripts (especially preinst and postinst) which start and stop services. But not sure how upstart scripts might interfere, for example if they use "respawn".
    – tlo
    Feb 13, 2013 at 17:34
  • 1
    It works for postgresql which has an init script, with this script. Setting up postgresql-9.1 (9.1.8-0ubuntu12.04) ... invoke-rc.d: policy-rc.d denied execution of start. I tried it with cron on 12.04 (which has upstart) and it works there, too.
    – rduplain
    Feb 13, 2013 at 17:48
3

I'd like to say "yes" to the upgrade to get all patches applied, then manually restart the service at a convenient time.

You can't do this in the general case, sorry. Even if a service is not restarted, packages don't provide any assurance that upgrades without service restarts won't break things (eg. anything dynamically loaded, like modules).

If you want a stable system, you should either hold back from upgrading a package, or upgrade it fully, complete with a service restart.

I can't really point to a credible source here, since I can't prove a negative. Debian policy is relevant here; it simply does not provide the guarantee that you are looking for. According to Debian policy, a package's functionality is not required to work until the postinst has finished successfully. So we can infer that if the postinst includes a mandatory service restart, then it needs to happen.

Some other mechanisms that might help you:

  1. Use apt-get --download-only upgrade to download updates in advance.
  2. Hold specific packages back from upgrades.
  3. Look into "high availability", so that servers can be upgraded in turn with no interruption to service. With Postgres, this would probably involve some kind of replicated configuration.
4
  • 1
    It's definitely possible as long as the packages follow the Debian policy and use "invoke-rc.d" which has a hook to "policy-rc.d". See my answer for details.
    – tlo
    Feb 12, 2013 at 18:03
  • OK, but the service still has the potential to be broken, regardless, since the upgrade can still walk over files that the service depends on. Feb 12, 2013 at 18:46
  • Great discussion, thanks. The most frustrating part of the default behavior is that postgresql is stopped, various packaging triggers are run, then postgresql is started again. Depending on the upgrades, this could take minutes, and it's for non-critical stuff like man processing. Even selecting one package has this delay. I realize that dynamically loaded modules could break, but I would like to evaluate my alternatives. More explicit control and inspection of upgrades should prevent broken systems. I was looking for the hook, which @tlo answers.
    – rduplain
    Feb 13, 2013 at 16:54
  • This is relevant: ubuntu.com/usn - supports RSS and email.
    – rduplain
    Feb 13, 2013 at 17:56
1

There is CLI based tool named as sysv-rc-conf Install sysv-rc-conf. You can also get it installed by running the following command in terminal:

sudo apt-get install sysv-rc-conf

Then you can activate/open it by running:

sudo sysv-rc-conf

Screenshot:

enter image description here

5
  • sysv-rc-conf manages runlevel configuration. I want to perform upgrades and inform apt that it should not stop the affected services, so that I can restart them manually when the time is right. In my example, this would be a call to sudo service postgresql restart.
    – rduplain
    Dec 7, 2012 at 1:22
  • I don't see how this answer is relevant to service restarts invoked by APT.
    – gertvdijk
    Feb 13, 2013 at 16:47
  • this is not only for APT & suitable for all kind of services.
    – Raja G
    Feb 13, 2013 at 16:49
  • @snow No it isn't. You can deconfigure the service in the runlevel configuration, but a service myservicename start will still start the service. This also applies to start/stops invoked by APT. That's exactly as @rduplain also tried to explain I think.
    – gertvdijk
    Feb 13, 2013 at 16:56
  • @gertvdijk ok how about deleting then ?
    – Raja G
    Feb 13, 2013 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .