Debian Bug report logs - #797108
init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Christian Seiler <christian@iwakd.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade

Date: Thu, 27 Aug 2015 22:19:57 +0200

[Message part 1 (text/plain, inline)]

Package: init-system-helpers
Version: 1.23
Severity: normal
Tags: patch

Dear Maintainer,

if a package in version 1 had WantedBy=a.target and this is changed
to WantedBy=b.target in version 2 of that package, deb-systemd-helper
will properly create the links in b.target.wants/, but will not remove
the links in a.target.wants/. Same goes with changes in Alias= and
changes in Also=.

I've attached a patch to this bug report that fixes this.

Note that any additional links that were manually created by the
administrator will not be touched, only those that were created by
deb-systemd-helper in the first place. The only use case that is
not covered by this patch is if an administrator wanted to keep a
link that was auto-created (there is no way to distinguish them),
but that seems to be quite unlikely (and the administrator could
re-create it later - and it would then stay, even if the same
version of the package were to be installed again - only upgrades
will remove links).

I've also attached a trivial package in two versions to test this.
They change all 3 options (WantedBy=, Also= and Alias=) to test
everything at the same time. Just extract the source tarballs and
build the native packages if you want to test this.

Please change the commit message of the patch so that it reflects
the bug number it closes when you apply it to git.

Regards,
Christian

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages init-system-helpers depends on:
ii  perl-base  5.20.2-6

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

-- no debconf information

[0001-deb-systemd-helper-Remove-obsolete-links-on-package-.patch (text/x-diff, attachment)]

[testpkg_42.tar.xz (application/x-xz, attachment)]

[testpkg_43.tar.xz (application/x-xz, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #10 received at 797108@bugs.debian.org (full text, mbox, reply):

From: Felipe Sateler <fsateler@debian.org>

To: Christian Seiler <christian@iwakd.de>, 797108@bugs.debian.org

Subject: Re: Bug#797108: init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade

Date: Thu, 27 Aug 2015 23:39:01 -0300

On 27 August 2015 at 17:19, Christian Seiler <christian@iwakd.de> wrote:
>
> Package: init-system-helpers
> Version: 1.23
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> if a package in version 1 had WantedBy=a.target and this is changed
> to WantedBy=b.target in version 2 of that package, deb-systemd-helper
> will properly create the links in b.target.wants/, but will not remove
> the links in a.target.wants/. Same goes with changes in Alias= and
> changes in Also=.
>
> I've attached a patch to this bug report that fixes this.
>
> Note that any additional links that were manually created by the
> administrator will not be touched, only those that were created by
> deb-systemd-helper in the first place. The only use case that is
> not covered by this patch is if an administrator wanted to keep a
> link that was auto-created (there is no way to distinguish them),
> but that seems to be quite unlikely (and the administrator could
> re-create it later - and it would then stay, even if the same
> version of the package were to be installed again - only upgrades
> will remove links).
>
> I've also attached a trivial package in two versions to test this.
> They change all 3 options (WantedBy=, Also= and Alias=) to test
> everything at the same time. Just extract the source tarballs and
> build the native packages if you want to test this.

The test packages only have test-changes.service differ, the other 2
are the same in both versions...

But I checked that the link is removed if it was existing, a new one I
created is preserved, and if I remove an enable link, then the
disabled state is preserved to the new name (ie, when moving from
targetA to targetB if I disable in targetA then it won't be enabled in
targetB).

However, (and I don't know if this is new or not), the state does not
seem to be removed on package purge: I removed a target, purged the
package, then reinstalled the package and the enable link was not
generated.


-- 

Saludos,
Felipe Sateler

Message #15 received at 797108@bugs.debian.org (full text, mbox, reply):

From: Christian Seiler <christian@iwakd.de>

To: Felipe Sateler <fsateler@debian.org>, 797108@bugs.debian.org

Subject: Re: Bug#797108: init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade

Date: Fri, 28 Aug 2015 13:28:46 +0200

[Message part 1 (text/plain, inline)]

On 28.08.2015 04:39, Felipe Sateler wrote:
> On 27 August 2015 at 17:19, Christian Seiler <christian@iwakd.de> wrote:
>> I've also attached a trivial package in two versions to test this.
>> They change all 3 options (WantedBy=, Also= and Alias=) to test
>> everything at the same time. Just extract the source tarballs and
>> build the native packages if you want to test this.
> 
> The test packages only have test-changes.service differ, the other 2
> are the same in both versions...

Yes, sure. But the original service changes all three settings - so
I can see that all of them are affected. I only include the two
services to make sure I can change Also=, otherwise I wouldn't have
included them.

> But I checked that the link is removed if it was existing, a new one I
> created is preserved, and if I remove an enable link, then the
> disabled state is preserved to the new name (ie, when moving from
> targetA to targetB if I disable in targetA then it won't be enabled in
> targetB).

:-)

> However, (and I don't know if this is new or not), the state does not
> seem to be removed on package purge: I removed a target, purged the
> package, then reinstalled the package and the enable link was not
> generated.

That shouldn't happen. I've just tried in a Jessie VM to just
install testpkg_42, remove one of the WantedBy= links, purge it,
install it again - and then everything was recreated as expected.
On the other hand, I don't remember what you're describing while
I was testing this, so I'll look into it and try to reproduce
(and if I can, fix it). I'll probably get back to you tomorrow
on that, since I'm a bit busy today.

Christian

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 797108@bugs.debian.org (full text, mbox, reply):

From: Felipe Sateler <fsateler@debian.org>

To: Christian Seiler <christian@iwakd.de>

Cc: 797108@bugs.debian.org

Subject: Re: Bug#797108: init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade

Date: Fri, 28 Aug 2015 09:32:42 -0300

On 28 August 2015 at 08:28, Christian Seiler <christian@iwakd.de> wrote:
> On 28.08.2015 04:39, Felipe Sateler wrote:
>> On 27 August 2015 at 17:19, Christian Seiler <christian@iwakd.de> wrote:
>>> I've also attached a trivial package in two versions to test this.
>>> They change all 3 options (WantedBy=, Also= and Alias=) to test
>>> everything at the same time. Just extract the source tarballs and
>>> build the native packages if you want to test this.
>>
>> The test packages only have test-changes.service differ, the other 2
>> are the same in both versions...
>
> Yes, sure. But the original service changes all three settings - so
> I can see that all of them are affected. I only include the two
> services to make sure I can change Also=, otherwise I wouldn't have
> included them.
>
>> But I checked that the link is removed if it was existing, a new one I
>> created is preserved, and if I remove an enable link, then the
>> disabled state is preserved to the new name (ie, when moving from
>> targetA to targetB if I disable in targetA then it won't be enabled in
>> targetB).
>
> :-)
>
>> However, (and I don't know if this is new or not), the state does not
>> seem to be removed on package purge: I removed a target, purged the
>> package, then reinstalled the package and the enable link was not
>> generated.
>
> That shouldn't happen. I've just tried in a Jessie VM to just
> install testpkg_42, remove one of the WantedBy= links, purge it,
> install it again - and then everything was recreated as expected.
> On the other hand, I don't remember what you're describing while
> I was testing this, so I'll look into it and try to reproduce
> (and if I can, fix it). I'll probably get back to you tomorrow
> on that, since I'm a bit busy today.

FWIW, I tried to test what happens if a service has more than one
WantedBy target, and only one of those was removed by the admin, and
the new package uses a different 2 targets.

Now I need to clean up manually in order to do more tests

-- 

Saludos,
Felipe Sateler

Message #25 received at 797108@bugs.debian.org (full text, mbox, reply):

From: Louis Bouchard <louis.bouchard@canonical.com>

To: 797108@bugs.debian.org

Subject: Re: Bug#797108: init-system-helpers: deb-systemd-helper doesn't remove old links when changing WantedBy= at package upgrade

Date: Fri, 31 Mar 2017 15:40:52 +0200

Hello,

I have tested the patch proposed in this bug and it doesn't work for me.

It does indeed remove the old WantedBy= link, but doesn't create the new one and
the two lines (old & new) remain in the dsh_state file.

Without the patch, the two lines are present in the dsh_state file, but the
second one is never created since in enable() :

>         my $create_links = 0;
>         if (debian_installed($scriptname)) {
>             $create_links = 1 unless no_link_installed($scriptname, $service_path);

no_link_installed() will return false for the second entry in the dsh_state
file, which is the link to be created for the modified WantedBy=

HTH,

Kind regards,

...Louis
-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer                       Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

Send a report that this bug log contains spam.