Why a Too‑Long /etc/hosts Line Stalled My Spring Boot Service (and How to Fix It)

Problem Environment

System: CentOS 6.9 (Final) 2.6.32-696.16.1.el6.x86_64

Java: 1.8.0_151

Apollo: 1.4.0

Framework: Spring Boot

Issue

After starting the service, it hangs while trying to fetch configuration from Apollo; no configuration is retrieved.

<code>2019-11-20 21:06:47.884 [main] INFO c.c.f.f.i.p.DefaultApplicationProvider - App ID is set to xdm-test by app.id property from /META-INF/app.properties
2019-11-20 21:06:47.886 [main] INFO c.c.f.f.i.p.DefaultServerProvider - Loading /opt/settings/server.properties
2019-11-20 21:06:47.886 [main] INFO c.c.f.f.i.p.DefaultServerProvider - Environment is set to [PRO] by property 'env' in server.properties.</code>

Investigation

Apollo returns configuration when manually requested.

The same code runs fine in another VPC environment.

Changing Tomcat startup parameters (e.g., using /dev/urandom) had no effect.

Network capture with

tcpdump

showed no request to Apollo.

Root Cause

The

/etc/hosts

file contained a single line mapping one IP address to 45 domain names, which broke the hosts parsing and prevented the service from resolving its own hostname.

<code>192.168.108.108 a1.com a2.com a3.com a4.com a5.com a6.com a7.com a8.com a9.com a10.com a11.com a12.com a13.com a14.com a15.com a16.com a17.com a18.com a19.com a20.com a21.com a22.com a23.com a24.com a25.com a26.com a27.com a28.com a29.com a30.com a31.com a32.com a33.com a34.com a35.com a36.com</code>

Solution

Split the long line into multiple lines, for example:

<code>192.168.108.108 a1.com a2.com a3.com a4.com a5.com a6.com a7.com a8.com a9.com a10.com a11.com a12.com a13.com a14.com a15.com a16.com a17.com a18.com
192.168.108.108 a19.com a20.com a21.com a22.com a23.com a24.com a25.com a26.com a27.com a28.com a29.com a30.com a31.com a32.com a33.com a34.com a35.com a36.com</code>

After restarting the service, configuration is fetched successfully.

Further Thoughts

The issue reproduces on CentOS 6.x (e.g., 6.9, 6.10) but not on CentOS 7.x, indicating the bug was fixed in newer kernel versions.