From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v7 2/8] cxenstored: add support for systemd active sockets Date: Wed, 5 Aug 2015 11:17:58 +0100 Message-ID: <1438769878.9747.47.camel@citrix.com> References: <1405639699-13494-1-git-send-email-mcgrof@do-not-panic.com> <1405639699-13494-3-git-send-email-mcgrof@do-not-panic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZMvls-0003A0-02 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2015 10:18:04 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , "Luis R. Rodriguez" Cc: xen-devel , "Luis R. Rodriguez" , Wei Liu List-Id: xen-devel@lists.xenproject.org On Wed, 2015-08-05 at 11:06 +0100, George Dunlap wrote: > On Fri, Jul 18, 2014 at 12:28 AM, Luis R. Rodriguez > wrote: > > From: "Luis R. Rodriguez" > > > > 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) On the other hand, does this mean I can no longer start xenstored by hand from the CLI? _That_ would seem to be worth preserving, for debugging etc if nothing else. Ian.