[Pkg-utopia-maintainers] Bug#734460: Bug#734460: network-manager: Issues related to systemd when upgrading from << 0.9.8.8-2

[Laurent Bigonville]

Le Sun, 12 Jan 2014 02:18:32 +0100,
Michael Biebl <biebl at debian.org> a écrit :

> Am 07.01.2014 13:12, schrieb Laurent Bigonville:
> > Package: network-manager
> > Version: 0.9.8.8-2
> > Severity: serious
> > 
> > Hi,
> > 
> > I'm opening this bug so this is not getting lost.
> > 
> > When upgrading from the previous versions the following events might
> > occurs when the user is running systemd:
> > 
> > 1) The package was not enabling the systemd unit in the previous
> > versions.
> > 2) NM was then started using the LSB script called network-manager.
> > This means that the cgroup was called network-manager.service.
> > 3) During the upgrade the systemd unit is properly enabled and the
> > LSB script is masked by a symlink, this means that at some point
> > during the upgrade, the canonical name changes from
> > network-manager.service to NetworkManager.service
> > 4) At the end of the upgrade, systemd looks for a
> > NetworkManager.service cgroups which is not existing and then
> > concludes that the service is not running at all.
> > 5) Systemd tries to start the service, NM complains that there is an
> > other instance of itself running => boom
> > 
> > To fix this, I would propose to stop NM in the preinst script if we
> > are upgrading from the previous versions and that the user is
> > running systemd.
> 
> Why preinst and not postinst (before the #DEBHELPER# stanza, i.e.
> before the service is enabled)?
> Stopping the service in preinst creates unnecessary downtime which
> could be fatal if NM is in charge of the network connection and you
> do a remote upgrade.
> I don't see a downside moving the network-manager stop to postinst, do
> you? Just in case I'm missing something

Well, in the postinst the symlink that mask the LSB will already be
present on disk. That means that the canonical name of the service has
already changed. A daemon-reload is actually needed for systemd to
notice this change, but nothing guarantee that no other packages would
do it for us between the moment the files are unpacked and the moment
our postinst script is called.

That's why I thought that stopping the service in the preinst was the
safer choice.

Cheers,

Laurent Bigonville