[systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates

Michal Sekletar msekleta at redhat.com
Fri Aug 9 06:49:45 PDT 2013


On Thu, Aug 08, 2013 at 03:35:24PM +0200, Tom Gundersen wrote:
> Hi Michal,

Hello Tom,

> 
> On Thu, Aug 8, 2013 at 3:19 PM, Michal Sekletar <msekleta at redhat.com> wrote:
> > Calling enable on template units doesn't make sense since it is possible
> > to enable instances directly and users are not forced to use Alias=
> > trickery anymore.
> 
> It actually might make sense to still call enable on a template unit
> with an Alias:

I was too quick doing conclusions here, sorry about that. On the bright
side, at least the discussion started about this topic.

> 
> Imagine foo at .service with Alias=bar at .service. In this case you want to
> be able to do "systemctl enable foo at .service", and then "systemctl
> start bar at baz.service" should start the instance foo at baz.service. An
> example where this would be useful is for "systemctl enable
> kmsconvt at .service" to make the kmsconvt template override the autovt
> template.

Fair enough, it looks like there are use cases for template enablement
after all, thus we shouldn't be so strict as proposed by my patch.

> 
> However, we definitely don't want to allow a template name in
> WantedBy= or RequiredBy= (this doesn't make any sense as "systemctl
> start foo at .service" is invalid).
> 
> Currently we don't really verify what is given in
> Alias/WantedBy/RequiredBy at all at enable time (only at runtime), but
> I think we should do this using unit_name_is_valid(name,true) for
> Alias and unit_name_is_valid(name,false) for the other two.

Doing some validation of installation information encoded in unit file seems
to me as very good idea.

> 
> What do you think?

Once everything is figured out then we should also expand documentation in
relevant section of systemd.unit man page because AFAIK now it doesn't cover
template unit files at all.

> 
> Cheers,
> 
> Tom

Michal


More information about the systemd-devel mailing list