Hello, Thanks for your report. I've recently got involved in smartmontools packaging and so I'm trying to fix some of the problems.
On Sat, Dec 26, 2015 at 05:18:23AM +1030, Ron wrote: > So I started looking into this mostly because after updating a bunch of > machines to Jessie with systemd as init, it rather annoyingly no longer > respected the existing configuration to not run the smartd daemon It seems this is quite common for daemon packages now, at least from the little research I've conducted so far. I agree it's quite awkward. I'm going to keep looking and see if any other daemon packages have a nice solution for this, and if so, consider adopting it. > Not only does it not respect that, but it installs 2 units to not do > it, smartd.service and smartmontools.service, I think this is intentional. The historic name of the init script matched the package name, smartmontools, but the actual daemon is called smartd. I think that whoever added the initial systemd support was intending to transition the package away from the old name and to smartd for the unit name (which is more sensible IMHO). To do so, they are forced to install a unit file matching the sysvinit script name, in order to mask the init script (otherwise systemd/compat stuff would start up the sysvinit script too). Normally you would mask by creating a symlink to /dev/null for the name of the init script. However it seems systemd's with the current arrangement is fine: "systemctl | grep smart" shows just smartd (preferred name); "systemctl status smartmontools" shows you the status of smartd (so it considers the two names for the same thing). > smartmontools.postinst itself has two copies of the dh_systemd_enable > boilerplate, *both* for just the smartd.service ... This seems to have been a typo; there should have been one dh_systemd_enable and one dh_systemd_start. The lack of the latter makes me think that activation probably did not happen until after a reboot until now. I've fixed this in the current packaging. It would have also been fixed by moving to dh(1)-style packaging (forthcoming). -- Jonathan Dowland
