[Geoserver-users] Quick tip: geoserver startup in 13s instead of 6min

Daniel_Araujo_Mirand · January 27, 2017, 1:15pm

Hello everyone,

TLDR: Change the line "securerandom.source=file:/dev/random" in "/etc/java-8-openjdk/security/java.security" to point to /dev/urandom instead to start a clean geoserver install in 13 seconds instead of 6 minutes. Be mindful of security implications.

I have been puzzled by some time why geoserver 2.10 and 2.10.1 took about 6 minutes to start in a kvm virtual machine, with a newly copied war file to the tomcat folder (/var/lib/tomcat8/webapps/ in my case). Nobody else seemed to have that problem and I was unable to identify meaningful log messages or anything different with my installation to ask a proper question here. I found out that the random number generator was not getting enough entropy to even start up a new session in tomcat. I finally noticed the the following line in /var/log/tomcat8/catalina.out which exposed the problem:

INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [313,537] milliseconds.

(In my defense, we use the comma as a decimal separator in Brazil, so the above time seemed to be 0.3 seconds at a glance)

Changing securerandom.source from /dev/random to /dev/urandom in java.security solved the problem immediately. I decided to exchange a bit of security for a faster startup. Please BE AWARE OF THE SECURITY IMPLICATIONS if you do that. My accessment is that it is a reasonable tradeoff IN MY CASE.

How to test:

-take a fresh ubuntu 16.4 server "minimal virtual machine" installation in a KVM host

-Install tomcat8

-Download geoserver, jai and jai_imageio

-Unpack everything in their proper places (see http://docs.geoserver.org/stable/en/user/production/java.html)

-after tomcat stops unpacking the geoserver war, run:

service tomcat8 stop && service tomcat8 start && time curl -vvhttp://127.0.0.1:8080/geoserver/web

That will take an arbitrary amount of time to complete, depending on how much entropy your VM has access to. If it is on a busy network and you type a lot on the console, it may finish sooner, if it is completely isolated and you are using a virtual terminal instead of ssh, it may take a long time. In my case it took 6 minutes with very light ssh console usage and a quiet network. Making more usage of the ssh console brought the time down to 3 minutes.

Change the entropy source from /dev/random to /dev/urandom and you will see times for that test around 10 seconds.

Best,
Daniel

Chris_Snider · January 27, 2017, 3:35pm

Hi,

I had a similar issue on an old CentOS 5.x box. The tomcat instance running our GeoServer was taking a long time to start. I found this page that has a Linux service that can be installed to generate entropy.

https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

I was able to keep our securerandom.source on /dev/random.

Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.

-----Original Message-----
From: Daniel Araujo Miranda [mailto:miranda.dam@anonymised.com]
Sent: Friday, January 27, 2017 6:16 AM
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Quick tip: geoserver startup in 13s instead of 6min

Hello everyone,

TLDR: Change the line "securerandom.source=file:/dev/random" in
"/etc/java-8-openjdk/security/java.security" to point to /dev/urandom
instead to start a clean geoserver install in 13 seconds instead of 6
minutes. Be mindful of security implications.

I have been puzzled by some time why geoserver 2.10 and 2.10.1 took
about 6 minutes to start in a kvm virtual machine, with a newly copied
war file to the tomcat folder (/var/lib/tomcat8/webapps/ in my case).
Nobody else seemed to have that problem and I was unable to identify
meaningful log messages or anything different with my installation to
ask a proper question here. I found out that the random number generator
was not getting enough entropy to even start up a new session in tomcat.
I finally noticed the the following line in
/var/log/tomcat8/catalina.out which exposed the problem:

INFO: Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [313,537] milliseconds.

(In my defense, we use the comma as a decimal separator in Brazil, so
the above time seemed to be 0.3 seconds at a glance)

Changing securerandom.source from /dev/random to /dev/urandom in
java.security solved the problem immediately. I decided to exchange a
bit of security for a faster startup. Please BE AWARE OF THE SECURITY
IMPLICATIONS if you do that. My accessment is that it is a reasonable
tradeoff IN MY CASE.

How to test:

-take a fresh ubuntu 16.4 server "minimal virtual machine"
installation in a KVM host

-Install tomcat8

-Download geoserver, jai and jai_imageio

-Unpack everything in their proper places (see
http://docs.geoserver.org/stable/en/user/production/java.html)

-after tomcat stops unpacking the geoserver war, run:

service tomcat8 stop && service tomcat8 start && time curl -vvhttp://127.0.0.1:8080/geoserver/web

That will take an arbitrary amount of time to complete, depending on how
much entropy your VM has access to. If it is on a busy network and you
type a lot on the console, it may finish sooner, if it is completely
isolated and you are using a virtual terminal instead of ssh, it may
take a long time. In my case it took 6 minutes with very light ssh
console usage and a quiet network. Making more usage of the ssh console
brought the time down to 3 minutes.

Change the entropy source from /dev/random to /dev/urandom and you will
see times for that test around 10 seconds.

Best,
Daniel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

jive · January 27, 2017, 9:18pm

What is random number entropy?

···

On 27 January 2017 at 05:15, Daniel Araujo Miranda <miranda.dam@anonymised.com> wrote:

Hello everyone,

TLDR: Change the line “securerandom.source=file:/dev/random” in
“/etc/java-8-openjdk/security/java.security” to point to /dev/urandom
instead to start a clean geoserver install in 13 seconds instead of 6
minutes. Be mindful of security implications.

I have been puzzled by some time why geoserver 2.10 and 2.10.1 took
about 6 minutes to start in a kvm virtual machine, with a newly copied
war file to the tomcat folder (/var/lib/tomcat8/webapps/ in my case).
Nobody else seemed to have that problem and I was unable to identify
meaningful log messages or anything different with my installation to
ask a proper question here. I found out that the random number generator
was not getting enough entropy to even start up a new session in tomcat.
I finally noticed the the following line in
/var/log/tomcat8/catalina.out which exposed the problem:

INFO: Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [313,537] milliseconds.

(In my defense, we use the comma as a decimal separator in Brazil, so
the above time seemed to be 0.3 seconds at a glance)

Changing securerandom.source from /dev/random to /dev/urandom in
java.security solved the problem immediately. I decided to exchange a
bit of security for a faster startup. Please BE AWARE OF THE SECURITY
IMPLICATIONS if you do that. My accessment is that it is a reasonable
tradeoff IN MY CASE.

How to test:

-take a fresh ubuntu 16.4 server “minimal virtual machine”
installation in a KVM host

-Install tomcat8

-Download geoserver, jai and jai_imageio

-Unpack everything in their proper places (see
http://docs.geoserver.org/stable/en/user/production/java.html)

-after tomcat stops unpacking the geoserver war, run:

service tomcat8 stop && service tomcat8 start && time curl -vvhttp://127.0.0.1:8080/geoserver/web

That will take an arbitrary amount of time to complete, depending on how
much entropy your VM has access to. If it is on a busy network and you
type a lot on the console, it may finish sooner, if it is completely
isolated and you are using a virtual terminal instead of ssh, it may
take a long time. In my case it took 6 minutes with very light ssh
console usage and a quiet network. Making more usage of the ssh console
brought the time down to 3 minutes.

Change the entropy source from /dev/random to /dev/urandom and you will
see times for that test around 10 seconds.

Best,
Daniel

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Geoserver-users mailing list
Geoserver-users@anonymised.com.382…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–
Jody Garnett

Bart_van_den_Eijnde1 · January 27, 2017, 10:10pm

Jody,

tl;dr: the pool used to create the random numbers has the entropy.

Linux maintains a pool of entropy from nondeterministic sources such as device timings, interrupts, mouse and keyboard activity, and so on. The entropy pool is then used to seed a pseudo-random number generator. The resulting random numbers from /dev/random are very high quality. The problem with /dev/random is that it is blocking; it is easy to drain the pool, at which point reads will block until more entropy is available. /dev/urandom continues to produce pseudo-random bytes regardless of the pool entropy estimate (it does not block); its bytes may be suitable for most cryptographic purposes . See:
https://en.wikipedia.org/wiki//dev/random

Recently booted machines have little entropy. Virtual machines are are also vulnerable as they are often restarted (and have no hardware of their own to provide good-quality entropy).

Kind regards,
Ben.

On 28/01/17 10:18, Jody Garnett wrote:

What is random number entropy?

--
Jody Garnett

On 27 January 2017 at 05:15, Daniel Araujo Miranda <miranda.dam@anonymised.com>
wrote:

Hello everyone,

     TLDR: Change the line "securerandom.source=file:/dev/random" in
"/etc/java-8-openjdk/security/java.security" to point to /dev/urandom
instead to start a clean geoserver install in 13 seconds instead of 6
minutes. Be mindful of security implications.

     I have been puzzled by some time why geoserver 2.10 and 2.10.1 took
about 6 minutes to start in a kvm virtual machine, with a newly copied
war file to the tomcat folder (/var/lib/tomcat8/webapps/ in my case).
Nobody else seemed to have that problem and I was unable to identify
meaningful log messages or anything different with my installation to
ask a proper question here. I found out that the random number generator
was not getting enough entropy to even start up a new session in tomcat.
I finally noticed the the following line in
/var/log/tomcat8/catalina.out which exposed the problem:

INFO: Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [313,537] milliseconds.

(In my defense, we use the comma as a decimal separator in Brazil, so
the above time seemed to be 0.3 seconds at a glance)

     Changing securerandom.source from /dev/random to /dev/urandom in
java.security solved the problem immediately. I decided to exchange a
bit of security for a faster startup. Please BE AWARE OF THE SECURITY
IMPLICATIONS if you do that. My accessment is that it is a reasonable
tradeoff IN MY CASE.

How to test:

     -take a fresh ubuntu 16.4 server "minimal virtual machine"
installation in a KVM host

     -Install tomcat8

     -Download geoserver, jai and jai_imageio

     -Unpack everything in their proper places (see
http://docs.geoserver.org/stable/en/user/production/java.html)

     -after tomcat stops unpacking the geoserver war, run:

service tomcat8 stop && service tomcat8 start && time curl -vvhttp://
127.0.0.1:8080/geoserver/web

That will take an arbitrary amount of time to complete, depending on how
much entropy your VM has access to. If it is on a busy network and you
type a lot on the console, it may finish sooner, if it is completely
isolated and you are using a virtual terminal instead of ssh, it may
take a long time. In my case it took 6 minutes with very light ssh
console usage and a quiet network. Making more usage of the ssh console
brought the time down to 3 minutes.

Change the entropy source from /dev/random to /dev/urandom and you will
see times for that test around 10 seconds.

Best,
Daniel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Chris_Snider · January 27, 2017, 10:25pm

I found this page has a good explanation, but you have to scroll past the initial image. It almost put me off the page, but I found the information good:

https://calomel.org/entropy_random_number_generators.html

Some additional sources I used:

http://stackoverflow.com/questions/28201794/slow-startup-on-tomcat-7-0-57-because-of-securerandom

http://security.stackexchange.com/questions/89/feeding-dev-random-entropy-pool

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, Inc.

···

What is random number entropy?

–

Jody Garnett

On 27 January 2017 at 05:15, Daniel Araujo Miranda <miranda.dam@…7725…> wrote:

Hello everyone,

TLDR: Change the line “securerandom.source=file:/dev/random” in
“/etc/java-8-openjdk/security/java.security” to point to /dev/urandom
instead to start a clean geoserver install in 13 seconds instead of 6
minutes. Be mindful of security implications.

I have been puzzled by some time why geoserver 2.10 and 2.10.1 took
about 6 minutes to start in a kvm virtual machine, with a newly copied
war file to the tomcat folder (/var/lib/tomcat8/webapps/ in my case).
Nobody else seemed to have that problem and I was unable to identify
meaningful log messages or anything different with my installation to
ask a proper question here. I found out that the random number generator
was not getting enough entropy to even start up a new session in tomcat.
I finally noticed the the following line in
/var/log/tomcat8/catalina.out which exposed the problem:

INFO: Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [313,537] milliseconds.

(In my defense, we use the comma as a decimal separator in Brazil, so
the above time seemed to be 0.3 seconds at a glance)

Changing securerandom.source from /dev/random to /dev/urandom in
java.security solved the problem immediately. I decided to exchange a
bit of security for a faster startup. Please BE AWARE OF THE SECURITY
IMPLICATIONS if you do that. My accessment is that it is a reasonable
tradeoff IN MY CASE.

How to test:

-take a fresh ubuntu 16.4 server “minimal virtual machine”
installation in a KVM host

-Install tomcat8

-Download geoserver, jai and jai_imageio

-Unpack everything in their proper places (see
http://docs.geoserver.org/stable/en/user/production/java.html)

-after tomcat stops unpacking the geoserver war, run:

service tomcat8 stop && service tomcat8 start && time curl -vvhttp://127.0.0.1:8080/geoserver/web

That will take an arbitrary amount of time to complete, depending on how
much entropy your VM has access to. If it is on a busy network and you
type a lot on the console, it may finish sooner, if it is completely
isolated and you are using a virtual terminal instead of ssh, it may
take a long time. In my case it took 6 minutes with very light ssh
console usage and a quiet network. Making more usage of the ssh console
brought the time down to 3 minutes.

Change the entropy source from /dev/random to /dev/urandom and you will
see times for that test around 10 seconds.

Best,
Daniel

Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Daniel_Araujo_Mirand · January 30, 2017, 10:26am

That is a better solution!
Thanks for the awesome tip.
Problem solved with "apt install haveged".

Chris, sorry for the repeated reply, the first one did not go to the list.

Best,

Daniel Miranda
Forensics Expert
Brazilian Federal Police

Em 27/01/2017 13:35, Chris Snider escreveu:

Hi,

I had a similar issue on an old CentOS 5.x box. The tomcat instance running our GeoServer was taking a long time to start. I found this page that has a Linux service that can be installed to generate entropy.

https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

I was able to keep our securerandom.source on /dev/random.

Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.

-----Original Message-----
From: Daniel Araujo Miranda [mailto:miranda.dam@anonymised.com]
Sent: Friday, January 27, 2017 6:16 AM
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Quick tip: geoserver startup in 13s instead of 6min

Hello everyone,

      TLDR: Change the line "securerandom.source=file:/dev/random" in
"/etc/java-8-openjdk/security/java.security" to point to /dev/urandom
instead to start a clean geoserver install in 13 seconds instead of 6
minutes. Be mindful of security implications.

      I have been puzzled by some time why geoserver 2.10 and 2.10.1 took
about 6 minutes to start in a kvm virtual machine, with a newly copied
war file to the tomcat folder (/var/lib/tomcat8/webapps/ in my case).
Nobody else seemed to have that problem and I was unable to identify
meaningful log messages or anything different with my installation to
ask a proper question here. I found out that the random number generator
was not getting enough entropy to even start up a new session in tomcat.
I finally noticed the the following line in
/var/log/tomcat8/catalina.out which exposed the problem:

INFO: Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [313,537] milliseconds.

(In my defense, we use the comma as a decimal separator in Brazil, so
the above time seemed to be 0.3 seconds at a glance)

      Changing securerandom.source from /dev/random to /dev/urandom in
java.security solved the problem immediately. I decided to exchange a
bit of security for a faster startup. Please BE AWARE OF THE SECURITY
IMPLICATIONS if you do that. My accessment is that it is a reasonable
tradeoff IN MY CASE.

How to test:

      -take a fresh ubuntu 16.4 server "minimal virtual machine"
installation in a KVM host

      -Install tomcat8

      -Download geoserver, jai and jai_imageio

      -Unpack everything in their proper places (see
http://docs.geoserver.org/stable/en/user/production/java.html)

      -after tomcat stops unpacking the geoserver war, run:

service tomcat8 stop && service tomcat8 start && time curl -vvhttp://127.0.0.1:8080/geoserver/web

That will take an arbitrary amount of time to complete, depending on how
much entropy your VM has access to. If it is on a busy network and you
type a lot on the console, it may finish sooner, if it is completely
isolated and you are using a virtual terminal instead of ssh, it may
take a long time. In my case it took 6 minutes with very light ssh
console usage and a quiet network. Making more usage of the ssh console
brought the time down to 3 minutes.

Change the entropy source from /dev/random to /dev/urandom and you will
see times for that test around 10 seconds.

Best,
Daniel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Daniel_Araujo_Mirand · January 30, 2017, 6:28pm

Ok, checked on Ubuntu 16.04 server "minimal VM":
*The service starts immediately after installing the package.
*The service restarts upon reboot.
*The geoserver test below runs on 12s upon reboot.
*I also looked at some package internals (init.d/systemd configuration, ps -A ux, apparmor profile) and found no surprises.

It seems haveged is properly packaged on Ubuntu and it just works.

Best,
Daniel

Em 27/01/2017 20:33, Chris Snider escreveu:

Don't forget to ensure the service starts by default. Otherwise the entropy will not be generated on a reboot as expected.

Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.

-----Original Message-----
From: Daniel Araujo Miranda [mailto:miranda.dam@anonymised.com]
Sent: Friday, January 27, 2017 12:26 PM
To: Chris Snider <chris.snider@anonymised.com>
Subject: Re: [Geoserver-users] Quick tip: geoserver startup in 13s instead of 6min

That is a better solution!

Thanks for the awesome tip.

Problem solved with "apt install haveged".

Best,

Daniel Miranda

Forensics Expert

Brazilian Federal Police

Em 27/01/2017 13:35, Chris Snider escreveu:

Hi,

I had a similar issue on an old CentOS 5.x box. The tomcat instance running our GeoServer was taking a long time to start. I found this page that has a Linux service that can be installed to generate entropy.

https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

I was able to keep our securerandom.source on /dev/random.

Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.

-----Original Message-----
From: Daniel Araujo Miranda [mailto:miranda.dam@anonymised.com]
Sent: Friday, January 27, 2017 6:16 AM
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Quick tip: geoserver startup in 13s instead of 6min

Hello everyone,

       TLDR: Change the line "securerandom.source=file:/dev/random" in
"/etc/java-8-openjdk/security/java.security" to point to /dev/urandom
instead to start a clean geoserver install in 13 seconds instead of 6
minutes. Be mindful of security implications.

       I have been puzzled by some time why geoserver 2.10 and 2.10.1 took
about 6 minutes to start in a kvm virtual machine, with a newly copied
war file to the tomcat folder (/var/lib/tomcat8/webapps/ in my case).
Nobody else seemed to have that problem and I was unable to identify
meaningful log messages or anything different with my installation to
ask a proper question here. I found out that the random number generator
was not getting enough entropy to even start up a new session in tomcat.
I finally noticed the the following line in
/var/log/tomcat8/catalina.out which exposed the problem:

INFO: Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [313,537] milliseconds.

(In my defense, we use the comma as a decimal separator in Brazil, so
the above time seemed to be 0.3 seconds at a glance)

       Changing securerandom.source from /dev/random to /dev/urandom in
java.security solved the problem immediately. I decided to exchange a
bit of security for a faster startup. Please BE AWARE OF THE SECURITY
IMPLICATIONS if you do that. My accessment is that it is a reasonable
tradeoff IN MY CASE.

How to test:

       -take a fresh ubuntu 16.4 server "minimal virtual machine"
installation in a KVM host

       -Install tomcat8

       -Download geoserver, jai and jai_imageio

       -Unpack everything in their proper places (see
http://docs.geoserver.org/stable/en/user/production/java.html)

       -after tomcat stops unpacking the geoserver war, run:

service tomcat8 stop && service tomcat8 start && time curl -vvhttp://127.0.0.1:8080/geoserver/web

That will take an arbitrary amount of time to complete, depending on how
much entropy your VM has access to. If it is on a busy network and you
type a lot on the console, it may finish sooner, if it is completely
isolated and you are using a virtual terminal instead of ssh, it may
take a long time. In my case it took 6 minutes with very light ssh
console usage and a quiet network. Making more usage of the ssh console
brought the time down to 3 minutes.

Change the entropy source from /dev/random to /dev/urandom and you will
see times for that test around 10 seconds.

Best,
Daniel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ricardo_Pinho · January 31, 2017, 11:02am

Oi Daniel,
Very interesting! I use VM’s a lot and always found geoserver very slow to start.

On my “Ubuntu 16.04 server minimal VM, clean install”, running on vmware player:
(needed previous: sudo apt install curl)

sudo su
service tomcat8 stop && service tomcat8 start && time curl http://127.0.0.1:8080/geoserver/web

returns

real 0m24.487s
user 0m0.000s
sys 0m0.004s

Then I tried the havegen solution:

sudo apt install haveged

#verifydefaults
sudo vi /etc/default/haveged

#contains: checked

DAEMON_ARGS=“-w 1024”

#start havegd at boot
update-rc.d haveged defaults

sudo reboot

Run it again:
sudo su
service tomcat8 stop && service tomcat8 start && time curl http://127.0.0.1:8080/geoserver/web

#Results

real 0m24.258s
user 0m0.000s
sys 0m0.004s

The same!

Am I doing this right?

Thank’s
Ricardo

Daniel_Araujo_Mirand · January 31, 2017, 12:22pm

Hi, Ricardo,

Your geoserver already starts in a reasonable time. I was unsettled with my installation because it took six minutes. Since haveged did not change the time needed to run your test, it seems geoserver (actually tomcat8) is not limited by entropy on startup.
To make sure you have enough entropy, run the following on the same machine but on a separate console:

watch cat /proc/sys/kernel/random/entropy_avail

Then run the startup test on the original console. The reported entropy is expected to be over 1000 bits and likely over 2000 bits. "man random" says the maximum is 4096. If it goes under 1000 you are "starved" for entropy and haveged is not working properly. My guess is that your number will be a healthy value over 2000 bits and you should try a different approach to improve your startup time, which by the way seems fine to me.

Best,
Daniel

Em 31/01/2017 09:02, Ricardo Pinho escreveu:

Oi Daniel,
Very interesting! I use VM's a lot and always found geoserver very slow to start.

On my "Ubuntu 16.04 server minimal VM, clean install", running on vmware player:
(needed previous: sudo apt install curl)

sudo su
service tomcat8 stop && service tomcat8 start && time curl http://127.0.0.1:8080/geoserver/web

# returns
real 0m24.487s
user 0m0.000s
sys 0m0.004s

Then I tried the havegen solution:

sudo apt install haveged

#verifydefaults
sudo vi /etc/default/haveged
#contains: checked
DAEMON_ARGS="-w 1024"

#start havegd at boot
update-rc.d haveged defaults

sudo reboot

Run it again:
sudo su
service tomcat8 stop && service tomcat8 start && time curl http://127.0.0.1:8080/geoserver/web

#Results
real 0m24.258s
user 0m0.000s
sys 0m0.004s

The same!

Am I doing this right?

Thank's
Ricardo

Ricardo_Pinho · January 31, 2017, 12:48pm

Hi Daniel,
Thank you for the reply.

The test was made at home, running the VM on my i7 laptop.

#Running the VM on the real hypervisor server and network:
service tomcat8 stop && service tomcat8 start && time curl http://127.0.0.1:8080/geoserver/web

#returns

real 1m5.163s
user 0m0.000s
sys 0m0.024s

#And:
watch cat /proc/sys/kernel/random/entropy_avail

#returns between:

445 to 840

···

So 1m for tomcat/geoserver to restart… seems to me an eternity!

When you reported 13s, I became a bit jealous…

PS.

Sorry, I’m an old fashion guy from ZX Spectrum generation, used to count bits, and Z80 timestates…

2017-01-31 12:22 GMT+00:00 Daniel Araujo Miranda <miranda.dam@anonymised.com>:

Hi, Ricardo,

Your geoserver already starts in a reasonable time. I was unsettled with my installation because it took six minutes. Since haveged did not change the time needed to run your test, it seems geoserver (actually tomcat8) is not limited by entropy on startup.
To make sure you have enough entropy, run the following on the same machine but on a separate console:

watch cat /proc/sys/kernel/random/entropy_avail

Then run the startup test on the original console. The reported entropy is expected to be over 1000 bits and likely over 2000 bits. “man random” says the maximum is 4096. If it goes under 1000 you are “starved” for entropy and haveged is not working properly. My guess is that your number will be a healthy value over 2000 bits and you should try a different approach to improve your startup time, which by the way seems fine to me.

Best,
Daniel

Em 31/01/2017 09:02, Ricardo Pinho escreveu:

Oi Daniel,
Very interesting! I use VM’s a lot and always found geoserver very slow to start.

On my “Ubuntu 16.04 server minimal VM, clean install”, running on vmware player:
(needed previous: sudo apt install curl)

sudo su
service tomcat8 stop && service tomcat8 start && time curl http://127.0.0.1:8080/geoserver/web

returns

real 0m24.487s
user 0m0.000s
sys 0m0.004s

Then I tried the havegen solution:

sudo apt install haveged

#verifydefaults
sudo vi /etc/default/haveged
#contains: checked
DAEMON_ARGS=“-w 1024”

#start havegd at boot
update-rc.d haveged defaults

sudo reboot

Run it again:
sudo su
service tomcat8 stop && service tomcat8 start && time curl http://127.0.0.1:8080/geoserver/web <http://127.0.0.1:8080/geoserver/web>

#Results
real 0m24.258s
user 0m0.000s
sys 0m0.004s

The same!

Am I doing this right?

Thank’s
Ricardo

–

Ricardo Pinho

Daniel_Araujo_Mirand · January 31, 2017, 1:24pm

It seems your haveged is not working properly. Please perform some more tests:

1. Look for the logs in /var/log/tomcat8/catalina.out for a line similar to

/INFO: Creation of SecureRandom instance for session ID generation using //
//[SHA1PRNG] took [313,537] milliseconds./

It should read 50,000 or more in your case, which is the time necessary for tomcat8 to generate a random session ID to start replying to requests to geoserver.

2. Change the line "securerandom.source=file:/dev/random" in
"/etc/java-8-openjdk/security/java.security" to point to /dev/urandom instead (just add an "u").

3. Run the test again. If the test time goes down and the catalina.out log no longer shows messages about the creation of session IDs taking a long time, then your problem is with haveged. If the test time does not go down, then some more exploring is needed.

If you problem ends up being with haveged, I suggest you try it again on a fresh VM. I double checked it and it should work just fine on Ubuntu 16.04 after "apt-get install haveged" without any need for "update-rc.d haveged defaults" or any intervention to the daemon configuration.If you end up not being able to use haveged, you can still use the "urandom" source. Please understand the security implications before doing that, the decision is not trivial.

Best,
Daniel

Em 31/01/2017 10:48, Ricardo Pinho escreveu:

Hi Daniel,
Thank you for the reply.

The test was made at home, running the VM on my i7 laptop.

#Running the VM on the real hypervisor server and network:
service tomcat8 stop && service tomcat8 start && time curl http://127.0.0.1:8080/geoserver/web
#returns
real 1m5.163s
user 0m0.000s
sys 0m0.024s

#And:
watch cat /proc/sys/kernel/random/entropy_avail
#returns between:
445 to 840

So 1m for tomcat/geoserver to restart... seems to me an eternity!
When you reported 13s, I became a bit jealous...

PS.
Sorry, I'm an old fashion guy from ZX Spectrum generation, used to count bits, and Z80 timestates...

2017-01-31 12:22 GMT+00:00 Daniel Araujo Miranda <miranda.dam@anonymised.com <mailto:miranda.dam@anonymised.com>>:

    Hi, Ricardo,

        Your geoserver already starts in a reasonable time. I was
    unsettled with my installation because it took six minutes. Since
    haveged did not change the time needed to run your test, it seems
    geoserver (actually tomcat8) is not limited by entropy on startup.
        To make sure you have enough entropy, run the following on the
    same machine but on a separate console:

        watch cat /proc/sys/kernel/random/entropy_avail

        Then run the startup test on the original console. The
    reported entropy is expected to be over 1000 bits and likely over
    2000 bits. "man random" says the maximum is 4096. If it goes under
    1000 you are "starved" for entropy and haveged is not working
    properly. My guess is that your number will be a healthy value
    over 2000 bits and you should try a different approach to improve
    your startup time, which by the way seems fine to me.

    Best,
    Daniel

    Em 31/01/2017 09:02, Ricardo Pinho escreveu:

        Oi Daniel,
        Very interesting! I use VM's a lot and always found geoserver
        very slow to start.

        On my "Ubuntu 16.04 server minimal VM, clean install", running
        on vmware player:
        (needed previous: sudo apt install curl)

        sudo su
        service tomcat8 stop && service tomcat8 start && time curl
        http://127.0.0.1:8080/geoserver/web
        <http://127.0.0.1:8080/geoserver/web>

        # returns
        real 0m24.487s
        user 0m0.000s
        sys 0m0.004s

        Then I tried the havegen solution:

        sudo apt install haveged

        #verifydefaults
        sudo vi /etc/default/haveged
        #contains: checked
        DAEMON_ARGS="-w 1024"

        #start havegd at boot
        update-rc.d haveged defaults

        sudo reboot

        Run it again:
        sudo su
        service tomcat8 stop && service tomcat8 start && time curl
        http://127.0.0.1:8080/geoserver/web
        <http://127.0.0.1:8080/geoserver/web>
        <http://127.0.0.1:8080/geoserver/web
        <http://127.0.0.1:8080/geoserver/web>>

        #Results
        real 0m24.258s
        user 0m0.000s
        sys 0m0.004s

        The same!

        Am I doing this right?

        Thank's
        Ricardo

--
Ricardo Pinho