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

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

On Mon, Mar 24, 2014 at 10:11:13AM +0000, Ian Campbell wrote:
> 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?

Not that I have seen.

> > 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.

I studied this approach a bit more and it turns out that execve() does just what
we want, it will carry the same PID for the spawned process, it won't return, 
it'll
just go onto the other process, if it fails it returns back, in which case we 
can
try the other cxenstored. We'd just have to rename the C xentstored to 
censtored.
This would simplify things for both init systems and systemd. In the init system
the check for oxenstored can be removed, in systemd we'd just have one systemd 
service file.

In light of this I'd like for us to consider this approach now.

Thoughts?

  Luis

Attachment: pgpfIV5iIP3bA.pgp
Description: PGP signature

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