On Mi, 24.04.19 06:40, Stephen John Smoogen (smooge(a)gmail.com) wrote:
> As mentioned before: systemd itself already needs entropy itself
> assigns a random 128bit id to each service invocation, dubbed the
> "invocation ID" of it, and it generates the machine ID and seeds its
> hash table hash functions), hence rngd doesn't cut it anyway, since it
> starts after systemd, being a service managed by systemd. If rngd was
> supposed to fill up the entropy pool at boot, it would have to run as
> initial PID 1 in the initrd, before systemd, and then hand over to
> systemd only after the pool is full. But it doesn't, hence rngd is
> pointless: it runs too late to be useful.
useful to systemd and your problems. What people are trying to say is that
it is useful to their problems.
but it can't be. it's logically impossible. let me explain this again:
1. systemd needs entropy to start services and other purposes
2. if the entropy pool is not filled up systemd thus might need to
wait for it to fill up, in a blocking fashion. When it blocks for
that it won't start any services until it unblocks again.
3. rngd is supposed to fill up the entropy pool, thus allowing systemd
to unblock and start the first services
4. rngd runs as regular service however, i.e.
And ther you have your ordering cycle:
a. systemd starts before rngd.
b. rngd runs before the entropy pool is full.
c. the entropy pool needs to be full for systemd to start
a before b before c before a before b before c before a? How's that
So if you want rngd to stay and do something useful, then it needs to
be modified to start *before* systemd, in the initrd, before systemd
is invoked. i.e. not as regular service, but as kind of an init before
the real init.
The current mode is just entirely bogus...
Lennart Poettering, Berlin