On Fri, Dec 12, Olaf Hering wrote:
> This works:
> ExecStart=@XENSTORED@ --no-fork $XENSTORED_ARGS
>
> This fails:
> ExecStart=$XENSTORED --no-fork $XENSTORED_ARGS
But this will likely work:
ExecStart=/usr/bin/env $XENSTORED --no-fork $XENSTORED_ARGS
Let me know how to proceed...
Olaf
__
On Fri, Dec 12, Olaf Hering wrote:
> On Fri, Dec 12, Ian Campbell wrote:
>
> > Seems ok. I wonder if the wrapper ought to source
> > @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> > rather than relying on the initscript and unit file to do so. Especially
> > in the inits
On Fri, 12 Dec 2014, Ian Campbell wrote:
On Fri, 2014-12-12 at 12:37 +0100, Olaf Hering wrote:
On Fri, Dec 12, Ian Campbell wrote:
Seems ok. I wonder if the wrapper ought to source
@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
rather than relying on the initscript a
On Fri, 2014-12-12 at 12:37 +0100, Olaf Hering wrote:
> On Fri, Dec 12, Ian Campbell wrote:
>
> > Seems ok. I wonder if the wrapper ought to source
> > @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> > rather than relying on the initscript and unit file to do so. Especiall
On Fri, Dec 12, Ian Campbell wrote:
> Seems ok. I wonder if the wrapper ought to source
> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons to obtain XENSTORED_* itself
> rather than relying on the initscript and unit file to do so. Especially
> in the initscript case it looks a bit ugly to have to manual
On Wed, 2014-12-10 at 18:52 +0100, Olaf Hering wrote:
> On Wed, Dec 10, Ian Campbell wrote:
>
> > That results in a wrapper which unconditionally execs, the systemd unit
> > just calls that while the sysv script runs the wrapper and then does the
> > xenstore-read -s loop.
>
> Since systemd hand
On Wed, 2014-12-10 at 19:01 +0100, Olaf Hering wrote:
> On Wed, Dec 10, Ian Campbell wrote:
>
> > Separately from the above I wonder if it might be worth moving the
> > xenstore readiness check into the xen-init-dom0 helper and having most
> > things which currently depend on xenstore actually dep
On Wed, Dec 10, Ian Campbell wrote:
> Separately from the above I wonder if it might be worth moving the
> xenstore readiness check into the xen-init-dom0 helper and having most
> things which currently depend on xenstore actually depend on the
> "dom0-is-ready" unit, which itself depends on xenst
On Wed, Dec 10, Ian Campbell wrote:
> That results in a wrapper which unconditionally execs, the systemd unit
> just calls that while the sysv script runs the wrapper and then does the
> xenstore-read -s loop.
Since systemd handles the socket there is already a listener.
http://lists.freedesktop
On Wed, Dec 10, Ian Campbell wrote:
> I'm not sure why we don't want to exec in both cases, making this whole
> problem moot.
Good point!
That will probably work because sysv lets xenstored do the fork, so the
script will return to its caller. In systemd case --no-fork is passed so
the started p
On Wed, 2014-12-10 at 10:15 +0100, Olaf Hering wrote:
> > I was imagining a "named parameter" as SuS calls them. One or both
> > the sites which run this wrapper script would pass an environment
> > variable. Something like this in the script:
> >
> > $xenstored_do_exec $XENSTORED "$@" $XENSTO
On Tue, Dec 09, Ian Jackson wrote:
> Bottom line: as relevant maintainer, I'm afraid I'm going to insist
> that this script be in /etc.
I dont agree with the reasoning, but to get this done:
Which place would that be, XEN_SCRIPT_DIR?
> > > I don't think this script wants to contain an option par
Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in
systemd"):
> On Tue, Dec 09, Ian Jackson wrote:
> > But: I think the script is rather over-engineered, and that it ought
> > to be in /etc.
>
> Why should the wrapper be in /etc?!
Because it is the last chance the adm
On Tue, Dec 09, Ian Jackson wrote:
> Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE
> in systemd"):
> > On Fri, Dec 05, Ian Jackson wrote:
> > > I think the only way to make this work properly is to factor the
> > > necessary parts out of init.d/xencommons into a new
Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in
systemd"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I think the only way to make this work properly is to factor the
> > necessary parts out of init.d/xencommons into a new script which can
> > be used by both xencommon
On Fri, Dec 05, Ian Jackson wrote:
> I think the only way to make this work properly is to factor the
> necessary parts out of init.d/xencommons into a new script which can
> be used by both xencommons and systemd. I'm not sure such a patch
> would be appropriate for 4.5 at this stage.
I came up
On Fri, Dec 05, Ian Jackson wrote:
> Can systemd not launch these daemons by running the existing
> xencommons et al init scripts ? Obviously that won't give you all of
> systemd's shiny features but IMO it ought to work.
I think the point was to let systemd pass the file descriptors. Thats why
Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in
systemd"):
> On Fri, Dec 05, Ian Jackson wrote:
> > I think the only way to make this work properly is to factor the
> > necessary parts out of init.d/xencommons into a new script which can
> > be used by both xencommon
On Fri, Dec 05, Ian Jackson wrote:
> I think the only way to make this work properly is to factor the
> necessary parts out of init.d/xencommons into a new script which can
> be used by both xencommons and systemd. I'm not sure such a patch
> would be appropriate for 4.5 at this stage.
Yes, a he
Olaf Hering writes ("[PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in
systemd"):
> The sysv runlevel script handles the boolean variable XENSTORED_TRACE
> from sysconfig.xencommons to enable tracing. Recognize this also to
> the systemd service file.
...
> -ExecStart=/bin/sh -c "exec $XENSTOR
20 matches
Mail list logo
