Re: [Xen-devel] [PATCH] systemd: add support initial systemd service files

[M A Young <m.a.young@xxxxxxxxxxxx>]

On Wed, 12 Mar 2014, Luis R. Rodriguez wrote:

> On Wed, Mar 12, 2014 at 12:44 PM, M A Young <m.a.young@xxxxxxxxxxxx> wrote:
> > Fedora has the following systemd files (in xen-4.3)
> >
> > proc-xen.mount - to mount /proc/xen
> OK
>
> > var-lib-xenstored.mount - to create a tmpfs mount at /var/lib/xenstored
> /var/lib/xenstored is the default path but why is tmpfs used? Are we
> supposed to shred the TBD upon reboot? I can see how using memory
> would yield better results than a filesystem, and it seems my tbd gets
> rid of anything other than dom0 data after reboot. Without starting
> xenstored I get upon boot:
I followed what the Fedora package was already doing when I took over 
managing it. However I believe the xencommons script clears out 
/var/lib/xenstored so this is equivalent behaviour.
> ...
> > These don't try to start a qemu-xen instance as the current xencommons
> > init.d script does,
> Any particular reason for this? I see it only eats up about
Fedora just hasn't done it so far. Perhaps it should, but I imagine 
offical systemd files would be expected to do this.
> ...
> > and we would probably need a xencommons.service to stop
> > a xencommons init.d script being run.
> What would be stopped exactly? If you've split out consoled to its own
> control domains and if you don't run the new initial qemu instance
> that the upstream xencommons script does start then what's left to
> stop? xensored cannot be currently stopped as it seems threads in the
> kernel are not kicked to stop using it. This could likely be fixed
> though.
Systemd will use init.d scripts if no corresponding .service file 
exists. The idea of adding a xencommons.service file would be to stop the 
xencommons init.d script being run and trying to do what the other systemd 
files have already done if both systemd and init.d scripts are installed.
        Michael Young

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