[OE-core] [PATCH 1/2] systemd: upgrade to 239

[ChenQi]

On 07/26/2018 11:07 PM, Peter Kjellerstedt wrote:
>> -----Original Message-----
>> From: Ricardo Salveti <rsalveti at rsalveti.net>
>> Sent: den 26 juli 2018 16:37
>> To: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
>> Cc: ChenQi <Qi.Chen at windriver.com>; openembedded-
>> core at lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239
>>
>> On Thu, Jul 26, 2018 at 9:30 AM, Peter Kjellerstedt
>> <peter.kjellerstedt at axis.com> wrote:
>>>> -----Original Message-----
>>>> From: openembedded-core-bounces at lists.openembedded.org
>> <openembedded-
>>>> core-bounces at lists.openembedded.org> On Behalf Of ChenQi
>>>> Sent: den 26 juli 2018 07:51
>>>> To: Ricardo Salveti <rsalveti at rsalveti.net>
>>>> Cc: openembedded-core at lists.openembedded.org
>>>> Subject: Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239
>>>>
>>>> On 07/26/2018 07:05 AM, Ricardo Salveti wrote:
>>>>> On Mon, Jul 16, 2018 at 11:05 PM, Chen Qi <Qi.Chen at windriver.com>
>> wrote:
>>>>>> Upgrade systemd to 239.
>>> [cut]
>>>
>>>>>> 3. update-alternatives changes
>>>>>>     The utilities like shutdown, poweroff, etc. are now created as
>> symlinks
>>>>>>     at do_install. So there's no need to use update-alternatives
>> mechanism
>>>>>>     anymore to create the symlinks now. In addtion, I don't think
>> we> now
>>>>>>     support multiple init systems at one running system, so
>> there's really
>>>>>>     no need to use update-alternatives mechanism here.
>>>>> I noticed that reboot stopped working locally as I had busybox
>>>>> installed together with systemd, and the busybox version ended up
>>>>> being used as it was provided via update-alternatives.
>>>>>
>>>>> Looking for possible similar broken links, I found that
>>>>> update-alternatives ended up pointing reboot, halt and poweroff to
>> the
>>>>> busybox binary instead of systemctl. Should we revert the changes
>> and
>>>>> bring back update-alternatives for them?
>>>>>
>>>>> Thanks,
>>>> I think the correct direction to fix this problem is to make busybox
>>>> only provide init utilities (reboot, halt, etc) when init manager is
>>>> set to busybox.
>>>>
>>>> We current have in busybox recipe's SRC_URI:
>>>>              ${@["",
>>>> "file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') ==
>>>> 'busybox')]} \
>>>>
>>>> I think the init utilities should be moved to init.cfg.
>>>>
>>>> Please check my logic to see if you can agree with it.
>>>> We have two facts here.
>>>> 1. Init utilities (reboot, halt, etc.) are tightly bond to the
>> specific
>>>> implementation of PID 1.
>>>> 2. We only allow one PID 1 in our image. (VIRTUAL-
>> RUNTIME_init_manager).
>>>> So we can conclude from the above two facts that it does not make
>> much
>>>> sense to have multiple providers of init utilities while we only
>> allow
>>>> one PID 1 provider on image.
>>>>
>>>> After all, we are using update-*alternatives*, things that this
>>>> mechanism manages are supposed to generally serve as alternatives to
>>>> each other.
>>>>
>>>> Best Regards,
>>>> Chen Qi
>>> For what it is worth, we have a package that installs wrappers for
>> init and
>>> reboot, which is now causing image creation to fail due to the change
>> to
>>> systemd since both packages now try to install init and reboot. I can
>> of
>>> course add a systemd_%.bbappend to remove init and reboot, but that
>> means
>>> the systemd package is broken unless the package with the wrappers is
>>> always installed.
>> Curious to why you need such wrappers, but wasn't it a problem before
> Well, to be honest, I did not know we had those wrappers until the image
> creation broke due to the change to the systemd recipe. I am not responsible
> for our use of systemd, so I have no idea why we have those wrappers...
>
>> even when we had update-alternatives for such utilities (e.g.
>> update-alternatives failing to link init/reboot because of your
>> wrappers when creating the rootfs)?
> I have not looked into it, but it seems the installation of the wrappers
> silently overwrites the links created by update-alternatives.

A wrappers is usually written like this:
<hook actions>
<actual call to the real binary>

sysv has the runlevel/service mechanism, and systemd has unit mechanism.
We'd better use such mechanisms to do the hook actions.

For reboot, you may want to look at rc6.d for sysvinit and reboot.target 
for systemd.
As an example on systemd, check 
/lib/systemd/system/reboot.target.wants/systemd-update-utmp-runlevel.service.

Best Regards,
Chen Qi

>> Cheers,
>> --
>> Ricardo Salveti de Araujo
> //Peter
>