CiviCRM Community Forums (archive)

We have at least one confirmed (and perhaps more that I didn't confirm) instances in which a site's Config.IDS.ini file suddenly becomes zero length.

That causes CiviCRM to grind to a halt with an error along the lines of:

Fatal error: Uncaught exception 'Exception' with message 'dude, Please make sure the folder is writable' in /var/aegir/platforms/ducky-ourpowerbase-d6-c3.4/sites/all/modules/civicrm/packages/IDS/Monitor.php:218 Stack trace: #0 /var/aegir/platforms/ducky-ourpowerbase-d6-c3.4/sites/all/modules/civicrm/CRM/Core/IDS.php(140): IDS_Monitor->__construct(Array, Object(IDS_Init)) #1 /var/aegir/platforms/ducky-ourpowerbase-d6-c3.4/sites/all/modules/civicrm/CRM/Core/Invoke.php(88): CRM_Core_IDS->check(Array) #2 /var/aegir/platforms/ducky-ourpowerbase-d6-c3.4/sites/all/modules/civicrm/drupal/civicrm.module(363): CRM_Core_Invoke::invoke(Array) #3 [internal function]: civicrm_invoke() #4 /var/aegir/platforms/ducky-ourpowerbase-d6-c3.4/includes/menu.inc(350): call_user_func_array('civicrm_invoke', Array) #5 /var/aegir/platforms/ducky-ourpowerbase-d6-c3.4/index.php(17): menu_execute_active_handler() #6 {main} thrown in /var/aegir/platforms/ducky-ourpowerbase-d6-c3.4/sites/all/modules/civicrm/packages/IDS/Monitor.php on line 218

In the confirmed instance, the date/time modified is 4:24 am this morning. I cross-checked with the apache error log (and yes, immediately after that time, we started logging this Uncaught exception error).

Then, I cross-referenced with our apache access log, and I found:

xxxx.xxx:80 69.171.228.251 - - [23/Mar/2012:04:24:40 -0400] "GET /civicrm/file?reset=1&id=73&eid=58 HTTP/1.1" 301 652 "-" "facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)"
xxxx.xxx:443 69.171.228.247 - - [23/Mar/2012:04:24:41 -0400] "GET /civicrm/file?reset=1&id=73&eid=58 HTTP/1.1" 200 29350 "-" "facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)"

This site is configured to redirect from port 80 to port 443 (hence the 301). I'm not sure why the source IP address changes though. When I manually enter that URL and watch the access log, I get:

xxxx.xxx:80 24.186.87.244 - - [23/Mar/2012:15:15:43 -0400] "GET /civicrm/file?reset=1&id=73&eid=58 HTTP/1.1" 301 625 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Iceweasel/10.0.2"
xxxx.xxx:443 24.186.87.244 - - [23/Mar/2012:15:15:43 -0400] "GET /civicrm/file?reset=1&id=73&eid=58 HTTP/1.1" 200 27311 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Iceweasel/10.0.2"

And, I'm delivered an image file and... the Config.IDS.ini does not become zero length. Also, the same facebook query is recorded for yesterday at that time and we didn't have any errors.

As much as I'd like to blame facebook... I'm wondering if there's a timing issue (our backups happen at close to this time). Perhaps a particular query combined with a sudden burst in Disk I/O causes that file to be improperly created??

Any ideas would be welcome.

I've prepared a work around patch in the event that the file becomes zero length... but I'm not sure if that's the right approach or if I should be digging deeper to figure out how the file become zero length in the first place.

--- CRM/Core/IDS.php.orig 2012-02-10 16:22:14.000000000 -0500
+++ CRM/Core/IDS.php  2012-03-23 15:20:08.000000000 -0400
@@ -80,7 +80,7 @@
       $config =& CRM_Core_Config::singleton( );

       $configFile = $config->configAndLogDir . 'Config.IDS.ini';
-      if ( ! file_exists( $configFile ) ) {
+      if ( ! file_exists( $configFile ) || filesize( $configFile ) == 0 ) {
           $tmpDir = empty( $config->uploadDir ) ? CIVICRM_TEMPLATE_COMPILEDIR : $config->uploadDir;
           // also clear the stat cache in case we are upgrading
           clearstatcache( );