I'm not sure piggy-backing on the host entropy will work reliably. I have
seen this issue in ec2, openstack boxes, etc. A newly spun up box will
exhibit this issue often.
Andrew
On Wed, Feb 15, 2017, 10:09 AM Bryan Rosander wrote:
> Hey Arnaud,
>
> Andy's solution is
Hey Arnaud,
Andy's solution is definitely the right answer for Java applications in
general (on docker or in vm or anywhere with more limited entropy).
A more general way to take care of entropy issues in docker containers
(applicable beyond NiFi) is to mount the host's /dev/random or
Hi Andy,
Thank you very much, and indeed it seems that you pointed the right
problem. The docker is running in a VM and it seems that I had a lack of
entroy.
I changed the entropy source to /dev/urandom and Nifi was able to start
immediately.
Thank you very much for your help
Arnaud
On Wed,
If this is not the issue, can you try starting NiFi and then run the following
command to generate a thread dump and provide that to the lists? It will
greatly help us determine the issue you are encountering. Thanks.
$ jcmd Thread.print
or
$ ./bin/nifi.sh dump filewithdump.txt
Andy LoPresto
Hi Arnaud,
I’m sorry you are having trouble getting NiFi going. We want to minimize any
inconvenience and get you up and running quickly.
Are you by any chance running on a VM that does not have access to any physical
inputs to generate entropy for secure random seeding? There is a known issue
Hi guys!
I'm trying to play with nifi (1.1.1) in a docker image. I tried different
configuration (cluster, single node, secured, etc.), however whatever I
try, Nifi takes forever to start (like 30-45 minutes). This not related to
data as I observe this behavior even when I instantiate the docker