[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:44, Juergen Gross wrote:
> 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.

Ross, you had some concerns I'm still not sure I understand.

Could you please answer my questions?

>> 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
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®.