Tried to debug failure & traced it to subprocess.Popen calling fork_exec()
with a bad path, but couldn't reproduce error from manual debugging
using ``nix-shell``.
Bad path meaning that most paths were of form /nix/store/.../bin/sby,
but one path was "sby" only. That's my only guess as to what would
be causing this failure.
`rngd` seems to be the root cause for slow boot issues, and its functionality is
redundant since kernel v3.17 (2014), which introduced a `krngd` task (in kernel
space) that takes care of pulling in data from hardware RNGs:
> commit be4000bc4644d027c519b6361f5ae3bbfc52c347
> Author: Torsten Duwe <duwe@lst.de>
> Date: Sat Jun 14 23:46:03 2014 -0400
>
> hwrng: create filler thread
>
> This can be viewed as the in-kernel equivalent of hwrngd;
> like FUSE it is a good thing to have a mechanism in user land,
> but for some reasons (simplicity, secrecy, integrity, speed)
> it may be better to have it in kernel space.
>
> This patch creates a thread once a hwrng registers, and uses
> the previously established add_hwgenerator_randomness() to feed
> its data to the input pool as long as needed. A derating factor
> is used to bias the entropy estimation and to disable this
> mechanism entirely when set to zero.
Closes: #96067
The build has been broken since gdk-pixbuf-xlib was broken out into a
separate package in #88086.
For some reason if I just add gdk-pixbuf-xlib.dev the headers don't make it
into CFLAGS.
This commit fixes the ejabberd tests for hydra:
mod_http_upload and mod_disco need to be explicitly enabled, and a
handler needs to be setup to make it work. Also, the client needs to be
able to contact the server.
The commit also fixes the situation where http upload failed: in that
case the client would wait forever because nothing catched the error.
Finally, there remains a non-reproducible error where ejabberd server
fails to start with an error like:
format: "Failed to create cookie file '/var/lib/ejabberd/.erlang.cookie': eacces"
(happens ~15%) I tried to check existence of /var/lib/ejabberd/ in
pre-start script and saw nothing that would explain this error, so I
gave up about this error in particular.
