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

[Juergen Gross <jgross@xxxxxxxx>]

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