Re: [PATCH v4 13/15] systemd: add xen systemd service and module files

["Luis R. Rodriguez" <mcgrof@do-not-panic.com>]

On Wed, May 7, 2014 at 8:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-04-29 at 18:12 -0700, Luis R. Rodriguez wrote:
>>   * simplifies startup to not require polling on the sockets
>>     as initial socket management is handled by systemd, we just
>>     take on the socket later once anything pokes at it, a simple nc -U
>>     on the socket files can activate the service for example.
>
> What about xenstore users which don't use the sockets but instead use
> the kernel ring interface? Does this mean that if only those users are
> present nothing starts xenstored?

It depends on how you use the service files, what you say is true only
if the xenstored.socket is enabled:

systemctl enable xenstored.socket

If however an administrator or a Linux distribution does this:

systemctl enable xenstored.service

then the xenstored will always be guaranteed to be started regardless.
If someone wants to test active socket working they should just enable
the socket and then tickle it with nc -U to see it working, that's
all.

>>   * allow for xenstored configuration through *either* of these
>>     configuration files:
>>       - /etc/sysconfig/xenstored
>>       - /etc/default/xenstored
>>     The /etc/default/xenstored will let debian based systems do
>>     the same, while SUSE/OpenSUSE/Fedora/RedHat can keep on chugging
>>     with sysconfig
>
> Is the usual systemd way?

Yes and no. Yes in the sense that its what daemons have been using for
ages, as such existing deamons need to keep working with what they've
been used to, in order to avoid huge changes. In the long run though
at least Lennert has expressed disdain towards these two practices of
using /etc/sysconfig and /etc/default -- and calls for developers to
abandon them. You can read the full rant here:

http://0pointer.de/blog/projects/on-etc-sysinit.html

The replacement should then be to start moving towards abandoning
these, however this is a radical change and I would encourage this to
be done as a phased step rather than a requirement.

>>   * defines a modules-load.d for us
>
> Does this duplicate the existing list in the LSB initscript, meaning we
> have to keep two places up to date? Can we avoid that somehow?

Its a good idea to keep only one, will work on that as part of my next series.

  Luis