Daemon Startup Order Explained

Daemon Startup Order Explained

Versions: 2.0

It's important to understand what happens when your Daemon is started. It will let you put your own setup code in the appropriate places.

1. Core_Daemon::__construct()

   • Parse any command-line options that were passed. If -H, -i, or -I were passed in, the request will be handled and the daemon will exit without ever returning from the constructor.
   • If the -d option was passed in, the process will detach from your shell and begin running in the background.
   • You will not need, and should not implement, a __construct method in your application class. See the Quick Start Guide for more details.

2. setup_plugins()

   • If you implemented this method in your daemon, it will be called next. The plugins will be instantiated and their constructors will be called.
   • In most cases, you will want to implement a Lock plugin. You can chose among the lock providers available in the Core/Lock directory or write your own extending the Core_Lock_Lock base class. This ensures only 1 instance of your daemon will be running at a time.
   • From this point on, plugins will always have their teardown() method called as the daemon shuts down.

3. setup_workers()

• Similar procedurally to setup_plugins.
• If you implemented this, it will be called next. Workers will be created.
• Worker lifecycle -- including teardown() will be handled implicitly.

1. check_environment()

   • This method ensures your system has the capability to run applications built on this library.
   • It will check things like PHP version, presence of essential PHP extensions, etc.
   • It will call the check_environment() methods on all loaded Plugins and Workers to ensure their minimum requirements are met.
   • You can add your own requirements by overloading this method, building an array of error messages, and passing up that array to parent::check_environment(). Passing up an empty array is interpreted as successful.

2. Core_Daemon::init()

   • Setup signal handlers
   • Call the setup() methods on all the loaded Plugins and Workers
   • Fire the ON_INIT event
   • Call your setup() method
   • Log a 'startup complete' message.

3. setup()

   • This is where you should put any daemon-specific setup code. Open database connections, message queues, implement any custom event listeners using on(), etc.
   • If you are connecting to a database or other external resource and you use Workers or Tasks in your application, you will need to re-connect to the database in each child process you create. You can implement that connection code in the setup() methods of Core_IWorker or Core_ITask objects, or manage it yourself in the methods or closures you're running in the background.

All of these steps are done in-order, automatically, the first time you call your application's getInstance() method. The static constructor is the only way to instantiate your application. It implements the singleton pattern and begins the process outlined here.

The Core_Daemon based application object it returns, though, is not controlling execution yet. To begin the event loop, you have invoke the run() method:

• run()
  • Calling this method will start the while(true) event loop.
  • Start the Daemon's internal clock.
  • Trigger auto-restarts when appropriate
  • Fire the ON_PREEXECUTE event.
  • Call your execute() method.
  • Fire the ON_POSTEXECUTE event.
  • All of these steps will continue in the while() loop until your application receives a shutdown signal, throws an uncaught exception, or calls its own shutdown() method.