Weave Code
Daemonizable Command Laravel Package
wrep/daemonizable-command
Laravel package for turning Artisan commands into long-running daemons. It provides a base command with loop control, graceful shutdown, signal handling, and start/stop/restart support, making it easier to build reliable background workers and scheduled tasks.
Daemonizable (endless running) commands for Symfony.
Frequently asked questions about Daemonizable Command
- How do I install wrep/daemonizable-command in a Laravel app?
- Install it with Composer using composer require wrep/daemonizable-command. There is no service provider or config file to publish because the package is a Symfony Console base class rather than a Laravel-native package. You then either extend its DaemonizableCommand class or apply its trait to an existing command. Make sure the pcntl extension is enabled in the PHP runtime that will execute the daemon.
- Does wrep/daemonizable-command support Laravel 10, 11, and 12?
- The package targets PHP 8.x with Symfony Console 6 or 7, which aligns with Laravel 10 through 12. However, it does not integrate with Laravel's command lifecycle beyond being a sibling of Illuminate\Console\Command. If you extend DaemonizableCommand you lose Laravel helpers such as info(), option(), confirm(), table(), and progressBar(). Check your Laravel version's native Command::trap() support before adding the dependency.
- Why does my daemonizable command fail when pcntl is not available?
- The daemon loop and signal handling depend on the pcntl extension. pcntl is not available on Windows, so local development and Windows CI runners cannot execute the daemon. Many stock PHP CLI Docker images do not compile it by default and require something like docker-php-ext-install pcntl followed by an image rebuild. Shared hosting environments may also block it.
- How is wrep/daemonizable-command different from php artisan queue:work?
- For queue consumers, php artisan queue:work is strictly better. It provides max-time, max-jobs, and memory recycling plus retry semantics, failed_jobs visibility, and graceful shutdown. This package only supplies the loop and signal handling, with no job recycling or queue integration. Use it only for genuinely long-lived pollers or listeners that are not queue-backed.
- How do I stop a daemonizable command gracefully?
- DaemonizableCommand listens for SIGTERM and SIGINT and exposes stopDaemon() and setTermination-style controls for programmatic exit. That lets a worker finish its current iteration before terminating when Supervisor or Docker sends a stop signal. SIGKILL cannot be caught, so an OOM kill or a stop that exceeds the grace period will still terminate abruptly. Graceful shutdown is best-effort, not guaranteed.
- Can I use DaemonizableCommand with an existing Laravel Artisan command?
- You cannot extend both DaemonizableCommand and Illuminate\Console\Command because PHP has single inheritance and the two classes are siblings under Symfony Command. Your options are to rewrite the command on top of DaemonizableCommand and lose Laravel's command ergonomics, or to use the package's trait on an existing command if it fits your version. For most teams a short in-house loop with pcntl_async_signals(true) and Command::trap() is simpler.
- Does wrep/daemonizable-command work on Windows?
- No. The package's signal handling requires the pcntl extension, which is not supported on Windows. Windows developers can still run the rest of the Laravel application, but the daemon command itself must run on Linux or macOS. If Windows CI is part of your pipeline, those jobs cannot exercise the daemon.
- How do I avoid memory leaks and stale state in long-running Artisan commands?
- The package solves the loop but not the operations around it. It offers no max-time, max-jobs, or memory-based recycling, so RSS drift, MySQL wait_timeout disconnects, Redis idle drops, and stale Eloquent or container state are your responsibility. Plan periodic restarts, health checks, and idempotent jobs, and remember the package provides no locking or partitioning if more than one process runs.
- Is wrep/daemonizable-command still maintained and safe for production?
- Adoption signals are modest: around 226 stars, a low overall score, and a narrow opportunity score because queue:work, schedule:work, Horizon, and Octane already cover the daemon niche. It is a single-maintainer dependency wrapping a fairly small loop. For production, prefer Laravel's native workers or a 30 to 50 line in-house command loop that keeps all Laravel helpers.
- What are the alternatives to wrep/daemonizable-command for signal handling in Laravel?
- Laravel 10 and later expose Command::trap() and untrap() through its signals trait, and pcntl_async_signals(true) avoids the declare(ticks=1) footgun the package relies on. A short in-house loop of roughly 30 to 50 lines keeps info(), option(), argument(), confirm(), table(), and progressBar() while handling SIGTERM and SIGINT. That is usually a better trade than forking your base class for a small amount of code.
Weaver
How can I help you explore Laravel packages today?