Re: [PATCH v7 2/8] cxenstored: add support for systemd active sockets

[Ian Campbell <ian.campbell@citrix.com>]

On Wed, 2015-08-05 at 12:21 +0100, George Dunlap wrote:
> On Wed, Aug 5, 2015 at 12:11 PM, Ian Campbell <ian.campbell@citrix.com> 
> wrote:
> > On Wed, 2015-08-05 at 11:56 +0100, George Dunlap wrote:
> > > On Wed, Aug 5, 2015 at 11:17 AM, Ian Campbell <
> > > ian.campbell@citrix.com>
> > > wrote:
> > > > On Wed, 2015-08-05 at 11:06 +0100, George Dunlap wrote:
> > > > > On Fri, Jul 18, 2014 at 12:28 AM, Luis R. Rodriguez
> > > > > <mcgrof@do-not-panic.com> wrote:
> > > > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > > > 
> > > > > > This adds systemd socket activation support for the C 
> > > > > > xenstored.
> > > > > > Active sockets enable xenstored to be loaded only if required 
> > > > > > by a
> > > > > > system
> > > > > > onto which Xen is installed on. Socket activation is handled by
> > > > > > systemd, once a port for a service which claims a socket is 
> > > > > > used
> > > > > > systemd will start the required services for it, on demand. For
> > > > > > more
> > > > > > details on socket activation refer to Lennart's socket
> > > > > > -activation
> > > > > > post regarding this [0].
> > > > > > 
> > > > > > Right now this code adds a no-op for this functionality, 
> > > > > > leaving
> > > > > > the
> > > > > > enablement to be done later once systemd is properly hooked 
> > > > > > into
> > > > > > the build system. The socket activation is ordered in aligment 
> > > > > > with
> > > > > > the socket activation order passed on to systemd.
> > > > > > 
> > > > > > [0] http://0pointer.de/blog/projects/socket-activation2.html
> > > > > 
> > > > > So with this patch in place, xenstored will not start on a system
> > > > > that
> > > > > has systemd, *even if it wasn't started from systemd*.
> > > > 
> > > > But where systemd is /sbin/init, right?
> > > > 
> > > > The case where xenstored was compiled with systemd support but 
> > > > systemd
> > > > is
> > > > not /sbin/init should still be expected to work, and isn't what I 
> > > > think
> > > > you
> > > > are complaining about here.
> > > > 
> > > > > Lots of systems (e.g., CentOS 7) have legacy systems in place to
> > > > > allow
> > > > > you to do things like "chkconfig --add xencommons" even on a 
> > > > > systemd
> > > > > system.  I think we still want to work with those, right?
> > > > 
> > > > Isn't chkconfig --add still arranging for the thing to be started 
> > > > by
> > > > systemd under the hood? If not systemd on a host where
> > > > /sbin/init==systemd
> > > > then what does else would start it?
> > > > 
> > > > If you are asking "should the sysvinit initscripts still be 
> > > > us(ed|able)
> > > > even though systemd is being used as /sbin/init on the host and a 
> > > > unit
> > > > file
> > > > is present" then AIUI the systemd answer is "no". (We may choose to
> > > > disagree with systemd on this I suppose)
> > > 
> > > Well that's not (apparently) the RHEL answer; doing "chkconfig --add
> > > [foo]" Just Works on CentOS 7 for all the sysvinit scripts I've used
> > > (including the Xen 4.4 Xen4CentOS packages).
> > 
> > I would expect that the CentOS 7 packaging guidelines would
> > require/encourage you to use the systemd unit files (via whatever 
> > command
> > that is) in preference to the sysvinit initscripts when they are 
> > available.
> > 
> > AUIU the compatibility works the other way round, which is if you use the
> > new systemd commands and there is no unit file with that name but there is
> > a sysv initscript with that name then systemd will invoke the initscript in
> > a compatibility mode.
> > 
> > I'm a bit surprised that chkconfig doesn't just to the right thing. It's
> > possible that the fact that our initscript and our systemd unitfiles do not
> > share the same names has defeated its heuristics.
> 
> It seems to me that "the right thing" for chkconfig to do is to run
> the script you've asked it to run, not do some other thing you haven't
> asked it to do. :-)  If you think about how different systemd is than
> sysvinit, the chance of a script with a similar name to a systemd rule
> being *actually* interchangeable is pretty low.  If they really want
> to push people into using systemd they should remove chkconfig
> altogether, or make it print a warning, not do something completely
> different.

There's no point arguing about that here or with me.