Michael Biebl <bi...@debian.org> writes: > Am 10.05.2018 um 19:22 schrieb Russ Allbery:
>> I may be misunderstanding the nature of the issue, but I believe that a >> Type=oneshot service that runs a small C program that calls getrandom() >> and then exit(0) when it returns would provide a useful facility. >> krb5-kdc could then just declare a dependency on that service and >> wouldn't be started until randomness was available. > So we'd shift the waiting for randomness-to-be-available from one > service to another? I don't quite see yet, where the benefit is in that. > What's better if a wait-for-rng-ready binary blocks on getrandom() > instead of the krb5-kdc binary itself? We wouldn't shorten the time we > have to wait this way. It means that the configured timeout for which it's reasonable to wait for randomness is centralized in one service that can set that based on understanding of what's necessary in practice, and timeouts to catch other startup problems can remain in place for other services. Right now, to have krb5-kdc wait for randomness requires extending the startup timeout of the service as a whole, thus potentially not diagnosing various other problems that might be preventing the KDC from starting unrelated to randomness. It also opens the door to what I think would be the best long-term solution (although the kernel and systemd folks may disagree with me): having the kernel explicitly signal userspace in some way when getrandom() is ready and exposing that in the systemd target dependency tree, so that nothing has to poll and the dependency can be handled in the same way that, e.g., devices appearing can be handled. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers