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@lists.xen.org
http://lists.xen.org/xen-devel
