Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 06/29/2016 02:00 PM, Juergen Gross wrote:
> On 29/06/16 14:52, Andrew Cooper wrote:
> > On 29/06/16 13:44, Juergen Gross wrote:
> > > @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
> > >         /* Tell the kernel we're up and running. */
> > >         xenbus_notify_running();
> > >
> > > -#if defined(XEN_SYSTEMD_ENABLED)
> > > -       if (systemd) {
> > > -               sd_notify(1, "READY=1");
> > > -               fprintf(stderr, SD_NOTICE "xenstored is ready\n");
> > > -       }
> > > -#endif
> > Getting rid of the socket configuration for systemd is ok, but we should
> > keep the sd_notify() calls for when the daemon is started by systemd.
> >
> > Socket activiation and sd_notify() are orthogonal, and sd_notify() is
> > still required if we don't want systemd to treat xenstored as a legacy
> > unix daemon.
> So what is the downside of xenstored being treated as a legacy daemon?
> This question is especially interesting for the case of patch 2 being
> considered: xenstored is no longer started by systemd, but by a wrapper
> script which might decide to start the xenstore domain instead.
>
> Another problem: today xenstored decides whether to call sd_notify()
> by testing the xenstore sockets being specified via systemd. This will
> no longer work. So how to do it now?
One problem with the patch as it currently is implemented is that the 
service type is not correct for when xenstored is a daemon. This makes 
it difficult to manage with systemd and difficult for other services to 
depend on it in a sensible fashion. The end result is subtle races and 
occasional failures.
How about:
* Maintain the existing service for xenstored
* Have a separate service (with different a service type) for starting 
the xenstore domain
* Switch between the two services

Personally I think it is better and more uniform for the administrator 
to enable and disable services in the normal fashion, but if you want to 
make it configurable with /etc/sysconfig/xencommons, then you can add 
something like this to xenstored.service:
ExecStartPre=/bin/grep -q XENSTORETYPE=daemon /etc/sysconfig/xencommons

and to xenstore-domain.service:

ExecStartPre=/bin/grep -q XENSTORETYPE=domain /etc/sysconfig/xencommons

Regards,
--
Ross Lagerwall

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