[Pkg-xen-devel] [PATCH 08/13] xen init script: rewrite xenstored start logic

[Hans van Kranenburg]

On 2/12/19 7:21 PM, Hans van Kranenburg wrote:
> On 2/12/19 7:14 PM, Ian Jackson wrote:
>> Hans van Kranenburg writes ("Re: [PATCH 08/13] xen init script: rewrite xenstored start logic"):
>>> So the question we should answer first is: What do we allow the user to
>>> set as value? /bin/bash? And how should the init script deal with that?
>>
>> If they specify an absolute path, it should be used.  Eg,
>>   /home/alice/Xen/xen/tools/xenstore/xenstore

So, if I have

  /home/knorrie/xenstore-mouton

and start that, and then change it to

  /home/knorrie/xenstore-kebab

...then do /etc/init.d/xen restart, then start-stop will not see a
matching process because there's no way it can know about this
xenstore-mouton binary which is still running. I end up with stopped
xenconsoled, and then xenstore-kebab will be started, which fails and
the whole thing aborts.

Option 1: simplify check to just do -f pidfile existence, like upstream
launch-xenstore does.
Option 2: do something with the `xenstore-read -s /` check from the
timeout loop. If it connects and reads, it's apparently running, boom, done.

Or a combination... or...

Whraagh, actually, instead of continuing with this... Maybe we should
just call launch-xenstore from the init script, and butcher it a bit
with a patch in the packaging...

* Change /etc/default/xencommons to /etc/default/xen
* Change the echo line into lsb_blah.
* Change the startup command into start-stop-daemon.
* Maybe do something with the `xenstore-read -s /` check? Why is this
used in Debian in the timeout loop instead? Is it better than -f pidfile?
* We already remove the section about XENSTORETYPE in /etc/default/xen,
so the domain part in it is just inactive code.

Then we have the script with build-replaced @@ in it and are closer to
looking at changes which we might try upstreaming later (converting to
lsb_etc for example.) And, we're closer to including systemd stuff,
since that simply also reuses the launch-xenstore. (!)

Also, apparently init-dom0 is not done inside launch-xenstore, but in
xencommons:

        @XEN_SCRIPT_DIR@/launch-xenstore || exit 1

        echo Setting domain 0 name, domid and JSON config...
        ${LIBEXEC_BIN}/xen-init-dom0

So, even the patch to move that into launch-xenstore because it wil only
print "Bweuuh, I have nothing to do" in all other cases can go upstream..

What do you think?

>> If the user specifies /bin/bash they get to keep all the resulting
>> pieces.
>>
>>> Or do you want to be able to use this to run your own xenstored
>>> replacement implementation from /usr/local/ian/ixenstored ?
>>
>> Right.  Or a wrapper script or something (although s-s-d will
>> mishandle that).
> 
> Yes, I'm no start-stop-daemon expert, but this should be well tested in
> combination with the already-running check.
> 
> Having the init script wrongly start another xenstored just makes
> everything hang withouta good explanation to the user.

K