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
signature.asc
Description: OpenPGP digital signature
