Coldfusion, Will not start and jvm.cfg

Coldfusion 9.0 relies upon a Java virtual machine to provide a host for its process. If it will not start the Java virtual machine may be missing things it depends on. In this case if the operating system Java package is updated and the Coldfusion jvm.cfg (referred to as jvm.config) refers to a static path for an old java package it can obscurely suggest the jvm.cfg might be corrupt. Although this is not the case, the Java package may be missing.

From the /opt/coldfusion9/logs/cfserver.log

The init.d startup script may refer to an explicit Java path and Java binary (but this is not the only location it may be set):

/etc/init.d/coldfusion -> /opt/coldfusion9/bin/coldfusion

The init.d script cfstart routine may prepare another file "jvm.config" for sourcing override settings

For example the jvm.config file may exist in:

/opt/coldfusion9/runtime/bin/jvm.config

And to get it ready a symlink is created in the

/opt/coldfusion9/runtime/bin

directory.

[NOTE: This is so that when the ELF binary "senses" or detects an optional jvm.config in its default execution directory it will automatically source its contents.]

Where $CFSTART is:

CFSTART='$SUCMDFILE -s /bin/sh $RUNTIME_USER -c "export PATH=$PATH:$CF_DIR/runtime/bin; export LD_LIBRARY_PATH=$LD_LIBRARY_PATH; cd $CF_DIR/runtime/bin; nohup $CF_DIR/runtime/bin/coldfusion9 -jar jrun.jar -autorestart -start coldfusion &"'

And /opt/coldfusion9/runtime/bin/coldfusion9 referred "to" in the CFSTART command string is an ELF binary that sources a jvm.config file

The jvm.config may contain an optional override at the top with appropriate "warnings":

Since the path /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.34.x86_64/jre/ is "explicit" and does not point at the convention in RHEL /usr/lib/jvm/jre which is normally

/usr/lib/jvm/jre -> /etc/alternatives/jre
/etc/alternatives/jre -> /usr/lib/jvm/jre-1.6.0-openjdk.x86_64
/usr/lib/jvm/jre-1.6.0-openjdk.x86_64 -> java-1.6.0-openjdk-1.6.0.34.x86_64/jre

and is updated by the alternatives method when updating the actual java runtime installed for the operating system.

Explicitly pathing is "brittle" and will break without warning when a regular # yum update command is run to update all the packages in a RHEL or like operating system.

Therefore, if you are being explicit in order to "control" the version of Java being used by an application, also be aware you may want to "pin" or "versionlock" a specific package so it isn't unintentionally updated without warning

$ sudo yum install yum-plugin-versionlock

Also be [aware] that RHEL5 and RHEL6 have different versionlock plugin pacakge names.

For RHEL5 it is:

# yum install yum-versionlock

# rpm -qa|grep java >> /etc/yum/pluginconf.d/versionlock.list

For RHEL6 it is:

# yum install yum-plugin-versionlock

# rpm -qa|grep java >> /etc/yum/pluginconf.d/versionlock.list
[consider if you versionlock a package; there are security implications if you do not regularly  update the package, this is a perfectly rational procedure however if you need more time to test]

Or be sure to keep the /opt/coldfusion9/runtime/bin/jvm.config file up to date when updating the operating system java version.

Or do not define it here (jvm.config) and allow the settings in the /etc/init.d/coldfusion9 startup script to take priority.

Unfortunately Adobe documentation demonstrating explictly choosing a Java version to host the Coldfusion process "other than" the Java jre that comes with the product is brief and general, to the point of not describing pitfalls relating to regular patching and updating for bug fixes and security matters.