On 20/07/16 14:11, Ian Jackson wrote: > Ross Lagerwall writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd > xenstore socket definitions"): >> Nevertheless, I feel that this patch series makes the implementation >> worse for users of xenstored as a daemon: >> >> - Because Type=oneshot is not intended to be used for daemon processes, >> systemctl status does not show the service as "running", instead it >> shows "exited". This is surprising, at the very least. I haven't tested,
With "RemainAfterExit" specified it is still "active (running)" on my system. >> but I believe it would also prevent us someday using the systemd service >> management features like Restart=on-failure > > This sounds undesirable. I would like to see this rectified. What are you speaking about: a failure during service start or in the running system? And how would you want to handle the failure of a xenstore domain? I think introducing restart capability to xenstored (d being daemon or domain) will need some more work than just rely on systemd. It should not be completely daemon specific! >> - Removes socket activation. Services would have to explicitly depend on >> xenstored.service rather than having an implicit dependency on simply by >> using xenstored.socket. This means configuring explicit ordering, etc., >> which is easier to get wrong. Socket activation is also generally the >> most efficient way of starting a service. > > Socket activation is a means to and end, not an objective in itself. > >> - Uses a poll loop to determine whether the daemon is ready or not >> rather than explicit notification from the daemon itself. > > I agree that polling is rather poor. I can remove the polling by adding appropriate code to xenstore daemon: the non-daemon process should exit only after the daemon is ready to work. For the xenstore domain init-xenstore-domain will exit only after the xenstore is up as the program itself is writing some xenstore entries. >> - Uses a shell script wrapper... > > I'm afraid that ISTM likeloy that however we do this a shell script > wrapper is going to be needed. > > One reason is that there should be _one_ place in the source tree > which reads the relevant config snippets etc. about how the whole Xen > system should be started. +1 Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel