[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: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. > 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 http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |