CentOS virt - Sep 2015 - Report on Xen-4.6rc2 from virt7-xen-46-candidate

Hi

I gave the new Xen-4.6rc2 a spin on a CentOS 7 virtualisation guest 
(nested-xen). I haven't yet started testing guests, but rather looked at 
the install itself.

One issue, I found, was with xenstored.service and the corresponding 
unit-file:

[root at xencen7ws ~]# systemctl status xenstored
xenstored.service - The Xen xenstore
    Loaded: loaded (/usr/lib/systemd/system/xenstored.service; disabled)
    Active: active (running) since Tue 2015-09-08 23:13:43 CEST; 13min ago
   Process: 757 ExecStartPre=/bin/mkdir -p /var/run/xen (code=exited, 
status=0/SUCCESS)
   Process: 753 ExecStartPre=/bin/rm -f /var/lib/xenstored/tdb* 
(code=exited, status=0/SUCCESS)
   Process: 740 ExecStartPre=/bin/grep -q control_d 
/proc/xen/capabilities (code=exited, status=0/SUCCESS)
  Main PID: 760 (xenstored)
    CGroup: /system.slice/xenstored.service
            ??760 /usr/sbin/xenstored

Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: TDB: 
tdb_open_ex: could not open file /var/lib/xenstored/tdb: No such file or 
directory
Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking 
store ...
Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking 
store complete.
Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: xenstored is 
ready
Sep 08 23:13:43 xencen7ws.virtfinity.local systemd[1]: Started The Xen 
xenstore.

As you can see, xenstored.service is running, but disabled by the 
package installation. This is, because xenstored.service apparently got 
overseen in the source-rpm's spec-file's post runtime/preun runtime. See
diff [1] for details.

Also, I think xenstored should write a pidfile. You might consider 
adding to /usr/lib/systemd/system/xenstored.service:
PIDFile=/var/run/xenstored.pid
and change
ExecStart=/usr/sbin/xenstored
to
ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid 
$XENSTORED_ARGS

Hope this helps, this is just a quick start. I'll continue checking and 
reporting during the next days.

Regards,
Thomas


[1]
diff -u rpmbuild-xen-4.6rc2x-3.el7-org/SPECS/xen.spec 
rpmbuild-xen-4.6rc2x-3.el7/SPECS/xen.spec
--- rpmbuild-xen-4.6rc2x-3.el7-org/SPECS/xen.spec    2015-09-08 
18:47:00.000000000 +0200
+++ rpmbuild-xen-4.6rc2x-3.el7/SPECS/xen.spec    2015-09-09 
00:06:27.558344410 +0200
@@ -403,6 +403,7 @@
   /bin/systemctl enable xen-qemu-dom0-disk-backend.service
   /bin/systemctl enable xen-init-dom0.service
   /bin/systemctl enable xenconsoled.service
+ /bin/systemctl enable xenstored.service
  # /bin/systemctl enable xendomains.service
  %endif

@@ -422,6 +423,7 @@
   /bin/systemctl disable xen-init-dom0.service
   /bin/systemctl disable xen-qemu-dom0-disk-backend.service
   /bin/systemctl disable xenconsoled.service
+ /bin/systemctl disable xenstored.service
  # /bin/systemctl disable xendomains.service
  %endif
  fi

On Tue, Sep 8, 2015 at 11:25 PM, T.Weyergraf <T.Weyergraf at
virtfinity.de> wrote:
> Hi
>
> I gave the new Xen-4.6rc2 a spin on a CentOS 7 virtualisation guest
> (nested-xen). I haven't yet started testing guests, but rather looked
at the
> install itself.
>
> One issue, I found, was with xenstored.service and the corresponding
> unit-file:
>
> [root at xencen7ws ~]# systemctl status xenstored
> xenstored.service - The Xen xenstore
>    Loaded: loaded (/usr/lib/systemd/system/xenstored.service; disabled)
>    Active: active (running) since Tue 2015-09-08 23:13:43 CEST; 13min ago
>   Process: 757 ExecStartPre=/bin/mkdir -p /var/run/xen (code=exited,
> status=0/SUCCESS)
>   Process: 753 ExecStartPre=/bin/rm -f /var/lib/xenstored/tdb*
(code=exited,
> status=0/SUCCESS)
>   Process: 740 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> (code=exited, status=0/SUCCESS)
>  Main PID: 760 (xenstored)
>    CGroup: /system.slice/xenstored.service
>            ??760 /usr/sbin/xenstored
>
> Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: TDB:
tdb_open_ex:
> could not open file /var/lib/xenstored/tdb: No such file or directory
> Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking store
> ...
> Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking store
> complete.
> Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: xenstored is
> ready
> Sep 08 23:13:43 xencen7ws.virtfinity.local systemd[1]: Started The Xen
> xenstore.
>
> As you can see, xenstored.service is running, but disabled by the package
> installation. This is, because xenstored.service apparently got overseen in
> the source-rpm's spec-file's post runtime/preun runtime. See diff
[1] for
> details.
The Xen documentation (in INSTALL) recommends enabing
xen-init-dom0.service, xenconsoled.service, and
xen-qemu-dom0-disk-backend.service.  I didn't specifically enable
xenstored, because I figured that was the "systemd way" -- specify the
dependencies, specify what you actually want (i.e., a xen dom0), and
let it sort out what actually needs to be started.

Is there a good reason to specifically enable xenstored, even though
it will start automatically because of dependencies?

(I really am asking here -- this whole systemd thing is really new to me.)
> Also, I think xenstored should write a pidfile. You might consider adding
to
> /usr/lib/systemd/system/xenstored.service:
> PIDFile=/var/run/xenstored.pid
> and change
> ExecStart=/usr/sbin/xenstored
> to
> ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid
> $XENSTORED_ARGS
>
> Hope this helps, this is just a quick start. I'll continue checking and
> reporting during the next days.
I think because systemd doesn't do forking, that it doesn't need a
pidfile.  In fact, if xenstored detects that it's running under
systemd, it will actually ignore the --pid-file directive.

 -George

Hey,

What do you mean by doesn't do forking?
It allows forking processes if the application can do that.
It doesn't fork them by default but ,is it really needed?
If xenstored is testing to be run under systemd and not forks itself 
because of it, that's another thing.

Eliezer

On 09/09/2015 12:40, George Dunlap wrote:
> I think because systemd doesn't do forking, that it doesn't need a
> pidfile.  In fact, if xenstored detects that it's running under
> systemd, it will actually ignore the --pid-file directive.
>
>   -George

On 09/09/2015 11:40 AM, George Dunlap wrote:
> On Tue, Sep 8, 2015 at 11:25 PM, T.Weyergraf <T.Weyergraf at
virtfinity.de> wrote:
>> Hi
>>
>> I gave the new Xen-4.6rc2 a spin on a CentOS 7 virtualisation guest
>> (nested-xen). I haven't yet started testing guests, but rather
looked at the
>> install itself.
>>
>> One issue, I found, was with xenstored.service and the corresponding
>> unit-file:
>>
>> [root at xencen7ws ~]# systemctl status xenstored
>> xenstored.service - The Xen xenstore
>>     Loaded: loaded (/usr/lib/systemd/system/xenstored.service;
disabled)
>>     Active: active (running) since Tue 2015-09-08 23:13:43 CEST; 13min
ago
>>    Process: 757 ExecStartPre=/bin/mkdir -p /var/run/xen (code=exited,
>> status=0/SUCCESS)
>>    Process: 753 ExecStartPre=/bin/rm -f /var/lib/xenstored/tdb*
(code=exited,
>> status=0/SUCCESS)
>>    Process: 740 ExecStartPre=/bin/grep -q control_d
/proc/xen/capabilities
>> (code=exited, status=0/SUCCESS)
>>   Main PID: 760 (xenstored)
>>     CGroup: /system.slice/xenstored.service
>>             ??760 /usr/sbin/xenstored
>>
>> Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: TDB:
tdb_open_ex:
>> could not open file /var/lib/xenstored/tdb: No such file or directory
>> Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking
store
>> ...
>> Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking
store
>> complete.
>> Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: xenstored is
>> ready
>> Sep 08 23:13:43 xencen7ws.virtfinity.local systemd[1]: Started The Xen
>> xenstore.
>>
>> As you can see, xenstored.service is running, but disabled by the
package
>> installation. This is, because xenstored.service apparently got
overseen in
>> the source-rpm's spec-file's post runtime/preun runtime. See
diff [1] for
>> details.
> The Xen documentation (in INSTALL) recommends enabing
> xen-init-dom0.service, xenconsoled.service, and
> xen-qemu-dom0-disk-backend.service.  I didn't specifically enable
> xenstored, because I figured that was the "systemd way" --
specify the
> dependencies, specify what you actually want (i.e., a xen dom0), and
> let it sort out what actually needs to be started.
>
> Is there a good reason to specifically enable xenstored, even though
> it will start automatically because of dependencies?
>
> (I really am asking here -- this whole systemd thing is really new to me.)
If the Xen docs (which I haven't checked) state it should not be 
enabled, it's probably best to follow that advice. xenstored is a bit 
tricky, as it's not designed to be started/stopped or restarted as a 
regular service.
For my initial report, I checked the stuff I recycled from fedora, which 
indeed enables xenstored.service and uses a pidfile. From an 
administrative point of view, I like pidfiles, as they allow to check a 
service from a script with very little effort. xenstored-pidfiles have 
been present all the time except until lately (apparently) and I dislike 
changing things like that without good reason.
Suffice to say, that there might be a good reason.
I found the initial systemd-related patches to Xen, adding the unit 
files, but I still need to find the patches changing that behaviour and 
explaining the reasons.
>
>> Also, I think xenstored should write a pidfile. You might consider
adding to
>> /usr/lib/systemd/system/xenstored.service:
>> PIDFile=/var/run/xenstored.pid
>> and change
>> ExecStart=/usr/sbin/xenstored
>> to
>> ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid
>> $XENSTORED_ARGS
>>
>> Hope this helps, this is just a quick start. I'll continue checking
and
>> reporting during the next days.
> I think because systemd doesn't do forking, that it doesn't need a
> pidfile.  In fact, if xenstored detects that it's running under
> systemd, it will actually ignore the --pid-file directive.
A quick check shows xenstored for systemd to create the socket (in the 
systemd case). I will read up more code and patches.

For the time being, you are right. Let's not change, what appears to be 
there for a reason. Once up and running, your packages provide a working 
xenstored, so there is nothing "broken" by any
means.
>
>   -George
Regards,
Thomas
> _______________________________________________
> CentOS-virt mailing list
> CentOS-virt at centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt