Unexpected behavior when updating exclusive policy package

From: Ansgar Wiechers <ansgar.wiechers_at_automatic-server.com>
Date: Tue, 20 Oct 2020 13:24:07 +0200

Hi Laurent

After adding a new service to our exclusive policy package we're
observing restarts of some services (oneshots to be precise) when
updating the package on our servers, and I wanted to ask if this is
expected behavior (because I did not expect it ^_^;).

Details:

On a system where the previous package version (without the new policy
service) is installed, all services are up and working (svctl liststate
shows all as "up"). When updating the policy package, (at least) some of
the dependent services are (re)started, namely cloud-init-network and
cloud-init-config, perhaps others as well:

----8<----
root_at_testawi2:~# apt-get install --only-upgrade s6-policy-exclusive
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  s6-policy-exclusive
1 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 12.6 kB of archives.
After this operation, 11.3 kB of additional disk space will be used.
Get:1 http://apt-1.asag.io/aos xenial/main amd64 s6-policy-exclusive all 0.4.22-0aos1~16.04.2 [12.6 kB]
Fetched 12.6 kB in 0s (925 kB/s)
[...]
(Reading database ... 66223 files and directories currently installed.)
Preparing to unpack .../s6-policy-exclusive_0.4.22-0aos1~16.04.2_all.deb ...
Unpacking s6-policy-exclusive (0.4.22-0aos1~16.04.2) over (0.4.21-0aos1~16.04.1) ...
Setting up s6-policy-exclusive (0.4.22-0aos1~16.04.2) ...
Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1~16.04.1 running 'init' at Tue, 20 Oct 2020 10:35:10 +0000. Up 402.60 seconds.
ci-info: +++++++++++++++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++++++++++++++
ci-info: +--------+------+------------------------------+---------------+--------+-------------------+
ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
ci-info: +--------+------+------------------------------+---------------+--------+-------------------+
ci-info: | br0 | True | 192.168.1.11 | 255.255.255.0 | global | fa:16:3e:f0:7e:30 |
ci-info: | br0 | True | fe80::f816:3eff:fef0:7e30/64 | . | link | fa:16:3e:f0:7e:30 |
ci-info: | eth0 | True | . | . | . | fa:16:3e:f0:7e:30 |
ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
ci-info: | lo | True | ::1/128 | . | host | . |
ci-info: +--------+------+------------------------------+---------------+--------+-------------------+
ci-info: ++++++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++++++
ci-info: +-------+-----------------+--------------+-----------------+-----------+-------+
ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
ci-info: +-------+-----------------+--------------+-----------------+-----------+-------+
ci-info: | 0 | 0.0.0.0 | 192.168.1.1 | 0.0.0.0 | br0 | UG |
ci-info: | 1 | 169.254.169.254 | 192.168.1.1 | 255.255.255.255 | br0 | UGH |
ci-info: | 2 | 192.168.1.0 | 0.0.0.0 | 255.255.255.0 | br0 | U |
ci-info: | 3 | 192.168.2.0 | 192.168.1.94 | 255.255.255.0 | br0 | UG |
ci-info: | 4 | 192.168.3.0 | 192.168.1.94 | 255.255.255.0 | br0 | UG |
ci-info: | 5 | 192.168.200.0 | 192.168.1.7 | 255.255.255.0 | br0 | UG |
ci-info: +-------+-----------------+--------------+-----------------+-----------+-------+
ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: | Route | Destination | Gateway | Interface | Flags |
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: | 0 | fe80::/64 | :: | br0 | U |
ci-info: | 4 | ff00::/8 | :: | br0 | U |
ci-info: +-------+-------------+---------+-----------+-------+
Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1~16.04.1 running 'modules:config' at Tue, 20 Oct 2020 10:35:10 +0000. Up 403.07 seconds.
---->8----

This appears to happen during postinst when updating the live DB.

We have 3 cloud-init services (cloud-init-local, cloud-init-network, and
cloud-init-config), but only the latter 2 of them seem to be affected,
which would indicate that the restarts follow the dependencies between
the services.

The new service is inserted between mdevd and mount-local, dependency-
wise, so dependendies would look like this (only the direct chains,
leaving out the other dependencies):

cloud-init-config
  -> cloud-init-network
    -> network
      -> essential-before-network (bundle)
        -> mount-local
          -> cryptdisks (the new service)
            -> mdevd
              -> ...

cloud-init-local
  -> mdevd
    -> ...

It seems that inserting the new service (cryptdisks) triggers a restart
of the service that depends on it (mount-local), which then triggers a
restart of the service(s) depending on mount-local and so on.

Is my understanding correct, and this behavior expected?

Also, we did not add the new service to the essential-before-network
bundle (yet). Do we need to do that, or is updating the bundle optional?

Regards
Ansgar
Received on Tue Oct 20 2020 - 11:24:07 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC