[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 29/06/16 15:44, Juergen Gross wrote: > On 29/06/16 15:31, Ross Lagerwall wrote: >> 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. > > Could you please educate me what's wrong? I'm no systemd expert. Ross, you had some concerns I'm still not sure I understand. Could you please answer my questions? >> 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 > > How could I specify e.g. in xendomains.service the dependency to > xenstore? > >> 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 > > The two services would be mutually exclusive. Can I tell systemd this > is the case? > >> 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 > > That's no good idea. Someone commenting out the old line and adding the > other option would end in both variants to be tried. This would have to > be a little bit more sophisticated. :-) Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |