[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] xen 4.5-unstable, oxenstored cannot start (centos 7, kernel 3.17.0)



On Fri, 2014-10-10 at 15:39 +0200, Olaf Hering wrote:
> On Fri, Oct 10, Ian Campbell wrote:
> 
> > On Fri, 2014-10-10 at 14:42 +0200, Olaf Hering wrote:
> > > Yes, --enable-systemd requires that the tools are started by systemd.
> > 
> > It shouldn't / mustn't.
> > 
> > --enable-systemd is supposed to enable things to run under systemd *if*
> > it is present, by enabling socket activation etc, not to break
> > non-systemd systems.
> > 
> > i.e. it's supposed to enable distros who support multiple init systems
> > to only provide a single Xen binary.
> 
> It is currently not coded that way.
> 
> If the system was booted with systemd,

That's a different scenario then.

What I said was: --enable-systemd must not break if you boot with e.g.
sysvinit or upstart as init, because I was countering your assertion
that --enable-systemd *required8 systemd.

>  and if staging is compiled with
> --enable-systemd --prefix=/odd/path, and if I run
> /odd/path/etc/init.d/xencommons start then xenstored will recognize that
> systemd is running. But it does not recognize that xenstore was not
> started by systemd itself. As a result socket activation will fail.
> 
> My idea to fix that case is to give xenstored a new --use-systemd-socket
> and adjust the code accordingly.

If you've enabled systemd and are actually booting with systemd then I
think you should be expected to arrange for systemd to start things.

If you want to boot with systemd but not actually take advantage of its
features, use --disable-systemd.

Ian.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

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