[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, Jun 29, 2016 at 03:00:41PM +0200, 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?
> 

Not sure I follow.

See 81d758afca7c3c1e3ccbd78154b33d64fd7757fb. I expect systemd_checkin
to be able to tell if cxenstored is started by systemd or not.
sd_listen_fds doesn't seem to involve testing xenstore sockets. Do I
miss anything?

Wei.

> 
> Juergen
> 

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.