When you actually try and run aapt you might get an even scarier looking error:
bash: /home/adrian/Android/android-sdk-linux_x86/platform-tools/aapt: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

I had a little bit of a panic before I realised that there is officially no 64bit version of the android SDK. After some quick googling, it turns out you need to install some 32bit compat libraries. This process has been documented over on the Fedora Project Wiki, but I’ve posted it here in case that page changes:

yum install glibc.i686 glibc-devel.i686 libstdc++.i686 zlib-devel.i686 ncurses-devel.i686 libX11-devel.i686 libXrender.i686 libXrandr.i68

There was nothing in the error log (although I’m still twiddling with php-fpm and lighttpd) but I realised that my post title (and URL) ended with “php”. Here’s the rewrite rule:

  url.rewrite-final = (
    # Exclude some directories from rewriting
    "^/(wp-admin|wp-includes|wp-content|gallery2)/(.*)" => "$0",
    # Exclude .php files at root from rewriting
    "^/(.*.php)" => "$0",
    # Handle permalinks and feeds
    "^/(.*)$" => "/index.php/$1"
  )
}

But the problem is with:

"^/(.*.php)" => "$0",

The single unescaped “.” next to “php” will translate to “any character, followed by php”. What we need is:

"^/(.*\.php)" => "$0",

But, as fate would have it, I only found this out because one of my post titles ended with the word “php”. Filed under coincidence.

The quick fix

The quickest way to combine the two is to use something like:

BookPeer::populateObjects($select->from('Books')
                                 ->where('author = ?', 'foo')
                                 ->order('title ASC')
                                 ->query()
                                 ->getDriverStatement());

The magic part is the call to “getDriverStatement” which returns the PDOStatement composed by Zend_Db_Statement_Pdo. The only downside to this is that the query will be executed by Zend_Db’s connection to the database, rather than Propel’s. If you can live with that then you may stop reading. If, like me, this sort of negligent waste of resources keeps you awake at night, then you need a rather unsightly hack.

Sleepless nights

Zend_Db doesn’t support any kind of “setConnection” method, where you pass in a PDO object. While Propel does support this, it only accepts an instance of PropelPDO. Rather than extending Propel, I thought the easiest way around this would be to create a Zend_Db adapter which, upon calling getConnection(), simply delegates back to Propel::getConnection().

The new adapter required a little hacking to get it right. There are a few methods to castrate because, understandably, the abstract adapter does a lot of checking to make sure it’s configured correctly. Instead, we’re using a PDO connection, configured elsewhere so any configuration parameters would simply get in the way.

class App_Db_Adapter_Propel_Mysql extends Zend_Db_Adapter_Pdo_Mysql {
 
   // configuration-less construction
   public function __construct() {
      parent::__construct(array());
   }
   public function getConnection() {
      $this->_connect();
      return $this->_connection;
   }
   // always use Propel's connection
   protected function _connect() {
      if (!$this->_connection) {
         $this->_connection = Propel::getConnection();
      }
   }
   // allow for no parameters to the constructor
   protected function __checkRequiredOptions(array $config) {}
}

Now we can use the Zend_Db factory (or, because the new adapter does not require any configuration, you could technically just instantiate it directly) to get our new adapter. The select object will use that adapter and we’ve avoided duplicate db connection attempts.

The finished article

$config = array('adapterNamespace'=>'App_Db_Adapter');
$select = Zend_Db::factory('Propel_Mysql', $config)->select();
 
BookPeer::populateObjects($select->from('Books')
                                 ->where('author = ?', 'foo')
                                 ->order('title ASC')
                                 ->query()
                                 ->getDriverStatement());

$arrayOfObjects = Zend_Registry::get('stuff');
$object = $arrayOfObjects['key'];
$object->foo();
// of course, I could do:
// $arrayOfObjects['key']->foo();
// but I still need the temporary assignment

Because I decided to put a stdClass object into the Zend_Registry, the code reads a little more fluently:

Zend_Registry::get('stuff')->key->foo();

As far as I’m aware, there is no significant penalty for using stdClass, but the results are much nicer.

When MySQL attempts to start up again, it won’t be able to find the relay log and replication will fail. The error messages in /var/log/mysqld.log might look something like:

[ERROR] Failed to open the relay log '/var/run/mysqld/[relay log filename]'

The pre-emptive fix is to tell MySQL to store the logs elsewhere (/var/lib/mysql/ perhaps) using the relay-log configuration option. If you’ve already suffered this problem, then the most straight forward fix is to start again; do a show master status, flush logs and then a mysqldump to get a fresh starting point on the master, and then copy the new dump over to the slave.

More information on the mysql bug report.

Whenever we want to carry out lengthy tasks or process large batches of data, we should consider executing that process in the background. The most typical way of doing this is through “cron jobs” – tasks which are scheduled to be executed at regular intervals; every 2 minutes, or at 6am every Sunday. Alternatively, you can have the web browser instigate the task by using something like shell_exec(). This guide presents a third alternative, system level daemons.

Introduction

Put simply, a daemon is a very long running process. Even when it has completed all its tasks, it stays resident, waiting for some work to do. They may spend a lot of their time sleeping, but if designed correctly, they spring to life when required. Of course, they may be constantly listening out for events (by reading a named pipe for example), rather than periodically checking to see if work is available.

Why is a daemon better than a cron job

For the same reason that web pages are not served by a cronjob running every minute. Daemons are designed to be much more responsive. Cron jobs are very reliable, but sometimes they are less “elegant”.

Why is a daemon better than shell_exec()

Irrespective of whether your process is triggered by an HTTP request or some other event, it might not be appropriate to create one process per request. If your process requires considerable resources, then you may end up swamping the server.

Broadly speaking, daemons can come in two flavours:

• Single background process
• Multiple background processes managed by a parent

Single background process

The parent creates a copy of itself (a process known as “forking”) and then dies. This leaves the single process running in the background. This type of daemon is very easy to manage and develop.

Multiple background processes managed by a parent

The parent creates a child, and then dies. That new child then creates multiple children. Each of these children is a “worker thread” and responsible for the heavy lifting. The parent of those children is responsible for distributing their workload amongst them. Apache HTTPd is a prime example of this – in the configuration you can choose how many children it can create, the minimum number of children to have available, etc.

Daemons provide a nice balance between the managed rigidity of a cron job while still being responsive.

Sample Application

I have recently found a handy PEAR library for creating PHP daemons – System_Daemon. It greatly simplifies the task of creating a daemon, although the library only supports “Single background process” type daemons.

1
2
3
4
5
6
7
8
9
10

require_once "System/Daemon.php";
System_Daemon::setOption("appName", "myDaemon");
System_Daemon::start();
while(true) {
   sleep(1); // prevent CPU hogging
   if (mt_rand(0,10) == 1) {
      // simulate a random event which requires handling
      System_Daemon::log(System_Daemon::LOG_INFO, "Doing something interesting...");
   }
}

This daemon does pretty much nothing, other than stay in the background, slowly adding to a log file. However, it demonstrates that you can have a very “lightweight” process listening for system events in only a few lines of code. It’s also important to have some element of a “forever” loop in there to keep the process going.

Signal Handlers

Signals are a very basic form of Inter-process communication. In its most common usage, you would send a SIGTERM signal to a process by using the kill command. We can trap SIGTERM signals explicitly and shutdown “nicely”. This means any work being carried out can be finished off cleanly, and then the process will terminate. We can trap many other signals, all of which can be sent via “kill” on the command line, or more interestingly, the PHP function posix_signal().

Important tip for signals

I discovered this recently : PHP’s sleep() method is interrupted by signal interrupts. This means you can have a fairly lazy daemon (e.g. sleeps for 5 seconds every interation) and when you want to wake it up, you send it a SIGTERM signal. When interrupted this way, sleep() returns how many seconds were left at the point of interruption.

System_Daemon wraps up pcntl_signal() for us into

1

System_Daemon::setSigHandler($signalConstant, $handlerName);

Init.d scripts

The System_Daemon library can generate init.d scripts for us, which means (for me at least) I can and stop/start a daemon with:

/sbin/service myDaemon restart

Because we studiously assigned a SIGTERM handler, when we ask the daemon to stop using our init.d script, it will shutdown cleanly.

Real Life Examples

Reporting System

Reports can take anywhere between 10 seconds and 3 hours to generate. Requests for report generation were stored in a database and the Reporting Daemon picked them up and processed them. The report was written to disk and made available in a reports area. The system remained responsive irrespective of how many reports were requested.

SMS Processing

A large, multinational mobile promotions company received hundreds of SMSes a second. In order to be an effective product, the SMS request must have a response as quickly as possible. During promotional periods SMS traffic would sky rocket. Each inbound SMS was written to a database and then awaited processing by the daemon. A similar system was written for outbound SMS messages. The entire SMS platform used about 5 PHP Daemons and was the bread-and-butter of a £40m+ company.

Co-ordinating remote service requests

On a much smaller scale than the previous two examples, I wrote a simple caching daemon. The daemon would listen out for SIGINT signals (sent by a web page using posix_signal()) During quiet periods, the daemon would forward requests to the remote service as they came in. During busy periods, the daemon would batch them together. Because the daemon acted as a centralised point for communications, it was the best place to judge work load. For those interested, the web page communicated with the daemon using System V queues, with more information here.

Things to watch out for

• The PCNTL library (required for this excercise) is only available when running PHP on the command line (cli mode)
• You will soon notice that calls to echo or print are quite distracting when the daemon is running.
• Going from personal experience, fatal errors can be hard to track down. Sometimes the process will die with nothing having been written to /var/log/php_error.
• Any resources opened before forking, may not be available after the fork (e.g file pointers, db connections). Because pcntl_fork() creates a copy of the current process, when the parent is killed off, all resources are closed. The child, now holding a reference to a closed resource, will trigger an error when that resource is accessed.
• Certain resources close after a period of inactivity (I’m looking at you, MySQL) – check that your resources are available before using them.
• Because the script never shuts down (or shuts down rarely) memory leaks can be problematic.

If you get the following error after having entered your mirror details:

Traceback (most recent call first):
File "/usr/lib/python2.4/subprocess.py", line 975, in _execute_child
raise child_exception
File "/usr/lib/python2.4/subprocess.py", line 542, in __init__
errread, errwrite)
File "/usr/lib/anaconda/iutil.py", line 488, in inVmware
proc = subprocess.Popen(lspci, stdout = subprocess.PIPE)
File "/usr/lib/anaconda/yuminstall.py", line 860, in doGroupSetup
if iutil.inXen() or iutil.inVmware() or \
File "/usr/lib/anaconda/yuminstall.py", line 942, in doRepoSetup
self.doGroupSetup()
File "/usr/lib/anaconda/backend.py", line 172, in doRepoSetup
anaconda.backend.doRepoSetup(anaconda)
File "/usr/lib/anaconda/dispatch.py", line 201, in moveStep
rc = stepFunc(self.anaconda)
File "/usr/lib/anaconda/dispatch.py", line 124, in gotoNext
self.moveStep()
File "/usr/lib/anaconda/text.py", line 721, in run
anaconda.dispatch.gotoNext()
File "/usr/bin/anaconda", line 1006, in ?
anaconda.intf.run(anaconda)
OSError: [Errno 2] No such file or directory

Then the fix is to increase the amount of memory available to your VM. 256MB is not enough for a CentOS 5.3 install – 384MB does the trick. I assume the same applies to any physical, real machine.

• Read MySQL’s documentation on creating SSL certificates – follow Example 1, ignoring the bit about client certificates.
• Make sure the slave can connect to the master on port 3306. For the security conscious, I don’t think this is as bad as it sounds – we restrict access by IP and our master MySQL server will require SSL credentials.
• Modify your master’s my.cnf file to include the ssl-* configuration options as per the Replication over SSL document
• Copy the master’s new ca-cert.pem, server-cert.pem and server-key.pem files to your slave machine
• This is where I fell over – specify your certificate/key files in CHANGE MASTER TO as demonstrated here and not in the my.cnf. For one reason or another, only the CHANGE MASTER TO method works.
• On the DB Master :
GRANT REPLICATION SLAVE ON *.* TO 'slave'@'slave-ip' IDENTIFIED BY 'slavepass' REQUIRE SSL;
FLUSH PRIVILEGES;

• On the DB Slave :
START SLAVE;
SHOW SLAVE STATUS;


By specifying the certificate/key file paths in the CHANGE MASTER TO command, we’ve made sure that the slave tries to connect over SSL – this is important because without this, the slave would send user/pass information in plain text. By specifying REQUIRES SSL in our master’s GRANT we’ve ensured that account can only be used if the client provides the correct SSL details. Similarly, by specifying the slave-ip for the slave user, we’ve further secured the master mysql server.

Along comes wordpress and very deftly puts to shame any half-baked CMS I ever came up with.

Hopefully, wordpress will bolster my rather stop-start blogging career.