From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BD26C433F5 for ; Wed, 2 Feb 2022 16:26:22 +0000 (UTC) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) by mx.groups.io with SMTP id smtpd.web10.361.1643819181796050022 for ; Wed, 02 Feb 2022 08:26:21 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=JPnUOM/f; spf=pass (domain: gmail.com, ip: 209.85.210.47, mailfrom: krussell7711@gmail.com) Received: by mail-ot1-f47.google.com with SMTP id b12-20020a9d754c000000b0059eb935359eso19964599otl.8 for ; Wed, 02 Feb 2022 08:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0PomnhQNz4vmxxya0rp9POFTHTZv6oMh0+wIgiDqmkI=; b=JPnUOM/fQo9GPOR0OfgtslicasKkBPpEhXFSG2FFBa4msILBmDFI9lx3TsrS2ImVoV IKaCjB1atL5TkLsT5Y5mgdIOMy6aycfdeY0M2/PMw4v+q6QOuUDusaSP6LZYkIdy/MNr 5b3aJ15P5UOalN3ECDZfT4tnMwTZh/TUs64h9jdKLJs+HTxBT8TVI208rPHjssuNceCU GtWBZXuCN3qIfJBVxxv3ldAZ02/KwZTt7p2HRKdB0VKCQuh/kvM6KLCEkZJIHOa2doru Rb541oMW0B37lLuWnhoW2yEDMnymrEY+27e+PZevALp6pUUL6MLAx+m5tDoZl9HGVYUZ KwFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0PomnhQNz4vmxxya0rp9POFTHTZv6oMh0+wIgiDqmkI=; b=xmoRp1RI8d3aCypQfF+1qhk7pCDNeybA0y9+f+swmt57Dpr1PJ1h0vWLTeoHgDmAyV 1K0fca7QEuqVVewpEctNzZNAN1OqpjKDYmv1LBdjeUk6LOdhRlIVpmboTZPoIVRNwwVJ n0QdZxCaBRzXinHTcRGZMBCq0Ec9R0ZlKgahBnOWHdd+MrtS1Frw2EDbcn88lPhGYi+A m81dz5EsR8OH56rH/NPE06r+2kYd85A2OqGDere8U3tQtnrBquxqWVwqU/4knR1nK4cL mppA7jQdNjAmom/8QlJJM3Jh96kPFLlp/5bWsdzCcHUSzAIeSKWL2qSwb1EVr6UvRnoB OuzA== X-Gm-Message-State: AOAM533sTOt3nIlTXrVayCasldgZol3HTZ2kb4yD0zKQ5S4Zivh3sdQu P0/YoMD4e8AvfhWGNYJheMdcdrA9H9oXIRqPPp8= X-Google-Smtp-Source: ABdhPJzM/mApoYmryA4q3NJOg1Wmb6lOa/v01a/Go2b9tl993Cl+P7Vt062RXyoOqRAglFXCO1TEzwyHkjLH68GezNY= X-Received: by 2002:a9d:67d0:: with SMTP id c16mr16966375otn.270.1643819180979; Wed, 02 Feb 2022 08:26:20 -0800 (PST) MIME-Version: 1.0 References: <20210917080804.2545478-1-ch@denx.de> In-Reply-To: From: Kyle Russell Date: Wed, 2 Feb 2022 11:26:09 -0500 Message-ID: Subject: Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service To: Claudius Heine Cc: OE-core , Marek Vasut , Alex Kiernan , Alexander Kanavin , Alban Bedel , Wes Lindauer Content-Type: multipart/alternative; boundary="0000000000005b7b8a05d70b7a40" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 02 Feb 2022 16:26:22 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/161220 --0000000000005b7b8a05d70b7a40 Content-Type: text/plain; charset="UTF-8" Thanks, Claudius. On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine wrote: > Hi Kyle, > > On 2022-02-02 13:38, Kyle Russell wrote: > > Is this the correct approach? Even the systemd-udev-settle.service man > > pages recommends not using its service. Were the kernel modules really > > not loaded when rngd started? Or is the original problem just a matter > > of waiting for sufficient entropy? > > IIRC, the rngd could not find any random source device node (/dev/hwrng > in that case), so the service failed to start. > If /dev/hwrng didn't exist, this feels like the original problem was a misconfigured kernel or module that wasn't being loaded properly. > The patch you are commenting on only adds `Wants` weak dependency to > make sure `systemd-udev-settle.service` is pulled in to the job queue, > the `After` ordering rule was already there. > Correct. Just because an `After` exists does not mean the service gets pulled into the job queue, so prior to this change no other service was causing the deprecated systemd-udev-settle.service to be run during boot. But now, every device including openssh (which has a default PACKAGECONFIG option for rng-tools) now depends on this deprecated service, which may cause unexpected boot delays. > So changing this service file to be triggered by a udev event or maybe > wrap it in a script, which makes sure the right modules are loaded and > device nodes are available, could be an improvement, but it would be out > of scope of this patch IMO. > I'm more curious whether this change should be reverted from upstream. It seems like a drop-in file could have been applied to your distro instead of adding a dependency on a deprecated service for all openssh users. Kyle > > > > On Fri, Sep 17, 2021 at 4:08 AM Claudius Heine > > wrote: > > > > rngd needs to start after `systemd-udev-settle` in order for the > kernel > > modules of the random source hardware to be loaded before it is > started. > > > > However, since the `rngd.service` does not require or want > > `systemd-udev-settle.service` it might not be scheduled for start and > > the `After=systemd-udev-settle.service` there has no effect. > > > > Adding `Wants=systemd-udev-settle.service` provides a weak > requirement > > to it, so that the `rngd` is started after it, if possible. > > > > Signed-off-by: Claudius Heine > > > --- > > > > Hi, > > > > this is a fix, which should probably be backported to the maintained > > releases. > > > > regards, > > Claudius > > > > meta/recipes-support/rng-tools/rng-tools/rngd.service | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service > > b/meta/recipes-support/rng-tools/rng-tools/rngd.service > > index 0559b97991..568686e80e 100644 > > --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service > > +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service > > @@ -3,6 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon > > DefaultDependencies=no > > After=systemd-udev-settle.service > > Before=sysinit.target shutdown.target > > +Wants=systemd-udev-settle.service > > Conflicts=shutdown.target > > > > [Service] > > -- > > 2.33.0 > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#156129): > > https://lists.openembedded.org/g/openembedded-core/message/156129 > > > > Mute This Topic: https://lists.openembedded.org/mt/85671578/4454381 > > > > Group Owner: openembedded-core+owner@lists.openembedded.org > > > > Unsubscribe: > > https://lists.openembedded.org/g/openembedded-core/unsub > > > > [bkylerussell@gmail.com ] > > -=-=-=-=-=-=-=-=-=-=-=- > > > --0000000000005b7b8a05d70b7a40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Claudius.

On Wed, Feb 2, 2022 = at 8:08 AM Claudius Heine <ch@denx.de&= gt; wrote:
Hi Ky= le,

On 2022-02-02 13:38, Kyle Russell wrote:
> Is this the correct approach?=C2=A0 Even the systemd-udev-settle.servi= ce man
> pages recommends not using its service.=C2=A0 Were the kernel modules = really
> not loaded when rngd started?=C2=A0 Or is the original problem just a = matter
> of waiting for sufficient entropy?

IIRC, the rngd could not find any random source device node (/dev/hwrng in that case), so the service failed to start.

If /dev/hwrng didn't exist, this feels like the original proble= m was a misconfigured
kernel or module that wasn't being load= ed properly.
=C2=A0
The patch you are commenting on only adds `Wants` weak dependency to
make sure `systemd-udev-settle.service` is pulled in to the job queue,
the `After` ordering rule was already there.

Correct.=C2=A0 Just because an `After` exists does not mean the servi= ce gets pulled into
the job queue, so prior to this change no oth= er service was causing the deprecated
systemd-udev-settle.service= to be run during boot.=C2=A0 But now, every device including
ope= nssh (which has a default PACKAGECONFIG option for rng-tools) now depends
on this deprecated service, which may cause unexpected boot delays= .
=C2=A0
So changing this service file to be triggered by a udev event or maybe
wrap it in a script, which makes sure the right modules are loaded and
device nodes are available, could be an improvement, but it would be out of scope of this patch IMO.

I'm mor= e curious whether this change should be reverted from upstream.=C2=A0 It se= ems
like a drop-in file could have been applied to your distro in= stead of adding a dependency
on a deprecated service for all open= ssh users.

Kyle
=C2=A0
=
>
> On Fri, Sep 17, 2021 at 4:08 AM Claudius Heine <ch@denx.de
> <mailto:ch@denx.de<= /a>>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0rngd needs to start after `systemd-udev-settle` in = order for the kernel
>=C2=A0 =C2=A0 =C2=A0modules of the random source hardware to be loaded = before it is started.
>
>=C2=A0 =C2=A0 =C2=A0However, since the `rngd.service` does not require = or want
>=C2=A0 =C2=A0 =C2=A0`systemd-udev-settle.service` it might not be sched= uled for start and
>=C2=A0 =C2=A0 =C2=A0the `After=3Dsystemd-udev-settle.service` there has= no effect.
>
>=C2=A0 =C2=A0 =C2=A0Adding `Wants=3Dsystemd-udev-settle.service` provid= es a weak requirement
>=C2=A0 =C2=A0 =C2=A0to it, so that the `rngd` is started after it, if p= ossible.
>
>=C2=A0 =C2=A0 =C2=A0Signed-off-by: Claudius Heine <ch@denx.de <mailto:ch@denx.de>>
>=C2=A0 =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0Hi,
>
>=C2=A0 =C2=A0 =C2=A0this is a fix, which should probably be backported = to the maintained
>=C2=A0 =C2=A0 =C2=A0releases.
>
>=C2=A0 =C2=A0 =C2=A0regards,
>=C2=A0 =C2=A0 =C2=A0Claudius
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0meta/recipes-support/rng-tools/rng-tools/rng= d.service | 1 +
>=C2=A0 =C2=A0 =C2=A0 =C2=A01 file changed, 1 insertion(+)
>
>=C2=A0 =C2=A0 =C2=A0diff --git a/meta/recipes-support/rng-tools/rng-too= ls/rngd.service
>=C2=A0 =C2=A0 =C2=A0b/meta/recipes-support/rng-tools/rng-tools/rngd.ser= vice
>=C2=A0 =C2=A0 =C2=A0index 0559b97991..568686e80e 100644
>=C2=A0 =C2=A0 =C2=A0--- a/meta/recipes-support/rng-tools/rng-tools/rngd= .service
>=C2=A0 =C2=A0 =C2=A0+++ b/meta/recipes-support/rng-tools/rng-tools/rngd= .service
>=C2=A0 =C2=A0 =C2=A0@@ -3,6 +3,7 @@ Description=3DHardware RNG Entropy = Gatherer Daemon
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultDependencies=3Dno
>=C2=A0 =C2=A0 =C2=A0 =C2=A0After=3Dsystemd-udev-settle.service
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Before=3Dsysinit.target shutdown.target
>=C2=A0 =C2=A0 =C2=A0+Wants=3Dsystemd-udev-settle.service
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Conflicts=3Dshutdown.target
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[Service]
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A02.33.0
>
>
>=C2=A0 =C2=A0 =C2=A0-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
>=C2=A0 =C2=A0 =C2=A0Links: You receive all messages sent to this group.=
>=C2=A0 =C2=A0 =C2=A0View/Reply Online (#156129):
>=C2=A0 =C2=A0 =C2=A0https://lis= ts.openembedded.org/g/openembedded-core/message/156129
>=C2=A0 =C2=A0 =C2=A0<https:/= /lists.openembedded.org/g/openembedded-core/message/156129>
>=C2=A0 =C2=A0 =C2=A0Mute This Topic: https://l= ists.openembedded.org/mt/85671578/4454381
>=C2=A0 =C2=A0 =C2=A0<https://lists.openembe= dded.org/mt/85671578/4454381>
>=C2=A0 =C2=A0 =C2=A0Group Owner: openembedded-core+owner@lis= ts.openembedded.org
>=C2=A0 =C2=A0 =C2=A0<mailto:openembedded-core%2Bowner@l= ists.openembedded.org>
>=C2=A0 =C2=A0 =C2=A0Unsubscribe:
>=C2=A0 =C2=A0 =C2=A0https://lists.openem= bedded.org/g/openembedded-core/unsub
>=C2=A0 =C2=A0 =C2=A0<https://lists.op= enembedded.org/g/openembedded-core/unsub>
>=C2=A0 =C2=A0 =C2=A0[bkylerussell@gmail.com <mailto:bkylerussell@gmail.com>]
>=C2=A0 =C2=A0 =C2=A0-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
>
--0000000000005b7b8a05d70b7a40--