Daemon Bundle Laravel Package

Getting Started

medicorenl/daemon-bundle is a Symfony2 bundle, not a Laravel package. There is no service provider, no config/daemon.php, and no auto-discovery — so a Laravel developer cannot composer require it into an app/ and expect anything to happen. Treat this section as "what you'd do if you were in a Symfony2 codebase," because that is the only context in which the package has any meaning.

Minimal setup in its native environment:

1. composer require medicorenl/daemon-bundle (PHP 5.x-era constraint likely; expect it to fight with modern PHP).
2. Register it in app/AppKernel.php:

   $bundles = array(
       // ...
       new MedicoreNL\DaemonBundle\DaemonBundle(),
   );
   

3. Open the bundle's Command/ directory first — that is where the daemon base class and any provided daemon:* commands will live. Read the base class constructor and configure() method before anything else; the available options (pid file, log file, user/group, detach, umask) are the entire public API.
4. Look at DependencyInjection/ for the service id and any parameters (pid path, log path) you can override in app/config/config.yml.
5. First use case: take an existing long-running console command (queue consumer, socket poller, scheduled scraper) and convert it into a process that forks into the background, writes a pid file, and logs to a file.

If you are genuinely on Laravel: skip the package. Use supervisor + an artisan command, or laravel/horizon for queues. The concept (detach, pid file, signal handling, logging) is worth borrowing; the code is not.

Implementation Patterns

Inherit the daemon base command. The usual shape of a bundle like this is a DaemonCommand (or AbstractDaemonCommand) that you extend. You typically implement a single execute()/run() loop and let the base class handle daemonization:

class ConsumeEventsCommand extends DaemonCommand
{
    protected function configure()
    {
        parent::configure(); // keep pid/log/detach options
        $this->setName('app:consume-events');
    }

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        while (true) {
            $this->processOneBatch();
            $this->checkForStopSignal(); // or rely on base class
            usleep(250000);
        }
    }
}

Drive it from the CLI, not from HTTP. The intended workflow is:

php app/console app:consume-events --detach --pid-file=/var/run/consume.pid
php app/console app:consume-events --stop --pid-file=/var/run/consume.pid

Verify the exact option names against configure(); they vary across bundles of this vintage.

Use your DI container inside the loop. Because the command runs under the kernel, you can $this->getContainer()->get('doctrine') etc. But be careful: on Symfony2 the container is not reset between iterations, so a leaked entity manager is a real problem (see Gotchas).

Pair with a process supervisor anyway. Even when the bundle forks, most teams still wrap it in supervisor or systemd so it restarts after crashes and on deploy. The bundle's pid file then becomes a debugging artifact, not the source of truth.

Log to file, not stdout. Once detached, stdout is gone. Route the loop's output through the bundle's logger option or through Monolog configured for a file handler with rotation.

Integration tip for other commands. Expose a small admin command (app:daemon:status) that reads the pid file and checks posix_kill($pid, 0) so operators can see whether the worker is actually alive.

Gotchas and Tips

• Framework mismatch is the headline. A Symfony2 bundle cannot be consumed by Laravel. There is no bridge, and none is coming — the package has zero stars, zero dependents, and no maintenance signal. Do not plan production work around it.
• Symfony2 is end-of-life. Symfony 2.8 lost support years ago. Any security tooling will flag the framework, and the bundle itself almost certainly targets PHP 5.3–5.6. Modern PHP will surface deprecations or fatal on each(), create_function(), dynamic properties, etc.
• No Composer auto-discovery. You must edit AppKernel.php. If the bundle is installed but commands don't appear in php app/console list, the registration step is the first thing to check.
• pcntl and posix are hard requirements. Daemonization needs pcntl_fork, posix_setsid, and friends. These are disabled in many shared hosts and some Docker base images. Check php -m before anything else; a missing pcntl usually manifests as a silent no-op or a vague fatal, not a clean error.
• Detach order matters. If the bundle forks before it initializes the DB connection, you can inherit sockets unpredictably. Conversely, forking after a connection means the child shares the parent's file descriptor — a classic source of "MySQL server has gone away." Connect after daemonization, or reconnect.
• Signal handling is coarse. Expect SIGTERM/SIGINT to be handled but not SIGHUP reload. Test graceful shutdown explicitly; a pid-file-only implementation will orphan workers if the parent dies.
• Pid file races. Stale pid files after a hard kill are common. A safe status check is posix_kill($pid, 0) plus verifying /proc/$pid/cmdline contains your command name — otherwise you may signal an unrelated PID that got recycled.
• Debugging detached processes is painful. Run foreground first (--no-detach or omit --detach) with -vvv. Add error_log() or a file logger at the top of the loop; once daemonized, you lose terminal output entirely.
• Memory leaks compound. Long loops in PHP accumulate memory via Doctrine identity maps, Monolog handlers, and closures. Call $em->clear() periodically, and cap iteration counts so the supervisor recycles the process (e.g. exit after 10k jobs).
• Extension points are thin. Realistically the only seams are the base command class and DI parameters for pid/log paths. If you need custom behavior (metrics, health checks, reload), you will be overriding methods, not composing services.
• Verdict for a Laravel developer: don't pull this in. Reach for supervisor + a first-class Laravel command, horizon, or spatie/laravel-schedule-monitor. If you must study daemonization patterns in PHP, read systemd/supervisord docs and symfony/process; this bundle is not a good reference and won't run in your stack.