Why not enable templated units?

[Ryan Kuester]

On Thu, Oct 02, 2014 at 06:56:42AM +0200, Martin Pitt wrote:
> Ryan Kuester [2014-10-01 19:48 -0500]:
> > Perhaps my example isn't compelling to anyone except me :^), but is
> > there a reason to squash what systemctl and systemd seem to allow?
> > systemctl seems to allow enabling of templates and systemd instantiates
> > them in a reasonable way.
> 
> Incidentally I was playing around with instantiated units just a few
> days ago (just with 208, not with 215). While systemctl enable
> foo at .service formally works with 208 (it creates a symlink), it
> doesn't actually do anything, and might even wreak some havoc. grawity
> says that due to that 215 doesn't even allow enabling instance
> templates any more.

Good to know. I was experimenting with 204, in which it actually did do
something. It looks like I was depending on undefined behavior. I see
commits upstream which make the changes about which you're talking.

> It seems the correct way to add dependencies to an instantiated unit
> is via udev rules, like
> 
>   SUBSYSTEM=="block", [... some tests for USB ...], ENV{SYSTEMD_WANTS}+="automount-usb-media@$name.service"

I see, so I can get the behavior I seek if udev wants both services
like:

	udev SYSTEMD_WANTS --> automount@$name.service
	udev SYSTEMD_WANTS --> scan@$name.service

rather than chaining them like:

	udev SYSTEMD_WANTS --> automount@$name.service wants --> scan@$name.service

which happens to work in 204, but relies on undefined behavior which
doesn't work in subsequent versions.

Yes, that seems to work. And at least in my case, it's fine for udev to
know about both services. Thanks for indulging me, guys.

-- Ryan