[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 20/07/16 14:08, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd 
> xenstore socket definitions"):
>> On 20/07/16 12:12, Juergen Gross wrote:
>>> To be clear: I don't want to avoid systemd by any means. I just don't
>>> want to have a complex and ugly solution with no gain just because
>>> doing it the systemd way.
>>
>> Given the introduction of this new choice, I agree that socket
>> activation isn't sensible.  In the grand scheme of things it doesn't buy
>> you much, as xenstored does not match the intended use for socket
>> activation (on-demand launch of services when something tries to use its
>> socket), as it is a start of day service that runs forever.
> 
> xenstore in its own domain is not a `new choice' which is being
> `introduced'.  It has been supported by Xen upstream for a long time.
> AFAICT from what Juergen is saying it seems that it was broken on
> systemd systems by systemd-specific configuration.
> 
>> However, socket activation and sd_notify() are entirely orthogonal, and
>> the removal of socket activation should not remove sd_notify().
> 
> I don't have a clear opinion opinion about this but it seems likely to
> me that retaining some kind of systemd `ready now' call is desirable
> or even necessary.

To be precise: the call might be desirable, but it is not necessary.
With a systemd service type "onehot" systemd will start follow-up units
only after the process started by systemd has exited. So the 'ready now'
indication would probably speed up the boot process by a few msecs.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.