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

Re: [Xen-devel] [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd

Olaf Hering writes ("Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in 
> 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 helper script to launch just xenstored would help. But which part
> would do the final "exec"? Perhaps the sysv script has to fork a shell
> like its done above. I will have a look at this. 

If there's no other way to do it, you could have the helper script
take an argument (or a named (environment) parameter) to discover
whether to call exec.

> Are you opposed to the idea to support XENSTORED_TRACE for systemd right
> in 4.5.0?

Ideally I would like to support XENSTORED_TRACE for systemd in 4.5.0.

But I do not want to duplicate the functionality at all.  systemd
seems to make it difficult to support XENSTORED_TRACE without either
duplicating functionality or refactoring the existing init.d script.
(Indeed the very fact that XENSTORED_TRACE does not work with systemd
right now is due to the systemd startup of xenstored being decoupled
from the init script code which handles XENSTORED_TRACE.  I seem to
remember making some comments about this kind of thing at the time...)

And I am currently unconvinced that refactoring things at this stage
of the 4.5 release is appropriate.  But others may have a different

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.


Xen-devel mailing list



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