When examining the log files closely, one critical line jumps out:

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

This 5-minute+ delay occurs during the initialization of Java's SecureRandom class, specifically when Tomcat attempts to generate session IDs for the host-manager webapp. The root cause lies in how Linux handles entropy collection for cryptographic operations.

New virtual machines often lack sufficient entropy (randomness) in the system pool because:

• No physical hardware random number generators (like /dev/hwrng)
• Few system activities generating entropy (keyboard/mouse inputs, disk activity)
• Limited interrupt timing variations in virtualized environments

Add this to your Tomcat's setenv.sh:

export JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom"

This tells Java to use the non-blocking entropy source. For production systems, consider these alternatives:

# Install haveged for better entropy generation
sudo apt-get install haveged -y
sudo service haveged start

# Or for AWS systems using EC2 instances:
sudo apt-get install rng-tools -y
sudo sed -i 's/HRNGDEVICE=\/dev\/null/HRNGDEVICE=\/dev\/hwrng/' /etc/default/rng-tools
sudo service rng-tools start

Check available entropy before and after fixes:

cat /proc/sys/kernel/random/entropy_avail

Healthy systems should show values >1000. For monitoring:

watch -n 1 cat /proc/sys/kernel/random/entropy_avail

For security-conscious deployments, modify CATALINA_BASE/conf/catalina.properties:

# Use a different algorithm with faster seeding
securerandom.source=file:/dev/./urandom
securerandom.algorithm=NativePRNG

While /dev/urandom is cryptographically secure for most use cases, consider these factors:

• Session ID collision probability remains extremely low
• The initial entropy pool weakness only affects the first few requests
• For financial systems, combine with hardware security modules

---

When your Tomcat 7 server suddenly stops responding during webapp deployment without any clear error messages, it's typically related to one of these underlying issues:

// Check if Tomcat is actually running
ps aux | grep tomcat

// Alternative check using netstat
netstat -tulnp | grep java

The key clue in your logs is this critical line:

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

This 5-minute delay during SecureRandom initialization is a known issue on Linux systems with insufficient entropy.

Quick Fix (for testing):

# Install haveged to increase entropy
sudo apt-get install haveged -y
sudo service haveged start

Permanent Solution (production):

# Edit Tomcat's startup script
sudo nano /opt/tomcat/bin/catalina.sh

# Add this line before the exec line:
JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom"

After applying changes, verify with:

# Check available entropy
cat /proc/sys/kernel/random/entropy_avail

# Should show >1000 for healthy systems
# Monitor Tomcat startup time
time /opt/tomcat/bin/startup.sh

For environments where changing the random source isn't acceptable:

# Option 1: Use rng-tools
sudo apt-get install rng-tools
sudo nano /etc/default/rng-tools
# Add: HRNGDEVICE=/dev/urandom
sudo service rng-tools restart

# Option 2: Pre-seed entropy before Tomcat starts
sudo apt-get install haveged
sudo systemctl enable haveged
sudo systemctl start haveged

The fundamental issue stems from how Linux handles entropy:

• Tomcat needs cryptographically secure random numbers for session IDs
• /dev/random blocks when entropy pool is exhausted
• Virtual machines often lack physical entropy sources

Solution	Security Level	Startup Time
/dev/random (default)	High	Minutes
/dev/./urandom	Medium	Seconds
haveged	Medium-High	Seconds

If the entropy solution doesn't resolve your issue:

# Check for file permission issues
sudo -u tomcat ls -la /opt/tomcat/webapps/

# Verify available memory
free -h

# Check for port conflicts
netstat -tulnp | grep -E '8080|8009'