It "appears" that we might have hit a limitation of the number or size of virtual hosts in Apache as it fails to load with the following error. Below is the output of the apache service log in solaris:
2012-02-29 08:26:10 -0500 - [22775/1] - - Unable to read configuration file: /apps/eap/rsa_agent_rp1_qa/rsa-axm/agent-47-apache2/webservers/apache2/conf/webagent.conf
2012-02-29 08:26:10 -0500 - [22775/1] - - Unable to read the configuration file: /apps/eap/rsa_agent_rp1_qa/rsa-axm/agent-47-apache2/webservers/apache2/conf/webagent.xml
Note: There is no webagent.xml file. This is an unsupported feature and that part of the error message should be avoided.
ulimit number of open files limit exceeded. Especially on older Soalris systems the limit was 256. On newer systems the lmit is 64K.
apachectl - This is a shell script that the Customer calls to start and stop apache.
Inside the script above contains a variable that sets the file descriptor max value:
ULIMIT_MAX_FILES="ulimit -S -n `ulimit -H -n`"
This sets the maximum open files for the apache process to 65536. So there are obviously plenty of file descriptors available and thus not the problem, so the customer thought. After further analysis, it was determined that customer was running the 32 bit version of Apache on Solaris and apparently hitting a 256 file descriptor limit even though apache sets the file descriptor at 65536. Historically, 32-bit applications have been limited to using the first 256 numerical file descriptors for use with standard I/O streams.
extended FILE facility
The extended FILE facility allows 32-bit processes to use any valid file descriptor with the standard I/O C-library functions. The extended FILE facility is enabled from the shell level before an application is launched. So, in this case, by adding the following command to the apachctl shell, it can extend the 32-bit file descriptor process limit for apache and thus start apache with the newly a vhosts.