Bug#959917: systemd: unit file Alias= leads to dangling symlink

[Michael Biebl]

Control: reassign -1 smartmontools

Hi

Am 07.05.20 um 02:51 schrieb Christoph Anton Mitterer:
> Package: systemd
> Version: 245.5-2
> Severity: normal
> 
> 
> Hey.
> 
> I've just noted the following behaviour.
> 
> /lib/systemd/system/smartmontools.service has:
> [Install]
> WantedBy=multi-user.target
> Alias=smartd.service
> 
> 
> Which leads to:
> # tree /etc/systemd/system
> /etc/systemd/system
> ├── multi-user.target.wants
> │   ├── smartd.service -> /lib/systemd/system/smartd.service
> │   ├── smartmontools.service -> /lib/systemd/system/smartmontools.service
> │   └── ...
> ├── smartd.service -> /lib/systemd/system/smartmontools.service
> ...
> 
> With /etc/systemd/system/multi-user.target.wants/smartmontools.service being
> a dangling symlink to the non-existant /lib/systemd/system/smartd.service .
> 
> /etc/systemd/system/smartd.service is however created with the correct
> destination.
> 
> 
> This stays if one disables/enables the unit, i.e. it's re-created with
> the dangling symlink.
> 

I was pointed to
https://salsa.debian.org/debian/smartmontools/-/commit/2a6b57611eba015de539f4e3686e2f5f161acdb3

The smartmontools package renamed the service unit from smartd.service
to smartmontools.service. That's the reason for the old, dangling symlink.

The cleanup of the old enablement symlinks needs to be done manually by
the smartmontools package.
Reassigning to the smartmontools package accordingly.

Regards,
Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20200507/cb0a5175/attachment.sig>