[PATCH] rng-tools: add systemd-udev-settle wants to service

[PATCH] rng-tools: add systemd-udev-settle wants to service

[Claudius Heine]

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 <ch@denx.de>
---

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

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Kyle Russell]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

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?

On Fri, Sep 17, 2021 at 4:08 AM Claudius Heine <ch@denx.de> 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 <ch@denx.de>
> ---
>
> 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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 3013 bytes --]

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Claudius Heine]

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.

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.

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.

regards,
Claudius

> 
> On Fri, Sep 17, 2021 at 4:08 AM Claudius Heine <ch@denx.de 
> <mailto:ch@denx.de>> 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 <ch@denx.de <mailto:ch@denx.de>>
>     ---
> 
>     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
>     <https://lists.openembedded.org/g/openembedded-core/message/156129>
>     Mute This Topic: https://lists.openembedded.org/mt/85671578/4454381
>     <https://lists.openembedded.org/mt/85671578/4454381>
>     Group Owner: openembedded-core+owner@lists.openembedded.org
>     <mailto:openembedded-core%2Bowner@lists.openembedded.org>
>     Unsubscribe:
>     https://lists.openembedded.org/g/openembedded-core/unsub
>     <https://lists.openembedded.org/g/openembedded-core/unsub>
>     [bkylerussell@gmail.com <mailto:bkylerussell@gmail.com>]
>     -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Kyle Russell]

[-- Attachment #1: Type: text/plain, Size: 4206 bytes --]

Thanks, Claudius.

On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de> 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 <ch@denx.de
> > <mailto:ch@denx.de>> 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 <ch@denx.de <mailto:ch@denx.de>>
> >     ---
> >
> >     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
> >     <https://lists.openembedded.org/g/openembedded-core/message/156129>
> >     Mute This Topic: https://lists.openembedded.org/mt/85671578/4454381
> >     <https://lists.openembedded.org/mt/85671578/4454381>
> >     Group Owner: openembedded-core+owner@lists.openembedded.org
> >     <mailto:openembedded-core%2Bowner@lists.openembedded.org>
> >     Unsubscribe:
> >     https://lists.openembedded.org/g/openembedded-core/unsub
> >     <https://lists.openembedded.org/g/openembedded-core/unsub>
> >     [bkylerussell@gmail.com <mailto:bkylerussell@gmail.com>]
> >     -=-=-=-=-=-=-=-=-=-=-=-
> >
>

[-- Attachment #2: Type: text/html, Size: 6884 bytes --]

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Claudius Heine]

On 2022-02-02 17:26, Kyle Russell wrote:
> Thanks, Claudius.
> 
> On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de 
> <mailto:ch@denx.de>> 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.

Yes, however it is a timing issue. The module was loaded properly at 
bootup, however at the time rngd was started the module was not loaded 
yet and thus the service fails to start. If it would be delayed until 
the module is loaded everything would be fine.

It does not happen if the module is compiled into the kernel or if a 
initramfs is used which loads the module (I think). I our case it 
happend with the caam module as an external module loaded on boot from 
the real root file system.

>     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.

This patch just adds a missing entry into the service file. If you have 
solved the described issue in some way and can revert this patch and 
remove the `Wants=systemd-udev-settle.service` then you can also remove 
the `After=systemd-udev-settle.service` at the same time and at that 
point you can just remove both of those entries directly in the patch 
that solved the timing issue.

I agree that `systemd-udev-settle.service` should probably not be used 
anymore, however that file already used it in a non-functional way and 
all this patch did was make it fulfill its intended function.

In retrospect I probably should have tried to find a way to remove the 
usage of `systemd-udev-settle.service` completely, when I looked into 
the issue, however all this patch in essence does is revive dead code, 
which was already in place.

Also I think at that time I couldn't find a more precise instrument in 
systemds massive toolbox to delay the start of rngd and services that 
should be started in succession until the just the hardware random 
generator device is ready and `After=systemd-udev-settle.service` was 
already there. I guess some `ExecStartPre=` script which delays the 
start until the conditions are met could be implemented, but that seems 
a bit hackish.

regards,
Claudius

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Kyle Russell]

[-- Attachment #1: Type: text/plain, Size: 4413 bytes --]

Thanks, Claudius.  I really appreciate your responses.  I'm not trying to
be pedantic.  Since I don't have your test setup, I was just trying to make
sure I understood the context of the problem as I figure out how to deal
with issues this is causing in our setup.

I was also hoping one of the recipe maintainers of either systemd or
rng-tools would comment on systemd-udev-settle.

I'll take a look at the caam module to see if I can understand how it works.

On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote:

> On 2022-02-02 17:26, Kyle Russell wrote:
> > Thanks, Claudius.
> >
> > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de
> > <mailto:ch@denx.de>> 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.
>
> Yes, however it is a timing issue. The module was loaded properly at
> bootup, however at the time rngd was started the module was not loaded
> yet and thus the service fails to start. If it would be delayed until
> the module is loaded everything would be fine.
>
> It does not happen if the module is compiled into the kernel or if a
> initramfs is used which loads the module (I think). I our case it
> happend with the caam module as an external module loaded on boot from
> the real root file system.
>
> >     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.
>
> This patch just adds a missing entry into the service file. If you have
> solved the described issue in some way and can revert this patch and
> remove the `Wants=systemd-udev-settle.service` then you can also remove
> the `After=systemd-udev-settle.service` at the same time and at that
> point you can just remove both of those entries directly in the patch
> that solved the timing issue.
>
> I agree that `systemd-udev-settle.service` should probably not be used
> anymore, however that file already used it in a non-functional way and
> all this patch did was make it fulfill its intended function.
>
> In retrospect I probably should have tried to find a way to remove the
> usage of `systemd-udev-settle.service` completely, when I looked into
> the issue, however all this patch in essence does is revive dead code,
> which was already in place.
>
> Also I think at that time I couldn't find a more precise instrument in
> systemds massive toolbox to delay the start of rngd and services that
> should be started in succession until the just the hardware random
> generator device is ready and `After=systemd-udev-settle.service` was
> already there. I guess some `ExecStartPre=` script which delays the
> start until the conditions are met could be implemented, but that seems
> a bit hackish.
>
> regards,
> Claudius
>

[-- Attachment #2: Type: text/html, Size: 5393 bytes --]

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Drew Moseley]

[-- Attachment #1: Type: text/plain, Size: 5376 bytes --]

On 2/3/22 9:12 AM, Kyle Russell wrote:

> Thanks, Claudius.  I really appreciate your responses.  I'm not trying 
> to be pedantic.  Since I don't have your test setup, I was just trying 
> to make sure I understood the context of the problem as I figure out 
> how to deal with issues this is causing in our setup.
>
> I was also hoping one of the recipe maintainers of either systemd or 
> rng-tools would comment on systemd-udev-settle.
>
> I'll take a look at the caam module to see if I can understand how it 
> works.
>
> On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote:
>
>     On 2022-02-02 17:26, Kyle Russell wrote:
>     > Thanks, Claudius.
>     >
>     > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de
>     > <mailto:ch@denx.de>> 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.
>
>     Yes, however it is a timing issue. The module was loaded properly at
>     bootup, however at the time rngd was started the module was not
>     loaded
>     yet and thus the service fails to start. If it would be delayed until
>     the module is loaded everything would be fine.
>
>     It does not happen if the module is compiled into the kernel or if a
>     initramfs is used which loads the module (I think). I our case it
>     happend with the caam module as an external module loaded on boot
>     from
>     the real root file system.
>
>     >     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.
>
>     This patch just adds a missing entry into the service file. If you
>     have
>     solved the described issue in some way and can revert this patch and
>     remove the `Wants=systemd-udev-settle.service` then you can also
>     remove
>     the `After=systemd-udev-settle.service` at the same time and at that
>     point you can just remove both of those entries directly in the patch
>     that solved the timing issue.
>
>     I agree that `systemd-udev-settle.service` should probably not be
>     used
>     anymore, however that file already used it in a non-functional way
>     and
>     all this patch did was make it fulfill its intended function.
>
>     In retrospect I probably should have tried to find a way to remove
>     the
>     usage of `systemd-udev-settle.service` completely, when I looked into
>     the issue, however all this patch in essence does is revive dead
>     code,
>     which was already in place.
>
>     Also I think at that time I couldn't find a more precise
>     instrument in
>     systemds massive toolbox to delay the start of rngd and services that
>     should be started in succession until the just the hardware random
>     generator device is ready and `After=systemd-udev-settle.service` was
>     already there. I guess some `ExecStartPre=` script which delays the
>     start until the conditions are met could be implemented, but that
>     seems
>     a bit hackish.
>
>     regards,
>     Claudius
>

We are getting report from our users that adding this "Wants" causes 
extremely slow boots on systems where it did not happen before this 
change. Has anyone looked further into this and whether this change is 
truly necessary?

We have it reverted locally to work around the specific issue but I 
wonder if there is a deeper issue here.

Drew

-- 
mailto:drew@moseleynet.net

[-- Attachment #2: Type: text/html, Size: 7937 bytes --]

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Khem Raj]

On 7/21/22 11:17 AM, Drew Moseley wrote:
> On 2/3/22 9:12 AM, Kyle Russell wrote:
> 
>> Thanks, Claudius.  I really appreciate your responses.  I'm not trying 
>> to be pedantic.  Since I don't have your test setup, I was just trying 
>> to make sure I understood the context of the problem as I figure out 
>> how to deal with issues this is causing in our setup.
>>
>> I was also hoping one of the recipe maintainers of either systemd or 
>> rng-tools would comment on systemd-udev-settle.
>>
>> I'll take a look at the caam module to see if I can understand how it 
>> works.
>>
>> On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote:
>>
>>     On 2022-02-02 17:26, Kyle Russell wrote:
>>     > Thanks, Claudius.
>>     >
>>     > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de
>>     > <mailto:ch@denx.de>> 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.
>>
>>     Yes, however it is a timing issue. The module was loaded properly at
>>     bootup, however at the time rngd was started the module was not
>>     loaded
>>     yet and thus the service fails to start. If it would be delayed until
>>     the module is loaded everything would be fine.
>>
>>     It does not happen if the module is compiled into the kernel or if a
>>     initramfs is used which loads the module (I think). I our case it
>>     happend with the caam module as an external module loaded on boot
>>     from
>>     the real root file system.
>>
>>     >     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.
>>
>>     This patch just adds a missing entry into the service file. If you
>>     have
>>     solved the described issue in some way and can revert this patch and
>>     remove the `Wants=systemd-udev-settle.service` then you can also
>>     remove
>>     the `After=systemd-udev-settle.service` at the same time and at that
>>     point you can just remove both of those entries directly in the patch
>>     that solved the timing issue.
>>
>>     I agree that `systemd-udev-settle.service` should probably not be
>>     used
>>     anymore, however that file already used it in a non-functional way
>>     and
>>     all this patch did was make it fulfill its intended function.
>>
>>     In retrospect I probably should have tried to find a way to remove
>>     the
>>     usage of `systemd-udev-settle.service` completely, when I looked into
>>     the issue, however all this patch in essence does is revive dead
>>     code,
>>     which was already in place.
>>
>>     Also I think at that time I couldn't find a more precise
>>     instrument in
>>     systemds massive toolbox to delay the start of rngd and services that
>>     should be started in succession until the just the hardware random
>>     generator device is ready and `After=systemd-udev-settle.service` was
>>     already there. I guess some `ExecStartPre=` script which delays the
>>     start until the conditions are met could be implemented, but that
>>     seems
>>     a bit hackish.
>>
>>     regards,
>>     Claudius
>>
> 
> We are getting report from our users that adding this "Wants" causes 
> extremely slow boots on systems where it did not happen before this 
> change. Has anyone looked further into this and whether this change is 
> truly necessary?
> 
> We have it reverted locally to work around the specific issue but I 
> wonder if there is a deeper issue here.

It seems the issue was that module load was racing with rngd in that 
case perhaps adding After=systemd-modules-load.service
might have been another choice to solve it. Using 
systemd-udev-settle.service is a bit heavy handed as it will wait for 
full h/w discovery which could vary from system to system.

> 
> Drew
> 
> -- 
> mailto:drew@moseleynet.net
> 
> 
> 
> 
> 

Re: [PATCH] rng-tools: add systemd-udev-settle wants to service

[Drew Moseley]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

So should I submit a patch with that change? I don't know how to reproduce the original issue so I won't have any way to prove if this is a viable fix.

Drew

[-- Attachment #2: Type: text/html, Size: 169 bytes --]

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Khem Raj]

On Fri, Jul 22, 2022 at 4:42 PM Drew Moseley <drew.moseley@gmail.com> wrote:
>
> So should I submit a patch with that change? I don't know how to reproduce the original issue so I won't have any way to prove if this is a viable fix.
>

Does this fix the problem you see ? if it does then perhaps Claudius
can help trying it for the original issue and help validate further.

> Drew
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#168425): https://lists.openembedded.org/g/openembedded-core/message/168425
> Mute This Topic: https://lists.openembedded.org/mt/85671578/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service

[Claudius Heine]

Hi Khem,

On 2022-07-21 17:29, Khem Raj wrote:
> 
> 
> On 7/21/22 11:17 AM, Drew Moseley wrote:
>> On 2/3/22 9:12 AM, Kyle Russell wrote:
>>
>>> Thanks, Claudius.  I really appreciate your responses.  I'm not 
>>> trying to be pedantic.  Since I don't have your test setup, I was 
>>> just trying to make sure I understood the context of the problem as I 
>>> figure out how to deal with issues this is causing in our setup.
>>>
>>> I was also hoping one of the recipe maintainers of either systemd or 
>>> rng-tools would comment on systemd-udev-settle.
>>>
>>> I'll take a look at the caam module to see if I can understand how it 
>>> works.
>>>
>>> On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote:
>>>
>>>     On 2022-02-02 17:26, Kyle Russell wrote:
>>>     > Thanks, Claudius.
>>>     >
>>>     > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de
>>>     > <mailto:ch@denx.de>> 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.
>>>
>>>     Yes, however it is a timing issue. The module was loaded properly at
>>>     bootup, however at the time rngd was started the module was not
>>>     loaded
>>>     yet and thus the service fails to start. If it would be delayed 
>>> until
>>>     the module is loaded everything would be fine.
>>>
>>>     It does not happen if the module is compiled into the kernel or if a
>>>     initramfs is used which loads the module (I think). I our case it
>>>     happend with the caam module as an external module loaded on boot
>>>     from
>>>     the real root file system.
>>>
>>>     >     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.
>>>
>>>     This patch just adds a missing entry into the service file. If you
>>>     have
>>>     solved the described issue in some way and can revert this patch and
>>>     remove the `Wants=systemd-udev-settle.service` then you can also
>>>     remove
>>>     the `After=systemd-udev-settle.service` at the same time and at that
>>>     point you can just remove both of those entries directly in the 
>>> patch
>>>     that solved the timing issue.
>>>
>>>     I agree that `systemd-udev-settle.service` should probably not be
>>>     used
>>>     anymore, however that file already used it in a non-functional way
>>>     and
>>>     all this patch did was make it fulfill its intended function.
>>>
>>>     In retrospect I probably should have tried to find a way to remove
>>>     the
>>>     usage of `systemd-udev-settle.service` completely, when I looked 
>>> into
>>>     the issue, however all this patch in essence does is revive dead
>>>     code,
>>>     which was already in place.
>>>
>>>     Also I think at that time I couldn't find a more precise
>>>     instrument in
>>>     systemds massive toolbox to delay the start of rngd and services 
>>> that
>>>     should be started in succession until the just the hardware random
>>>     generator device is ready and `After=systemd-udev-settle.service` 
>>> was
>>>     already there. I guess some `ExecStartPre=` script which delays the
>>>     start until the conditions are met could be implemented, but that
>>>     seems
>>>     a bit hackish.
>>>
>>>     regards,
>>>     Claudius
>>>
>>
>> We are getting report from our users that adding this "Wants" causes 
>> extremely slow boots on systems where it did not happen before this 
>> change. Has anyone looked further into this and whether this change is 
>> truly necessary?
>>
>> We have it reverted locally to work around the specific issue but I 
>> wonder if there is a deeper issue here.
> 
> It seems the issue was that module load was racing with rngd in that 
> case perhaps adding After=systemd-modules-load.service
> might have been another choice to solve it. Using 
> systemd-udev-settle.service is a bit heavy handed as it will wait for 
> full h/w discovery which could vary from system to system.

Maybe systemd-modules-load.service could be enough in many cases, 
however it has to be made sure that the device node /dev/hwrng is 
created before the service is started. Just making sure that the modules 
are loaded might not be enough...

As I described the best, albeit a bit hackish solutions, would be a 
`ExecStartPre` script that delays the service until the system is ready 
for rngd.

It is a bit difficult for me to test this now, since I no longer have 
access to exactly that hardware, but I will try to review all patches 
and comment on it if I find any potential issues.

regards,
Claudius

[OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle"

[drew.moseley]

From: Drew Moseley <drew@moseleynet.net>

The systemd-udev-settle service is listed as obsolete and does in
some cases result in a significant boot time.  Replace that with
"after systemd-modules-load" to allow the random source hardware
to be loaded in the proper sequence.

Before this change:

   Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 2min 17.262s
   multi-user.target reached after 2min 8.153s in userspace

After this change:

   Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
   multi-user.target reached after 9.522s in userspace

Signed-off-by: Drew Moseley <drew@moseleynet.net>
---
 meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service
index 568686e80e..e818cfcf78 100644
--- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
+++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
@@ -3,7 +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
+After=systemd-modules-load.service
 Conflicts=shutdown.target
 
 [Service]
-- 
2.37.1

Re: [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle"

[Drew Moseley]

On 7/26/22 9:17 AM, drew.moseley@gmail.com wrote:

> From: Drew Moseley <drew@moseleynet.net>
>
> The systemd-udev-settle service is listed as obsolete and does in
> some cases result in a significant boot time.  Replace that with
> "after systemd-modules-load" to allow the random source hardware
> to be loaded in the proper sequence.
>
> Before this change:
>
>     Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 2min 17.262s
>     multi-user.target reached after 2min 8.153s in userspace
>
> After this change:
>
>     Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
>     multi-user.target reached after 9.522s in userspace
>
> Signed-off-by: Drew Moseley <drew@moseleynet.net>
> ---
>   meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> index 568686e80e..e818cfcf78 100644
> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> @@ -3,7 +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
> +After=systemd-modules-load.service
>   Conflicts=shutdown.target
>   
>   [Service]


Hi Khem, Claudius,

Any thoughts on this change? Obviously I cannot verify if the original 
hardware combination issue is resolved and unfortunately it sounds like 
you cannot either but I'm using this successfully to work around the 
delayed boots I was seeing here.

Drew

-- 
mailto:drew@moseleynet.net

Re: [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle"

[Claudius Heine]

Hi Drew,

On 2022-08-01 20:44, Drew Moseley wrote:
> On 7/26/22 9:17 AM, drew.moseley@gmail.com wrote:
> 
>> From: Drew Moseley <drew@moseleynet.net>
>>
>> The systemd-udev-settle service is listed as obsolete and does in
>> some cases result in a significant boot time.  Replace that with
>> "after systemd-modules-load" to allow the random source hardware
>> to be loaded in the proper sequence.
>>
>> Before this change:
>>
>>     Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 
>> 2min 17.262s
>>     multi-user.target reached after 2min 8.153s in userspace
>>
>> After this change:
>>
>>     Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
>>     multi-user.target reached after 9.522s in userspace
>>
>> Signed-off-by: Drew Moseley <drew@moseleynet.net>
>> ---
>>   meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service 
>> b/meta/recipes-support/rng-tools/rng-tools/rngd.service
>> index 568686e80e..e818cfcf78 100644
>> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
>> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
>> @@ -3,7 +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
>> +After=systemd-modules-load.service
>>   Conflicts=shutdown.target
>>   [Service]
> 
> 
> Hi Khem, Claudius,
> 
> Any thoughts on this change? Obviously I cannot verify if the original 
> hardware combination issue is resolved and unfortunately it sounds like 
> you cannot either but I'm using this successfully to work around the 
> delayed boots I was seeing here.

Well as I said, `systemd-modules-load.service` just waits until all 
statically configured modules are loaded, however not until the 
`/dev/hwrng` device node is available. `systemd-udev-settle.service` 
waits until all udev rules are applied, and that means it includes 
loading of all dynamically loaded modules as well as executing code that 
creates symlinks, etc.

Instead of waiting for modules to be loaded, that might be unrelated or 
waiting for all (mostly unrelated) udev rules to be settled, I think 
waiting directly for the `/dev/hwrng` device node might be more explicit 
and specific.

regards,
Claudius

Re: [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle"

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

On Tue, Aug 2, 2022 at 8:24 AM Claudius Heine <ch@denx.de> wrote:

> Hi Drew,
>
> On 2022-08-01 20:44, Drew Moseley wrote:
> > On 7/26/22 9:17 AM, drew.moseley@gmail.com wrote:
> >
> >> From: Drew Moseley <drew@moseleynet.net>
> >>
> >> The systemd-udev-settle service is listed as obsolete and does in
> >> some cases result in a significant boot time.  Replace that with
> >> "after systemd-modules-load" to allow the random source hardware
> >> to be loaded in the proper sequence.
> >>
> >> Before this change:
> >>
> >>     Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) =
> >> 2min 17.262s
> >>     multi-user.target reached after 2min 8.153s in userspace
> >>
> >> After this change:
> >>
> >>     Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
> >>     multi-user.target reached after 9.522s in userspace
> >>
> >> Signed-off-by: Drew Moseley <drew@moseleynet.net>
> >> ---
> >>   meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> >> b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> >> index 568686e80e..e818cfcf78 100644
> >> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> >> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> >> @@ -3,7 +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
> >> +After=systemd-modules-load.service
> >>   Conflicts=shutdown.target
> >>   [Service]
> >
> >
> > Hi Khem, Claudius,
> >
> > Any thoughts on this change? Obviously I cannot verify if the original
> > hardware combination issue is resolved and unfortunately it sounds like
> > you cannot either but I'm using this successfully to work around the
> > delayed boots I was seeing here.
>
> Well as I said, `systemd-modules-load.service` just waits until all
> statically configured modules are loaded, however not until the
> `/dev/hwrng` device node is available. `systemd-udev-settle.service`
> waits until all udev rules are applied, and that means it includes
> loading of all dynamically loaded modules as well as executing code that
> creates symlinks, etc.
>
> Instead of waiting for modules to be loaded, that might be unrelated or
> waiting for all (mostly unrelated) udev rules to be settled, I think
> waiting directly for the `/dev/hwrng` device node might be more explicit
> and specific.
>

Yeah something more surgical and pointed

Requires=dev-hwrng.device
After=dev-hwrng.device


Might be worth trying



> regards,
> Claudius
>

[-- Attachment #2: Type: text/html, Size: 6465 bytes --]

[OE-core][PATCH v2] rng-tools: Replace obsolete "wants systemd-udev-settle"

[drew.moseley]

From: Drew Moseley <drew@moseleynet.net>

The systemd-udev-settle service is listed as obsolete and does in
some cases result in a significant boot time.  Replace that with a
specific wait for the random source hardware device to be loaded.

Before this change:

   Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 2min 17.262s
   multi-user.target reached after 2min 8.153s in userspace

After this change:

   Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
   multi-user.target reached after 9.522s in userspace

Signed-off-by: Drew Moseley <drew@moseleynet.net>
---
 meta/recipes-support/rng-tools/rng-tools/rngd.service | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service
index 568686e80e..0f50890dcb 100644
--- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
+++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
@@ -3,7 +3,8 @@ Description=Hardware RNG Entropy Gatherer Daemon
 DefaultDependencies=no
 After=systemd-udev-settle.service
 Before=sysinit.target shutdown.target
-Wants=systemd-udev-settle.service
+Requires=dev-hwrng.device
+After=dev-hwrng.device
 Conflicts=shutdown.target
 
 [Service]
-- 
2.37.1

Re: [OE-core][PATCH v2] rng-tools: Replace obsolete "wants systemd-udev-settle"

[Dragos-Marian Panait]

It seems that this change introduced a boot delay for qemux86-64 + 
systemd build.

Steps:

git clone git://git.yoctoproject.org/poky
. poky/oe-init-build-env

add to conf/local.conf:

DISTRO_FEATURES:remove = " sysvinit"
DISTRO_FEATURES:append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = ""

bitbake core-image-full-cmdline

Cause of boot delay:
[ TIME ] Timed out waiting for device /dev/hwrng.
[DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon.

Regards,
Dragos

On 04.08.2022 18:09, Drew Moseley wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> From: Drew Moseley <drew@moseleynet.net>
>
> The systemd-udev-settle service is listed as obsolete and does in
> some cases result in a significant boot time.  Replace that with a
> specific wait for the random source hardware device to be loaded.
>
> Before this change:
>
>     Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 2min 17.262s
>     multi-user.target reached after 2min 8.153s in userspace
>
> After this change:
>
>     Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
>     multi-user.target reached after 9.522s in userspace
>
> Signed-off-by: Drew Moseley <drew@moseleynet.net>
> ---
>   meta/recipes-support/rng-tools/rng-tools/rngd.service | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> index 568686e80e..0f50890dcb 100644
> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> @@ -3,7 +3,8 @@ Description=Hardware RNG Entropy Gatherer Daemon
>   DefaultDependencies=no
>   After=systemd-udev-settle.service
>   Before=sysinit.target shutdown.target
> -Wants=systemd-udev-settle.service
> +Requires=dev-hwrng.device
> +After=dev-hwrng.device
>   Conflicts=shutdown.target
>
>   [Service]
> --
> 2.37.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#168859): https://lists.openembedded.org/g/openembedded-core/message/168859
> Mute This Topic: https://lists.openembedded.org/mt/92815243/6328324
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [dragos.panait@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core][PATCH v2] rng-tools: Replace obsolete "wants systemd-udev-settle"

[Drew Moseley]

Well dang. Any other suggestions on how to resolve the original issue 
without breaking others things?


Drew

On 8/12/22 8:59 AM, Dragos-Marian Panait wrote:
> It seems that this change introduced a boot delay for qemux86-64 + 
> systemd build.
>
> Steps:
>
> git clone git://git.yoctoproject.org/poky
> . poky/oe-init-build-env
>
> add to conf/local.conf:
>
> DISTRO_FEATURES:remove = " sysvinit"
> DISTRO_FEATURES:append = " systemd"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = ""
>
> bitbake core-image-full-cmdline
>
> Cause of boot delay:
> [ TIME ] Timed out waiting for device /dev/hwrng.
> [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon.
>
> Regards,
> Dragos
>
> On 04.08.2022 18:09, Drew Moseley wrote:
>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>
>> From: Drew Moseley <drew@moseleynet.net>
>>
>> The systemd-udev-settle service is listed as obsolete and does in
>> some cases result in a significant boot time.  Replace that with a
>> specific wait for the random source hardware device to be loaded.
>>
>> Before this change:
>>
>>     Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 
>> 2min 17.262s
>>     multi-user.target reached after 2min 8.153s in userspace
>>
>> After this change:
>>
>>     Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
>>     multi-user.target reached after 9.522s in userspace
>>
>> Signed-off-by: Drew Moseley <drew@moseleynet.net>
>> ---
>>   meta/recipes-support/rng-tools/rng-tools/rngd.service | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service 
>> b/meta/recipes-support/rng-tools/rng-tools/rngd.service
>> index 568686e80e..0f50890dcb 100644
>> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
>> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
>> @@ -3,7 +3,8 @@ Description=Hardware RNG Entropy Gatherer Daemon
>>   DefaultDependencies=no
>>   After=systemd-udev-settle.service
>>   Before=sysinit.target shutdown.target
>> -Wants=systemd-udev-settle.service
>> +Requires=dev-hwrng.device
>> +After=dev-hwrng.device
>>   Conflicts=shutdown.target
>>
>>   [Service]
>> -- 
>> 2.37.1
>>
>>
>> 
>>
-- 
mailto:drew@moseleynet.net

[OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[drew.moseley]

From: Drew Moseley <drew@moseleynet.net>

The previous change to remove the dependency on systemd-udev-settle
caused boot delays at least on qemu. It seems that change required
a hwrng device but that's not necessarily available on all platforms.

This changes the "Requires" to a "WantedBy" as modeled after the
version of this file on Ubuntu 20.04.

Signed-off-by: Drew Moseley <drew@moseleynet.net>
---
 meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
index 0f50890dcb..b013d95932 100644
--- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
+++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
@@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
 DefaultDependencies=no
 After=systemd-udev-settle.service
 Before=sysinit.target shutdown.target
-Requires=dev-hwrng.device
-After=dev-hwrng.device
 Conflicts=shutdown.target
 
 [Service]
@@ -32,3 +30,4 @@ SystemCallFilter=@system-service
 
 [Install]
 WantedBy=sysinit.target
+WantedBy=dev-hwrng.device
-- 
2.37.2

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Drew Moseley]

Hi Khem,

It looks like you recently removed both the dependency on hwrng and 
systemd-udev-settle.  Do you think this change will be useful?

Claudius, any thoughts here?


Drew



On 8/15/22 2:25 PM, drew.moseley@gmail.com wrote:
> From: Drew Moseley <drew@moseleynet.net>
>
> The previous change to remove the dependency on systemd-udev-settle
> caused boot delays at least on qemu. It seems that change required
> a hwrng device but that's not necessarily available on all platforms.
>
> This changes the "Requires" to a "WantedBy" as modeled after the
> version of this file on Ubuntu 20.04.
>
> Signed-off-by: Drew Moseley <drew@moseleynet.net>
> ---
>   meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> index 0f50890dcb..b013d95932 100644
> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
>   DefaultDependencies=no
>   After=systemd-udev-settle.service
>   Before=sysinit.target shutdown.target
> -Requires=dev-hwrng.device
> -After=dev-hwrng.device
>   Conflicts=shutdown.target
>   
>   [Service]
> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
>   
>   [Install]
>   WantedBy=sysinit.target
> +WantedBy=dev-hwrng.device

-- 
mailto:drew@moseleynet.net

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Khem Raj]

On Mon, Aug 15, 2022 at 11:30 AM Drew Moseley <drew.moseley@gmail.com> wrote:
>
> Hi Khem,
>
> It looks like you recently removed both the dependency on hwrng and
> systemd-udev-settle.  Do you think this change will be useful?

Depending on udev-settle certainly seems an overkill so that should go.
the change you have made will now ensure that this service starts when
dev-hwrng device is created
but loses the order of starting the service. So it may still race with
device creation.

>
> Claudius, any thoughts here?
>
>
> Drew
>
>
>
> On 8/15/22 2:25 PM, drew.moseley@gmail.com wrote:
> > From: Drew Moseley <drew@moseleynet.net>
> >
> > The previous change to remove the dependency on systemd-udev-settle
> > caused boot delays at least on qemu. It seems that change required
> > a hwrng device but that's not necessarily available on all platforms.
> >
> > This changes the "Requires" to a "WantedBy" as modeled after the
> > version of this file on Ubuntu 20.04.
> >
> > Signed-off-by: Drew Moseley <drew@moseleynet.net>
> > ---
> >   meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
> >   1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > index 0f50890dcb..b013d95932 100644
> > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
> >   DefaultDependencies=no
> >   After=systemd-udev-settle.service
> >   Before=sysinit.target shutdown.target
> > -Requires=dev-hwrng.device
> > -After=dev-hwrng.device
> >   Conflicts=shutdown.target
> >
> >   [Service]
> > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
> >
> >   [Install]
> >   WantedBy=sysinit.target
> > +WantedBy=dev-hwrng.device
>
> --
> mailto:drew@moseleynet.net
>

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Alexander Kanavin]

I am definitely seeing a serious regression where qemu images get
stuck for 4 minutes on boot waiting for /dev/hwrng, so if this is
fixing the issue, I'd appreciate getting it in!

Alex

On Mon, 15 Aug 2022 at 20:48, Khem Raj <raj.khem@gmail.com> wrote:
>
> On Mon, Aug 15, 2022 at 11:30 AM Drew Moseley <drew.moseley@gmail.com> wrote:
> >
> > Hi Khem,
> >
> > It looks like you recently removed both the dependency on hwrng and
> > systemd-udev-settle.  Do you think this change will be useful?
>
> Depending on udev-settle certainly seems an overkill so that should go.
> the change you have made will now ensure that this service starts when
> dev-hwrng device is created
> but loses the order of starting the service. So it may still race with
> device creation.
>
> >
> > Claudius, any thoughts here?
> >
> >
> > Drew
> >
> >
> >
> > On 8/15/22 2:25 PM, drew.moseley@gmail.com wrote:
> > > From: Drew Moseley <drew@moseleynet.net>
> > >
> > > The previous change to remove the dependency on systemd-udev-settle
> > > caused boot delays at least on qemu. It seems that change required
> > > a hwrng device but that's not necessarily available on all platforms.
> > >
> > > This changes the "Requires" to a "WantedBy" as modeled after the
> > > version of this file on Ubuntu 20.04.
> > >
> > > Signed-off-by: Drew Moseley <drew@moseleynet.net>
> > > ---
> > >   meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
> > >   1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > > index 0f50890dcb..b013d95932 100644
> > > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
> > >   DefaultDependencies=no
> > >   After=systemd-udev-settle.service
> > >   Before=sysinit.target shutdown.target
> > > -Requires=dev-hwrng.device
> > > -After=dev-hwrng.device
> > >   Conflicts=shutdown.target
> > >
> > >   [Service]
> > > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
> > >
> > >   [Install]
> > >   WantedBy=sysinit.target
> > > +WantedBy=dev-hwrng.device
> >
> > --
> > mailto:drew@moseleynet.net
> >
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#169360): https://lists.openembedded.org/g/openembedded-core/message/169360
> Mute This Topic: https://lists.openembedded.org/mt/93042904/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Claudius Heine]

Hi Dew.

On 2022-08-15 20:25, drew.moseley@gmail.com wrote:
> From: Drew Moseley <drew@moseleynet.net>
> 
> The previous change to remove the dependency on systemd-udev-settle
> caused boot delays at least on qemu. It seems that change required
> a hwrng device but that's not necessarily available on all platforms.
> 
> This changes the "Requires" to a "WantedBy" as modeled after the
> version of this file on Ubuntu 20.04.
> 
> Signed-off-by: Drew Moseley <drew@moseleynet.net>
> ---
>   meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> index 0f50890dcb..b013d95932 100644
> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
>   DefaultDependencies=no
>   After=systemd-udev-settle.service
>   Before=sysinit.target shutdown.target
> -Requires=dev-hwrng.device
> -After=dev-hwrng.device
>   Conflicts=shutdown.target
>   
>   [Service]
> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
>   
>   [Install]
>   WantedBy=sysinit.target
> +WantedBy=dev-hwrng.device

This looses the order. Have you tried just replacing `Requires` with 
`Wants`. So something like this:


```

Before=sysinit.target shutdown.target
Wants=dev-hwrng.device
After=dev-hwrng.device
Conflicts=shutdown.target

```

If that still would cause the long waiting time on qemu?

I haven't investigated the qemu issue, but maybe qemu just doesn't 
provide a hardware random source? If it doesn't provide a hardware 
random source, then installing rng-tools on there might also not make sense.

Alternatively maybe just adding a start timeout might solve it?

regards,
Claudius

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Dragos-Marian Panait]

[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]

Hi Claudius,

On 19.08.2022 12:36, Claudius Heine wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> Hi Dew.
>
> On 2022-08-15 20:25, drew.moseley@gmail.com wrote:
>> From: Drew Moseley <drew@moseleynet.net>
>>
>> The previous change to remove the dependency on systemd-udev-settle
>> caused boot delays at least on qemu. It seems that change required
>> a hwrng device but that's not necessarily available on all platforms.
>>
>> This changes the "Requires" to a "WantedBy" as modeled after the
>> version of this file on Ubuntu 20.04.
>>
>> Signed-off-by: Drew Moseley <drew@moseleynet.net>
>> ---
>>   meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git 
>> a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service 
>> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>> index 0f50890dcb..b013d95932 100644
>> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
>>   DefaultDependencies=no
>>   After=systemd-udev-settle.service
>>   Before=sysinit.target shutdown.target
>> -Requires=dev-hwrng.device
>> -After=dev-hwrng.device
>>   Conflicts=shutdown.target
>>
>>   [Service]
>> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
>>
>>   [Install]
>>   WantedBy=sysinit.target
>> +WantedBy=dev-hwrng.device
>
> This looses the order. Have you tried just replacing `Requires` with
> `Wants`. So something like this:
>
>
> ```
>
> Before=sysinit.target shutdown.target
> Wants=dev-hwrng.device
> After=dev-hwrng.device
> Conflicts=shutdown.target
>
> ```
>
> If that still would cause the long waiting time on qemu?
>
> I haven't investigated the qemu issue, but maybe qemu just doesn't
> provide a hardware random source? If it doesn't provide a hardware
> random source, then installing rng-tools on there might also not make 
> sense.
> Alternatively maybe just adding a start timeout might solve it?
> regards,
> Claudius


I've tested the patch on a NUC7, results are the same as with qemu:
- increased boot time
- timeout for rng-tools.service
[ TIME ] Timed out waiting for device /dev/hwrng.
[DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon.

Regards,
Dragos

[-- Attachment #2: Type: text/html, Size: 4281 bytes --]

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Drew Moseley]

[-- Attachment #1: Type: text/plain, Size: 3047 bytes --]


On 8/19/22 8:50 AM, Dragos-Marian Panait wrote:
>
> Hi Claudius,
>
> On 19.08.2022 12:36, Claudius Heine wrote:
>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>
>> Hi Dew.
>>
>> On 2022-08-15 20:25, drew.moseley@gmail.com wrote:
>>> From: Drew Moseley <drew@moseleynet.net>
>>>
>>> The previous change to remove the dependency on systemd-udev-settle
>>> caused boot delays at least on qemu. It seems that change required
>>> a hwrng device but that's not necessarily available on all platforms.
>>>
>>> This changes the "Requires" to a "WantedBy" as modeled after the
>>> version of this file on Ubuntu 20.04.
>>>
>>> Signed-off-by: Drew Moseley <drew@moseleynet.net>
>>> ---
>>>   meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git 
>>> a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service 
>>> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>> index 0f50890dcb..b013d95932 100644
>>> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
>>>   DefaultDependencies=no
>>>   After=systemd-udev-settle.service
>>>   Before=sysinit.target shutdown.target
>>> -Requires=dev-hwrng.device
>>> -After=dev-hwrng.device
>>>   Conflicts=shutdown.target
>>>
>>>   [Service]
>>> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
>>>
>>>   [Install]
>>>   WantedBy=sysinit.target
>>> +WantedBy=dev-hwrng.device
>>
>> This looses the order. Have you tried just replacing `Requires` with
>> `Wants`. So something like this:
>>
>>
>> ```
>>
>> Before=sysinit.target shutdown.target
>> Wants=dev-hwrng.device
>> After=dev-hwrng.device
>> Conflicts=shutdown.target
>>
>> ```
>>
>> If that still would cause the long waiting time on qemu?
>>
>> I haven't investigated the qemu issue, but maybe qemu just doesn't
>> provide a hardware random source? If it doesn't provide a hardware
>> random source, then installing rng-tools on there might also not make 
>> sense.
>> Alternatively maybe just adding a start timeout might solve it?
>> regards,
>> Claudius
>
>
> I've tested the patch on a NUC7, results are the same as with qemu:
> - increased boot time
> - timeout for rng-tools.service
> [ TIME ] Timed out waiting for device /dev/hwrng.
> [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon.
>
> Regards,
> Dragos
>

Interesting. I guess this patch should definitely be ignored and the 
patch from Khem that removes both the dev-hwrng and systemd-udev-settle 
depencies is the right approach. That means that the original problem 
that adding systemd-udev-settle was meant to solve, is no longer solved 
but it seems that the proposed solutions here have adverse effects 
elsewhere.

Simply removing the systemd-udev-settle dependency fixes the issue that 
my customer has that caused me to start investigating here.

Drew

-- 
mailto:drew@moseleynet.net

[-- Attachment #2: Type: text/html, Size: 5248 bytes --]

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Dragos-Marian Panait]

[-- Attachment #1: Type: text/plain, Size: 4918 bytes --]


On 19.08.2022 17:34, Drew Moseley wrote:
>
> **[Please note: This e-mail is from an EXTERNAL e-mail address]
>
>
> On 8/19/22 8:50 AM, Dragos-Marian Panait wrote:
>>
>> Hi Claudius,
>>
>> On 19.08.2022 12:36, Claudius Heine wrote:
>>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>>
>>> Hi Dew.
>>>
>>> On 2022-08-15 20:25, drew.moseley@gmail.com wrote:
>>>> From: Drew Moseley <drew@moseleynet.net>
>>>>
>>>> The previous change to remove the dependency on systemd-udev-settle
>>>> caused boot delays at least on qemu. It seems that change required
>>>> a hwrng device but that's not necessarily available on all platforms.
>>>>
>>>> This changes the "Requires" to a "WantedBy" as modeled after the
>>>> version of this file on Ubuntu 20.04.
>>>>
>>>> Signed-off-by: Drew Moseley <drew@moseleynet.net>
>>>> ---
>>>> meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
>>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git 
>>>> a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service 
>>>> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>>> index 0f50890dcb..b013d95932 100644
>>>> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>>> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>>> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
>>>>   DefaultDependencies=no
>>>>   After=systemd-udev-settle.service
>>>>   Before=sysinit.target 
>>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> 
>>>> shutdown.target 
>>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> 
>>>>
>>>> -Requires=dev-hwrng.device
>>>> -After=dev-hwrng.device
>>>>   Conflicts=shutdown.target 
>>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> 
>>>>
>>>>
>>>>   [Service]
>>>> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
>>>>
>>>>   [Install]
>>>>   WantedBy=sysinit.target 
>>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> 
>>>>
>>>> +WantedBy=dev-hwrng.device
>>>
>>> This looses the order. Have you tried just replacing `Requires` with
>>> `Wants`. So something like this:
>>>
>>>
>>> ```
>>>
>>> Before=sysinit.target 
>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> 
>>> shutdown.target 
>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> 
>>>
>>> Wants=dev-hwrng.device
>>> After=dev-hwrng.device
>>> Conflicts=shutdown.target 
>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> 
>>>
>>>
>>> ```
>>>
>>> If that still would cause the long waiting time on qemu?
>>>
>>> I haven't investigated the qemu issue, but maybe qemu just doesn't
>>> provide a hardware random source? If it doesn't provide a hardware
>>> random source, then installing rng-tools on there might also not 
>>> make sense.
>>> Alternatively maybe just adding a start timeout might solve it?
>>> regards,
>>> Claudius
>>
>>
>> I've tested the patch on a NUC7, results are the same as with qemu:
>> - increased boot time
>> - timeout for rng-tools.service
>> [ TIME ] Timed out waiting for device /dev/hwrng.
>> [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon.
>>
>> Regards,
>> Dragos
>>
>
> Interesting. I guess this patch should definitely be ignored and the 
> patch from Khem that removes both the dev-hwrng and 
> systemd-udev-settle depencies is the right approach. That means that 
> the original problem that adding systemd-udev-settle was meant to 
> solve, is no longer solved but it seems that the proposed solutions 
> here have adverse effects elsewhere.
>
> Simply removing the systemd-udev-settle dependency fixes the issue 
> that my customer has that caused me to start investigating here.
>
> Drew
>
> -- 
> mailto:drew@moseleynet.net
Sorry for the confusion, I did not test any additional patches/changes 
that have been suggested in this email thread.
My test was performed on current Yocto master sources. No additional 
patches.
I just wanted to inform that the boot delay is also observed on real hw, 
not just qemu.
Again, sorry for the confusion.

Dragos

[-- Attachment #2: Type: text/html, Size: 8410 bytes --]

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Drew Moseley]

[-- Attachment #1: Type: text/plain, Size: 5262 bytes --]


On 8/19/22 11:07 AM, Dragos-Marian Panait wrote:
>
>
> On 19.08.2022 17:34, Drew Moseley wrote:
>>
>> **[Please note: This e-mail is from an EXTERNAL e-mail address]
>>
>>
>> On 8/19/22 8:50 AM, Dragos-Marian Panait wrote:
>>>
>>> Hi Claudius,
>>>
>>> On 19.08.2022 12:36, Claudius Heine wrote:
>>>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>>>
>>>> Hi Dew.
>>>>
>>>> On 2022-08-15 20:25, drew.moseley@gmail.com wrote:
>>>>> From: Drew Moseley <drew@moseleynet.net>
>>>>>
>>>>> The previous change to remove the dependency on systemd-udev-settle
>>>>> caused boot delays at least on qemu. It seems that change required
>>>>> a hwrng device but that's not necessarily available on all platforms.
>>>>>
>>>>> This changes the "Requires" to a "WantedBy" as modeled after the
>>>>> version of this file on Ubuntu 20.04.
>>>>>
>>>>> Signed-off-by: Drew Moseley <drew@moseleynet.net>
>>>>> ---
>>>>> meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
>>>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>>>>
>>>>> diff --git 
>>>>> a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service 
>>>>> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>>>> index 0f50890dcb..b013d95932 100644
>>>>> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>>>> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
>>>>> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
>>>>>   DefaultDependencies=no
>>>>>   After=systemd-udev-settle.service
>>>>>   Before=sysinit.target 
>>>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> 
>>>>> shutdown.target 
>>>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> 
>>>>>
>>>>> -Requires=dev-hwrng.device
>>>>> -After=dev-hwrng.device
>>>>>   Conflicts=shutdown.target 
>>>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> 
>>>>>
>>>>>
>>>>>   [Service]
>>>>> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
>>>>>
>>>>>   [Install]
>>>>>   WantedBy=sysinit.target 
>>>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> 
>>>>>
>>>>> +WantedBy=dev-hwrng.device
>>>>
>>>> This looses the order. Have you tried just replacing `Requires` with
>>>> `Wants`. So something like this:
>>>>
>>>>
>>>> ```
>>>>
>>>> Before=sysinit.target 
>>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> 
>>>> shutdown.target 
>>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> 
>>>>
>>>> Wants=dev-hwrng.device
>>>> After=dev-hwrng.device
>>>> Conflicts=shutdown.target 
>>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> 
>>>>
>>>>
>>>> ```
>>>>
>>>> If that still would cause the long waiting time on qemu?
>>>>
>>>> I haven't investigated the qemu issue, but maybe qemu just doesn't
>>>> provide a hardware random source? If it doesn't provide a hardware
>>>> random source, then installing rng-tools on there might also not 
>>>> make sense.
>>>> Alternatively maybe just adding a start timeout might solve it?
>>>> regards,
>>>> Claudius
>>>
>>>
>>> I've tested the patch on a NUC7, results are the same as with qemu:
>>> - increased boot time
>>> - timeout for rng-tools.service
>>> [ TIME ] Timed out waiting for device /dev/hwrng.
>>> [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon.
>>>
>>> Regards,
>>> Dragos
>>>
>>
>> Interesting. I guess this patch should definitely be ignored and the 
>> patch from Khem that removes both the dev-hwrng and 
>> systemd-udev-settle depencies is the right approach. That means that 
>> the original problem that adding systemd-udev-settle was meant to 
>> solve, is no longer solved but it seems that the proposed solutions 
>> here have adverse effects elsewhere.
>>
>> Simply removing the systemd-udev-settle dependency fixes the issue 
>> that my customer has that caused me to start investigating here.
>>
>> Drew
>>
>> -- 
>> mailto:drew@moseleynet.net
> Sorry for the confusion, I did not test any additional patches/changes 
> that have been suggested in this email thread.
> My test was performed on current Yocto master sources. No additional 
> patches.
> I just wanted to inform that the boot delay is also observed on real 
> hw, not just qemu.
> Again, sorry for the confusion.
>
> Dragos


Sorry for adding to the confusion. My point was intended to be that I am 
fairly certain the recent patch submitted by Khem will resolve the boot 
delay issue you are having as well as the original boot delay caused by 
systemd-udev-settle.

Drew

-- 
mailto:drew@moseleynet.net

[-- Attachment #2: Type: text/html, Size: 9454 bytes --]

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Alexander Kanavin]

So which recent patch? Can you link to it please?

Alex


On Fri, 19 Aug 2022 at 17:13, Drew Moseley <drew.moseley@gmail.com> wrote:
>
>
> On 8/19/22 11:07 AM, Dragos-Marian Panait wrote:
>
>
> On 19.08.2022 17:34, Drew Moseley wrote:
>
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
>
> On 8/19/22 8:50 AM, Dragos-Marian Panait wrote:
>
> Hi Claudius,
>
> On 19.08.2022 12:36, Claudius Heine wrote:
>
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> Hi Dew.
>
> On 2022-08-15 20:25, drew.moseley@gmail.com wrote:
>
> From: Drew Moseley <drew@moseleynet.net>
>
> The previous change to remove the dependency on systemd-udev-settle
> caused boot delays at least on qemu. It seems that change required
> a hwrng device but that's not necessarily available on all platforms.
>
> This changes the "Requires" to a "WantedBy" as modeled after the
> version of this file on Ubuntu 20.04.
>
> Signed-off-by: Drew Moseley <drew@moseleynet.net>
> ---
>   meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> index 0f50890dcb..b013d95932 100644
> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
>   DefaultDependencies=no
>   After=systemd-udev-settle.service
>   Before=sysinit.target shutdown.target
> -Requires=dev-hwrng.device
> -After=dev-hwrng.device
>   Conflicts=shutdown.target
>
>   [Service]
> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
>
>   [Install]
>   WantedBy=sysinit.target
> +WantedBy=dev-hwrng.device
>
>
> This looses the order. Have you tried just replacing `Requires` with
> `Wants`. So something like this:
>
>
> ```
>
> Before=sysinit.target shutdown.target
> Wants=dev-hwrng.device
> After=dev-hwrng.device
> Conflicts=shutdown.target
>
> ```
>
> If that still would cause the long waiting time on qemu?
>
> I haven't investigated the qemu issue, but maybe qemu just doesn't
> provide a hardware random source? If it doesn't provide a hardware
> random source, then installing rng-tools on there might also not make sense.
> Alternatively maybe just adding a start timeout might solve it?
> regards,
> Claudius
>
>
> I've tested the patch on a NUC7, results are the same as with qemu:
> - increased boot time
> - timeout for rng-tools.service
> [ TIME ] Timed out waiting for device /dev/hwrng.
> [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon.
>
> Regards,
> Dragos
>
>
> Interesting. I guess this patch should definitely be ignored and the patch from Khem that removes both the dev-hwrng and systemd-udev-settle depencies is the right approach. That means that the original problem that adding systemd-udev-settle was meant to solve, is no longer solved but it seems that the proposed solutions here have adverse effects elsewhere.
>
> Simply removing the systemd-udev-settle dependency fixes the issue that my customer has that caused me to start investigating here.
>
> Drew
>
> --
> mailto:drew@moseleynet.net
>
> Sorry for the confusion, I did not test any additional patches/changes that have been suggested in this email thread.
> My test was performed on current Yocto master sources. No additional patches.
> I just wanted to inform that the boot delay is also observed on real hw, not just qemu.
> Again, sorry for the confusion.
>
> Dragos
>
>
> Sorry for adding to the confusion. My point was intended to be that I am fairly certain the recent patch submitted by Khem will resolve the boot delay issue you are having as well as the original boot delay caused by systemd-udev-settle.
>
> Drew
>
> --
> mailto:drew@moseleynet.net
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#169634): https://lists.openembedded.org/g/openembedded-core/message/169634
> Mute This Topic: https://lists.openembedded.org/mt/93042904/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device

[Khem Raj]

On Fri, Aug 19, 2022 at 8:22 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> So which recent patch? Can you link to it please?
>

https://patchwork.yoctoproject.org/project/oe-core/patch/20220813170156.4040589-1-raj.khem@gmail.com/

but this needs to remove sysinit from target, I have meant to send a
v2 but had no time to do so far.

> Alex
>
>
> On Fri, 19 Aug 2022 at 17:13, Drew Moseley <drew.moseley@gmail.com> wrote:
> >
> >
> > On 8/19/22 11:07 AM, Dragos-Marian Panait wrote:
> >
> >
> > On 19.08.2022 17:34, Drew Moseley wrote:
> >
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> >
> > On 8/19/22 8:50 AM, Dragos-Marian Panait wrote:
> >
> > Hi Claudius,
> >
> > On 19.08.2022 12:36, Claudius Heine wrote:
> >
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > Hi Dew.
> >
> > On 2022-08-15 20:25, drew.moseley@gmail.com wrote:
> >
> > From: Drew Moseley <drew@moseleynet.net>
> >
> > The previous change to remove the dependency on systemd-udev-settle
> > caused boot delays at least on qemu. It seems that change required
> > a hwrng device but that's not necessarily available on all platforms.
> >
> > This changes the "Requires" to a "WantedBy" as modeled after the
> > version of this file on Ubuntu 20.04.
> >
> > Signed-off-by: Drew Moseley <drew@moseleynet.net>
> > ---
> >   meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +--
> >   1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > index 0f50890dcb..b013d95932 100644
> > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon
> >   DefaultDependencies=no
> >   After=systemd-udev-settle.service
> >   Before=sysinit.target shutdown.target
> > -Requires=dev-hwrng.device
> > -After=dev-hwrng.device
> >   Conflicts=shutdown.target
> >
> >   [Service]
> > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service
> >
> >   [Install]
> >   WantedBy=sysinit.target
> > +WantedBy=dev-hwrng.device
> >
> >
> > This looses the order. Have you tried just replacing `Requires` with
> > `Wants`. So something like this:
> >
> >
> > ```
> >
> > Before=sysinit.target shutdown.target
> > Wants=dev-hwrng.device
> > After=dev-hwrng.device
> > Conflicts=shutdown.target
> >
> > ```
> >
> > If that still would cause the long waiting time on qemu?
> >
> > I haven't investigated the qemu issue, but maybe qemu just doesn't
> > provide a hardware random source? If it doesn't provide a hardware
> > random source, then installing rng-tools on there might also not make sense.
> > Alternatively maybe just adding a start timeout might solve it?
> > regards,
> > Claudius
> >
> >
> > I've tested the patch on a NUC7, results are the same as with qemu:
> > - increased boot time
> > - timeout for rng-tools.service
> > [ TIME ] Timed out waiting for device /dev/hwrng.
> > [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon.
> >
> > Regards,
> > Dragos
> >
> >
> > Interesting. I guess this patch should definitely be ignored and the patch from Khem that removes both the dev-hwrng and systemd-udev-settle depencies is the right approach. That means that the original problem that adding systemd-udev-settle was meant to solve, is no longer solved but it seems that the proposed solutions here have adverse effects elsewhere.
> >
> > Simply removing the systemd-udev-settle dependency fixes the issue that my customer has that caused me to start investigating here.
> >
> > Drew
> >
> > --
> > mailto:drew@moseleynet.net
> >
> > Sorry for the confusion, I did not test any additional patches/changes that have been suggested in this email thread.
> > My test was performed on current Yocto master sources. No additional patches.
> > I just wanted to inform that the boot delay is also observed on real hw, not just qemu.
> > Again, sorry for the confusion.
> >
> > Dragos
> >
> >
> > Sorry for adding to the confusion. My point was intended to be that I am fairly certain the recent patch submitted by Khem will resolve the boot delay issue you are having as well as the original boot delay caused by systemd-udev-settle.
> >
> > Drew
> >
> > --
> > mailto:drew@moseleynet.net
> >
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#169634): https://lists.openembedded.org/g/openembedded-core/message/169634
> > Mute This Topic: https://lists.openembedded.org/mt/93042904/1686489
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >