On 2/17/19 12:27 AM, Marek Marczykowski-Górecki wrote:
> On Sat, Feb 16, 2019 at 10:36:00PM +0100, Hans van Kranenburg wrote:
>> Actually, while looking at this again...
>>
>> In the init script, we already have...
>>
>> capability_check()
>> {
>> [ -e "/proc/xen/capabilities" ] || return 1
>> grep -q "control_d" /proc/xen/capabilities || return 1
>> return 0
>> }
>>
>> ...which gets called like this...
>>
>> capability_check
>> case "$?" in
>> 0) ;;
>> *) log_end_msg 255; exit ;;
>> esac
>>
>> Looking at /proc/xen/capabilities and seeing if there's control_d inside
>> seems to be a more common way to check if this is a dom0.
>>
>> It does log_end_msg 255 and 255 seems to be warning.
>
> systemd doesn't agree:
>
> Setting up xen-utils-common (4.11.1-2~) ...
> (...)
> Job for xen.service failed because the control process exited with error
> code.
> See "systemctl status xen.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript xen, action "restart" failed.
> ● xen.service - LSB: Xen daemons
> Loaded: loaded (/etc/init.d/xen; generated)
> Active: failed (Result: exit-code) since Sat 2019-02-16 18:16:04 EST;
> 6ms ago
> Docs: man:systemd-sysv-generator(8)
> Process: 7215 ExecStart=/etc/init.d/xen start (code=exited,
> status=255/EXCEPTION)
Hah! Yes, of course, because the exit without code will use the return
code of the previous command instead of 0. I forgot about that.
> Feb 16 18:16:04 d10test systemd[1]: Starting LSB: Xen daemons...
> Feb 16 18:16:04 d10test xen[7215]: Starting Xen daemons: (warning).
> Feb 16 18:16:04 d10test systemd[1]: xen.service: Control process exited,
> code=exited, status=255/EXCEPTION
> Feb 16 18:16:04 d10test systemd[1]: xen.service: Failed with result
> 'exit-code'.
> Feb 16 18:16:04 d10test systemd[1]: Failed to start LSB: Xen daemons.
> dpkg: error processing package xen-utils-common (--configure):
> installed xen-utils-common package post-installation script subprocess
> returned error exit status 1
>
> Full output: https://gist.github.com/marmarek/f6964e16157e69f5761e68ea1a925ae7
>
>> The upstream init script has...
>>
>> # run this script only in dom0:
>> # no capabilities file in xenlinux domU kernel
>> # empty capabilities file in pv_ops domU kernel
>> if test -f /proc/xen/capabilities && \
>> ! grep -q "control_d" /proc/xen/capabilities ; then
>> exit 0
>> fi
>>
>> ...which also doesn't look really good, since this exit 0 doesn't happen
>> when /proc/xen/capabilities does *not* exist, and the first domU I'm
>> looking inside here doesn't have it.
>
> Generally I (too?) try to migrate away from /proc/xen, that's why my
> patch use /sys/hypervisor/uuid instead.
Ok, I don't know too much about all the xen things in /proc and /sys
yet, but it seems the current check for a dom0 does its work, so let's
not change that right now.
But, change it to just exit 0. I added a change on top of the wip.testme
branch.
https://salsa.debian.org/xen-team/debian-xen/commits/wip.testme
Thanks,
Hans
