Category Archives: SugarCRM

sugar_file_utils.php Fatal error: on migrating SugarCRM

[text]Fatal error: sugar_file_put_contents_atomic() : fatal rename failure ‘/tmp/tempI3QakJ’ -> ‘cache/modules/Employees/Employeevardefs.php’ in /home/account_name/public_html/sugarcrm/include/utils/sugar_file_utils.php on line 187
[/text]

It’s a permissions thing. Setting up a new server to migrate SugarCRM. The new install of Sugar appears ok until I update the config.php file and then it breaks.

The trigger is the permissions on the second named file

[text]
‘cache/modules/Employees/Employeevardefs.php’
[/text]

Just for clarity the line 187 that is referenced is in this function in SugarCRM

[php]
180 if (!@rename($temp, $filename))
181 {
182 @unlink($filename);
183 if (!@rename($temp, $filename))
184 {
185 // cleaning up temp file to avoid filling up temp dir
186 @unlink($temp);
187 trigger_error("sugar_file_put_contents_atomic() : fatal rename failure ‘$temp’ -> ‘$filename’", E_USER_ERROR);
188 }
189 }
[/php]

The error is triggered when line 183 fails to rename the temp file as the cache file. Permissions on the temp directory must be ok or the creation of the temp file would have triggered an earlier error. It is also unlinked (deleted) successfully which means that at line 186 the temp directory/file permissions are ok. So it must be the cache directory at issue.

In this case the cpanel server was allocating the user account as both owner and group. Sugar apparently wants to see Apache as the group, or at least the Apache account owner, ‘nobody’. So while the chmod settings for owner and group read/write were ok, the group was incorrect.

[text]
#chown -R owner:nobody sugarcrm/
[/text]

Command for the ownership change for the group to nobody.

Edit: As correctly pointed out I had used chmod when I manually typed up the instructions. Corrected the above to read chown. Thanks Derek.

MySQL & PHP Upgrade CentOS server

I now appear to have a new Linux VPS running with CentOS and Plesk. I wont go into the stupid details of why this has taken 2 weeks to provision, or another 2 days for me to ‘fix’ the ip addresses etc, only to find that CentOS has an older version of PHP at 5.1 and MySQL needing to be upgraded to match with PHP 5.3 when I tried to upgrade.

I referenced Christian Montoya’s blog for the update for PHP but found that I had a couple of issues.

The first was that when I ran the yum command for the PHP upgrade it complained about the MySQL support / version.

yum update php

was changed to include MySQL

yum update php mysql

Which did what I needed.

Running the

php -v

Advised that the updated 5.3 version was installed but I then found that MySQL was not running.

A quick wade around discovered that /var/log/mysqld.log that there was another error preventing MySQL from starting. This was the message:

[ERROR] /usr/libexec/mysqld: unknown option '--skip-bdb'

Editing the /etc/my.cnf file to comment out this option in both the main section and the mysql_safe section of the file fixed this issue and allowed MySQL to start.

Next I had in the mysql log messages like:

[ERROR] Column count of mysql.proc is wrong. Expected 20, found 16. 
Created with MySQL 50077, now running 50156. 
Please use mysql_upgrade to fix this error.

So trying to use mysql_upgrade as a command by itself fails for user root@local host

]# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
mysqlcheck: Got error: 1045: Access denied for user 'root'@'localhost' (using password: NO) when 
trying to connect
FATAL ERROR: Upgrade failed

Using the correct username is as simple as 

#mysqlupgrade -u username -p  [Enter]

Which will prompt you for the password and then run the upgrade with the authenticated username.

And that, I hope, completes the backend upgrade so I can run SugarCRM on this server.

SugarCRM upgrading 5.2 to 5.5 and beyond

I’ve started a process of upgrading our live SugarCRM system from 5.2.0c to later versions. The upgrade paths leave a blind trail at 5.5.4 as there is currently no direct upgrade to 6.1 from 5.5.4. So I am using 5.2.0 to 5.5.1 and then 5.5.1 to 6.1beta5.

The main reason for the upgrade is that we want to use the projects tracking and in 5.2.0 there is no ability to connect the projects panels with prospects/targets, only with accounts/contacts.

I use the prospects/targets for anyone that may be associated with a project but is not a key player, i.e. I dont need to see as much detail for a business or person that plays a minor role.

5.5.x fixes that limitation, and I expect 6.1 will also, but the question is how much time do I spend on 5.5 given that 6.1 is looking pretty stable.

I think I’ll be shooting for 6.1 as the next upgrade to production unless we find a show stopper in testing.

Sugar CRM upgrade IIS7 Internal Server error timeout

There are days that I loathe software. For the record, the config this relates to is Windows Server 2008, IIS 7, SugarCRM 5.2.0c, separate MS-SQL 2005 database server. PHP 5.2.6,

HTTP Error 500.0 – Internal Server Error
C:inetpubphpphp-cgi.exe – The FastCGI process exceeded configured activity timeout

Two ‘supposedly’ identical servers. SugarCRM 5.2.0c installed on production and working a treat. The dev system just just been setup for a new instance of Sugar to provide for testing of the upgrade path to 5.5.1 and probably 6.1 but first the cloned 5.2.0c had to work.

A freshly installed 5.5.1 on dev was working and apparently so was the copied 5.2.0c from production. Except that the Upgrade Wizard in the cloned copy gave the time out error shown above. The 5.5.1 however worked fine which left me thinking it was a Sugar issue, or specific to the site or app pool.

To cut a full 8 hour day down to the stuff we need to know, the issue was that while I looked at all the settings, site level, app pool, and server, for whatever obscure reason the Fast-CGI icon was not showing in the dev server configuration panel.

http://www.iis.net/download/AdministrationPack
The admin pack for IIS7 is required for that interface and provided access to the time out setting which I raised from 30 to 300 and the Upgrade Wizard could then function.

There is a marked difference in performance between 5.2.0c and 5.5.1 in the Upgrade Wizard and this is the bit that threw me at first, because the 5.5.1 clean install would run with the default timeout set at 30 while 5.2.0c would not.