If you ever get this, chances are you are suffering from Apache leaving a bunch of stray semaphore sets lying around after an attempted restart of apache. A semaphore in simple terms, is a lock on an operation. The fix, with many thanks to Carlos Rivero solved my problem instantly. Note that his solution does not fix the root of the problem, rather it simply gets you going again.

In terminal do the following using the ipcs app, which according to the man pages "ipcs - report XSI interprocess communication facilities status" . The -s flag will show a list of semaphores sets:

Most likely you will see a fairly large list here. You need too, and it is safe too, have these deleted. The following command will again do the trick:

Note: If your apache is running as nobody or another user, be sure to substitute that other user in place of  apache above.

<h2>Cannot create SSLMutex solution</h2>

At the heart of the problem, is most likely a poorly configured Apache server. By default, SSMutex is configured to the default setting, as it was on this one server of ours. If you read the Apache.org pages for mod_ssl configuration, they have this to say about the default setting:

<pre>

The following Mutex types are available:

none | no

This is the default where no Mutex is used at all. Use it at your own risk. But because currently the Mutex is mainly used for synchronizing write access to the SSL Session Cache you can live without it as long as you accept a sometimes garbled Session Cache. So it's not recommended to leave this the default. Instead configure a real Mutex.

</pre>

There are of course optional configuration settings. At the very least, it is suggested that you set SSLMutex to sem, which will let Apache choose which SSLMutex type to use.

You will most likely find this setting in the ssl.conf file located at /etc/httpd/conf.d.

Going to the menu 'Virtual Machine->Shut Down Guest' didn't do anything. The trick was to hold down the option key, which changes the Shut Down Guest to 'Power Off'. Selecting this worked fine.

Hope this tip helps someone else.

The long and short of it all is that a security hole in Flash is in the wild, and is unpatchable according to Adobe.

Mike Murray, the chief information security officer at Orlando, Fla.-based Foreground Security says "The best mitigation is to not use Flash, but we know that that's impossible for most users, since Flash is so widely used on the Web. Almost everyone using the Internet is vulnerable to a Web site that allows content to be updated inappropriately. That's not hyperbole, it's just fact. This has the potential to affect any social media site, any career site, any dating site, many retail sites and many cloud applications. That's why this attack is so serious. End users would never know they got exploited."

To read all about this, and how it might affect you, please take a moment to get educated and read the story at ComputerWorld.com.

Travel with science editor Susan Watts to World War II code-breaking centre Bletchley Park. Visit where Turing worked to find out more about the man and speak to some of his relatives.

The solution is really quite simple. In Adobe's infinite wisdom, they don't allow parameters in the URL when trying to load the XMLRPC connection file. ExpressionEngine uses something like yoursite.com/index.php?ACT=10&ID=1 as the way to connect. If you look at the server logs, Contribute will truncate your URL to just /index.php.

The solution is rather simeple, and requires only that you can modify your .htaccess file. Simply add a line like this:

The 'yoursite.com/?ACT=10&id=1 should be replaced with whatever URL ExpressionEngine gives you after turning on, and setting up the Metaweblog API feature in ExpressionEngine Modules. For a complete how-to on setting this up, check out Ryan Irelan's excellent screencast on setting up external editors. If you aren't familiar with Ryan's screencasts on ExpressionEngine, now is the time to check those out too. At just $5 a pop, there is something for everyone in them. I have been using ExpressionEngine for two years and still learnt a lot of things.

Enjoy.

If you have your own hand crafted WordPress plugins you wish to update, here is some useful information to help you:

1 - wp_category and wp_post2cat don't exist anymore. DO NOT recreate them, it will not help you.
2 - WordPress now uses three new tables to replace the old tables: wp_terms, wp_term_relationships, wp_term_taxonomy.

Here is an example code that I had in one of my plugins:

Here is the code after I updated it:

Here is what I did to upgrade my plugin:
1 - I didn't feel like rewriting tons of code, so where I had a table column in a select, I changed it to as tablename.column. For example, in the above example I needed cat_ID, cat_name and category_parent. The new names for those are wp_terms.term_id, wp_terms.name and wp_term_taxonomy.parent. By using wp_terms.term_id AS cat_ID, I would not have to modify any other code where I used cat_ID.
2 - Instead of requiring two tables in the FROM section of a MySQL SELECT, I need three, which also means I needed to add an additional MySQL WHERE query also. To clarify this part, I am going to outline it here:

OLD FROM -> NEW FROM
wp_category -> wp_terms
wp_post2cat -> wp_term_relationships
non-existent -> wp_term_taxonomy

New WHERE statements

becomes

And to fix the last relationship which will join the posts to the WordPress categories:

becomes

Note that you will need to add one last MySQL where clause. The reason for this last one, is that the taxonomy is no longer used just for categories. Since our old WordPress plugin we are updating was used for categories, we want to ensure we select just categories from our new tables.

Here is the one additional MySQL WHERE clause:

Hopefully this will help someone out in their WordPress upgrade problem. If you see any errors in my code, or have any questions, post a comment. I usually try to check my comments regularly but I am worked to the gills right now, so I might not respond very quickly.

Enjoy!

First off there are two ways to install a PECL package. First is to simply issue a pecl command at the prompt: pecl install geoip

Or, you can download the package and install it manually:

Either of these methods still requires you to add a file in /etc/php.d to enable the new package. For the geoip package you can add a file called geoip.ini to /etc/php.d

You can check quickly if geoip is installed by running 'php -r 'print_r(phpinfo());' | grep -i geoip' at the command line:

If there is no output, then you have done something wrong and geoip is not installed.

However, if you get something like this:

You might scratch your head and say to yourself, but I am trying to install the geoip distribution, what gives? What the PECL package is looking for is the geoip-devel rpm. Simply issue yum install geoip-devel at the prompt, then go ahead with one of the above methods of installing the PECL geoip package.

Since I wrote that article, I found that my MailScanner was again hogging the CPU. Last time it was an issue with f-prot interaction, this time it is a problem apparently with MailScanner.

Here is what I did to debug this issue, and here is the post that helped me learn more about MailScanner.

First thing was to check top:

When I did a strace -p 7078 I saw nothing. Literally. So that was not much help. Next up, see what ps has for me:

There is my stuck process, and apparently it is stuck cleaning messages. But which messages? The MailScanner working directory has more than one email in it, and to be picky I would prefer not to delete a valid email. Next step to be thorough is to do an strace on MailScanner itself and see what it is up to. You will see a lot of output, and then finally you should see a list of PID's coupled with the email that is stuck:

Note the different PID on these files that seem to cause MailScanner to loop indefinitely: [pid 24167]. Now we can run a trace on that PID:

Now we will get more looping text, but this time it will show the emails that MailScanner is stuck on:

While MailScanner is still running, you can go to the MailScanner working directory and see a list of folders named after the MailScanner PID's:

Go into the problem PID's directory and you will see a list of files that make up the email that is stuck. This might help you determine why the email is stuck. In my case, there was a virus attached to an email, which, like the this post pointed out, was also causing MailScanner to loop.

Yes, you can easily just go to /home/virtual/FILESYSTEMTEMPLATE/services/sendmail/mqueue/ and delete all the emails in the queue and restart MailScanner, but I wanted to be sure that one of the emails was really the problem.

This little how-to does not fix the real issue of MailScanner getting stuck in an endless loop, but merely solves the current issue of MailScanner hogging the CPU. We can fully expect the issue to rear its ugly little head again at some point. Hopefully by that time, we will have solved the root issue.