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 manually
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 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 parser!
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 $@
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 xenstored,
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 xencommons and
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 script
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 admin has
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 $XENSTORED
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
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
11 matches
Mail list logo
