[Debian-ha-maintainers] Bug#862248: Bug#862248: No straightforward and permanent way to disable DRBD autostart, no drbd systemd unit file

[Apollon Oikonomopoulos]

On 09:54 Fri 12 May     , Christian Balzer wrote:
> On Thu, 11 May 2017 09:33:59 +0300 Apollon Oikonomopoulos wrote:
> 
> > On 09:15 Thu 11 May     , Christian Balzer wrote:
> > > Firstly I recreated the initial state bu unmasking drbd and enabling 
> > > it, > then reloading systemd.
> > > 
> > > That find then gives us:
> > > ---
> > > /run/systemd/generator.late/drbd.service
> > > /etc/systemd/system/multi-user.target.wants/drbd.service  
> > 
> > So, now we need ls -l 
> > /etc/systemd/system/multi-user.target.wants/drbd.service to see how old 
> > the symlink is and where it points to. Can you also zgrep drbd-utils 
> > /var/log/dpkg.log*?
> > 
> 
> 
> Sure thing, that's quite the old chestnut indeed:
> ---
> lrwxrwxrwx 1 root root 32 Aug 11  2015 /etc/systemd/system/multi-user.target.wants/drbd.service -> /lib/systemd/system/drbd.service
> ---
> 
> Note that this link is also present on:
> A Wheezy system with "8.9.2~rc1-1~bpo70+1" installed.
> On a system that was initially installed with Jessie but had
> 8.9.2~rc1-2+deb8u1 installed first.
> The plot thickens, see below.

Yes, it makes prefect sense. This is what happened:

We were originally shipping a systemd unit since 8.4.4-1 and up to 
8.9.5-1, where the systemd unit was dropped as it didn't make much 
sense, at least in the way it was implemented.

Now, the symlinks under /etc/systemd/system/multi-user.target.d which 
are created by systemctl enable/update-rc.d enable are only cleaned up 
during package *purge*. So, when you had a version with the systemd unit 
and upgraded to a version without it, the symlink would still be there, 
while the unit file itself would not be there.

So, what should be done in the package actually is invoke 

 deb-systemd-helper purge drbd.service

in drbd-utils.postinst iff upgrading from versions that had a systemd 
unit in place.

There's an additional problem here: upstream's initscript does not have 
any Default-Start runlevels, as upstream doesn't suggest enabling the 
initscript by default. This however causes update-rc.d (and systemctl 
enable) to shortcircuit the action by default:

 # update-rc.d drbd disable
 update-rc.d: error: drbd Default-Start contains no runlevels, aborting.

To recap: we need to properly clean up systemd's symlinks to the 
obsolete service file *and* fix the initscript to contain Default-Start 
levels. I would also consider disabling the service by default on new 
installations, as this is what upstream also recommends.

Ideas?

Cheers,
Apollon