Re: [Xen-devel] [PATCH v2 7/7] systemd: add support initial xen systemd service files

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Sat, 2014-03-22 at 03:26 +0100, Luis R. Rodriguez wrote:
> On Fri, Mar 21, 2014 at 10:08:14AM +0000, Ian Campbell wrote:
> > On Wed, 2014-03-19 at 13:58 -0700, Luis R. Rodriguez wrote:
> > > [...]
> > > diff --git a/tools/hotplug/Linux/systemd/oxenstored.service.in 
> > > b/tools/hotplug/Linux/systemd/oxenstored.service.in
> > > [...]
> > > +ExecStartPost=-@BINDIR@/xenstore-write "/local/domain/0/name" "Domain-0"
> > > diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in 
> > > b/tools/hotplug/Linux/systemd/xenstored.service.in
> > [...]
> > > +ExecStartPost=@BINDIR@/xenstore-write "/local/domain/0/name" "Domain-0"
> > 
> > I accidentally deleted the subthread about writing domid here too, but I
> > was wondering if it might be better to have a common xenstore service
> > which depends on oxenstore.service || cxenstore.service and then does
> > this kind of common implementation agnostic setup in one place where it
> > can't get out of sync easily?
> 
> That's what I was hoping for to achieve with the socket file but that
> seems to not work as expected, even if you claim the socket explicitly
> as part of both oxenstored and xenstored. To me this could likely be
> an enhancement to systemd but not sure.
> 
> systemd does not allow one to use || as part of the language for requirements,

Does it not have some sort of "Provides: some-virtual-facility" which
two things can provide and other things can depend on?

> This means we either do some sort of meta @VARIABLE@ substitution or a common
> init routine which will do the or checking for us. The only problem with this
> is systemd will treat the Forking type service ExecStart as the process to 
> care
> for, and if we add a wrapper that'd be dead. I haven't tried to implement one
> but I think this could confuse systemd or administrators.

Yes, lets not go that route.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel