AOLserver, Y2038 and bad MaxIdle/MaxOpen configuration examples

Back on May 12, 2006, there were reports amongst some users of AOLserver of their server mysteriously hanging, all coincidentally just around 2006-05-12 21:25 US/Eastern, or 2006-05-13 01:27:28 UTC, to be specific. It turns out it was just 1,000,000,000 (or 10e9) seconds away from the end of time in traditional Unix epoch time, which is a 32-bit signed integer, or 1,147,483,648 seconds since 1970-01-01 00:00:00 UTC. You could call this the first “Y2038” bug, which gets its name from the fact that the end of Unix time when represented by a 32-bit signed integer is in the year 2038, or 2038-01-19 03:14:07 UTC to be exact.

Bas Scheffers was the one who recognized the 10e9 coincidence, and soon after ‘Jesus’ Jeff Rogers realized that the MaxOpen and MaxIdle configuration parameters as shipped by default with ACS and OpenACS are set to 10e9 seconds, like so:

ns_param   maxidle   1000000000
ns_param   maxopen   1000000000

Reducing this number to something reasonable (say, “3600”) and restarting the server resolves the issue.

Other folks have already blogged about this issue, but just in case you missed it, here’s a short round-up:

• Michael A. Cleverly: The first Y2038 problem I’ve personally seen
• substitute: THE FUTURE LIES AHEAD
• Ryan Singel and Kevin Poulsen at Wired’s 27B-6: The Unix End Times Are Upon Us
• Kyle Johnson at bumperactive.com: Repent, For The End Is 1 x 10^9 Seconds Nigh!

Tags:
AOLserver,
Y2038,
bug,
ACS,
OpenACS