Both boxes are running Ubuntu Intrepid Ibex (8.10). On both machines, the jruby app was set up in its own account, with its own copy of java and jruby. The same versions of java and jruby were used; in fact, the downloads (jdk-6u10-linux-x64.bin and jruby-bin-1.1.5.tar) were copied from the old machine to the new.
The only difference I found was that the new machine (which I inherited, but is faster) has java 1.6.0_0 installed in /usr/bin. However, the account set up for the jruby app has JAVA_HOME and the PATH set so that java 1.6.0_10 is being used on both machines.
Thanks to Vladimir Sizikov (and others), I found a solution. This bug report started me on the right path, and this one almost gave me the fix. On the second one, Vladimir said "Once I replace /etc/localtime with proper America/New_York file, everything gets back to normal", so I copied the /etc/localtime file from the old box to the new. Still the same problem...
In another one of Vladimir's posts, he suggested this code, which shows the problem:
- jruby -rjava -e "p org.joda.time.DateTimeZone.getDefault.getID; p java.util.TimeZone.getDefault.getID"
After more hunting (using the SystemV timezone clue), I found this post, which suggested "change /etc/localtime to a symbolic link again", so I got rid of the localtime file and created a link to /usr/share/zoneinfo/CST6CDT, and that worked! However, it really wasn't the link that made the difference -- I copied the CST6CDT file from zoneinfo instead of linking to it, and that also worked.
So, since the localtime file from the old machine works there, but doesn't work on the new machine, and using the localtime file from zoneinfo does work on the new machine, there's still something else going on that I don't understand. But since it's working...
Perfect. That fixed it for me. I had a Java / Joda Time problem that was making me crazy. Thanks!
ReplyDelete