[meta-virtualization] [PATCH] cgroup-lite: remove incorrect SYSTEMD_AUTO_ENABLE setting

Alex Kiernan alex.kiernan at gmail.com
Mon May 6 22:57:22 PDT 2019


On Mon, May 6, 2019 at 5:16 PM Jonas Bonn <jonas at norrbonn.se> wrote:
>
>
>
> On Mon, May 6, 2019, 16:42 Alex Kiernan <alex.kiernan at gmail.com> wrote:
>>
>> On Mon, May 6, 2019 at 2:38 PM Paul Barker <paul at betafive.co.uk> wrote:
>> >
>> > On 06/05/2019 03:00, Hongxu Jia wrote:
>> > > Since commit [154abbc329 systemd: create preset files instead of
>> > > installing in image] applied in oe-core, it checks SYSTEMD_AUTO_ENABLE
>> > > ...
>> > > |ERROR: cgroup-lite-1.15-r0 do_package: SYSTEMD_AUTO_ENABLE_cgroup-lite
>> > > 'mask' is not 'enable' or 'disable'
>> > > ...
>> > >
>> > > Signed-off-by: Hongxu Jia <hongxu.jia at windriver.com>
>> > > ---
>> > >   recipes-containers/cgroup-lite/cgroup-lite_1.15.bb | 1 -
>> > >   1 file changed, 1 deletion(-)
>> > >
>> > > diff --git a/recipes-containers/cgroup-lite/cgroup-lite_1.15.bb b/recipes-containers/cgroup-lite/cgroup-lite_1.15.bb
>> > > index 7b48c3a..cb16a65 100644
>> > > --- a/recipes-containers/cgroup-lite/cgroup-lite_1.15.bb
>> > > +++ b/recipes-containers/cgroup-lite/cgroup-lite_1.15.bb
>> > > @@ -18,7 +18,6 @@ INITSCRIPT_PARAMS = "start 8 2 3 4 5 . stop 20 0 1 6 ."
>> > >   # where systemd is in use.
>> > >   SYSTEMD_PACKAGES = "${PN}"
>> > >   SYSTEMD_SERVICE_${PN} = "cgroups-init.service"
>> > > -SYSTEMD_AUTO_ENABLE_${PN} = "mask"
>> >
>> > Looking at the commit message from when this was added
>> > (http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=5b13da8e575ac746b46426f2471bf004b2201e41),
>> > the intention is that the service is indeed masked.
>> >
>> > Rather than breaking this behaviour I'd like to see if we can support
>> > this in oe-core.
>> >
>> > Cc-ing Jonas and Alex on this one - is it simple to support> `SYSTEMD_AUTO_ENABLE = "mask"` after the recent systemd changes in oe-core?
>> >
>>
>> Okay, so going back and reading the code, previously you could say
>> anything to systemctl that was understood by the script (enable,
>> disable, mask, preset), so I think there's just mask we need to put
>> back. That said there's probably a hole in enable/disable where we
>> should delete any existing symlink to allow the preset logic to
>> control it correctly.
>
>
> Remember, the preset logic runs only on first boot when /etc/systemd/system is empty. There are no symlinks to remove.
>

I'm really thinking of the private systemctl implementation here,
fixing them up during image construction where someone's manually
created them.

>> I think it'll mean that you end up with the SYSTEMD_AUTO_ENABLE
>> control doing different things in different phases, which is possibly
>> surprising, but I think preferable.
>
>
> 'mask' is not something you can do with preset.
>
> The argument 'mask' to SYSTEMD_AUTO_ENABLE in that recipe is bogus. The correct argument is 'disable'. If you look at what the recipe is doing it is already setting up a permanent link to /dev/null for the service so it is already effectively masked... and unmaskable at that!
>

The question for me is, is SYSTEMD_AUTO_ENABLE an interface to preset
files, or something broader; where we were was SYSTEMD_AUTO_ENABLE was
an interface to systemctl, now it's a much narrower thing which just
gets you preset file entries.

If SYSTEMD_AUTO_ENABLE is an interface for controlling the general
systemd setup we avoid manual symlink creation and have a place we can
build out the stateless stuff - to me that seems like a better option.

The other thing which I suspect we had and now don't was the ability
to use enable as a mechanism for instantiating templates.

Something else that bothers me, we're doing the exact opposite of the
recommendation in writing preset files as part of our packages:

"It is not recommended to ship preset files within the respective
software packages implementing the units, but rather centralize them
in a distribution or spin default policy, which can be amended by
administrator policy."

But I don't have a better answer right now...

--
Alex Kiernan


More information about the meta-virtualization mailing list