Weave Code
Daemon Bundle Laravel Package
medicorenl/daemon-bundle
Daemon Bundle is a PHP package for building and managing long-running daemon processes. It offers a base daemon class, signal handling, PID file management, graceful shutdown, and logging to keep background workers reliable and easy to operate.
Symfony2 daemon bundle.
Frequently asked questions about Daemon Bundle
- Can I use medicorenl/daemon-bundle in a Laravel application?
- No. It is a Symfony2 bundle wired through Kernel::registerBundles() and the Symfony DI container, a loading path Laravel never calls. Its Symfony 2.x and PHP 5.x composer constraints also conflict with any modern Laravel application. Composer will fail resolution outright, and --ignore-platform-reqs only defers the failure to runtime.
- Is medicorenl/daemon-bundle a Laravel package or a Symfony bundle?
- It is a Symfony2 bundle, not a Laravel package. Laravel packages load via ServiceProvider classes registered in config/app.php or through Composer package discovery, while a Bundle subclass plus Extension and CompilerPass has no equivalent in Laravel. Sharing Symfony Console and Process components underneath does not bridge that gap.
- Why does composer require medicorenl/daemon-bundle fail on modern Laravel and PHP 8?
- The bundle targets Symfony 2.x, which reached end of life in November 2018, and almost certainly declares a PHP 5.x constraint. Modern Laravel applications pin Symfony 6 or 7 components and run PHP 8.1+, so Composer reports a conflict before any code is autoloaded. Forcing the install with --ignore-platform-reqs moves the error to runtime, where the expected Symfony kernel and container symbols do not exist.
- Which Symfony and PHP versions does DaemonBundle support?
- As a Symfony2 bundle it targets the Symfony 2.x line, which has been end of life since 2.8 in November 2018. Its PHP constraint is almost certainly in the 5.x range. Neither is compatible with a supported Laravel release or PHP 8.x.
- What is the Laravel-native alternative to this daemon bundle?
- For queue workers use Laravel Horizon or php artisan queue:work under Supervisor or systemd. For custom background loops, write an artisan command and supervise it with a systemd unit or a Supervisor program. The Log facade, Cache::lock, and the queue worker's graceful shutdown hooks already cover the logging, locking, and shutdown features this bundle exists to provide.
- Does medicorenl/daemon-bundle handle forking, signals, and PID files itself?
- The package description claims a base daemon class, signal handling, PID file management, graceful shutdown, and logging. What is unverified is whether it implements the fork and signal logic with pcntl directly or wraps an existing library. Read the source before trusting any of it, since there are no tests, stars, or dependent projects vouching for the behavior.
- Is medicorenl/daemon-bundle still maintained and safe to depend on?
- Treat it as abandoned. It has zero stars, zero dependents, and no visible maintenance activity, so there is no user base to surface bugs and no security response capability. Combined with an end-of-life framework dependency in a vendor namespace, that is a supply-chain risk you would own entirely.
- How do I implement graceful shutdown for a long-running Laravel worker?
- Inside a custom artisan command, handle SIGTERM with pcntl_signal and pcntl_async_signals, or rely on the queue worker's built-in graceful shutdown via --timeout and the stopping and stopped hooks, or Horizon's terminate handling. Let Supervisor or systemd send the signal and enforce a stop timeout. Finish the in-flight job, release locks, flush logs, and exit cleanly instead of calling exit mid-task.
- How do I prevent duplicate daemon processes in Laravel, PID file or cache lock?
- Prefer Cache::lock with a named lock and a TTL over a PID file, because it works across containers and hosts where a filesystem PID file does not. Also configure Supervisor with numprocs=1 or a single systemd unit so only one instance can run. A PID file is only a fallback and is unreliable after a hard kill or container restart.
- Should I extract the daemon code into a Laravel package instead of installing it?
- Extraction is the only sensible path if you want this behavior in Laravel: read the source, harvest the fork strategy, signal set, PID handling, and logging hooks, then reimplement them as a first-party artisan command. In most cases you need to reimplement nothing, because Supervisor, systemd, Horizon, and queue:work already cover process supervision and graceful shutdown. Confirm the LICENSE and upstream provenance before copying any code.
Weaver
How can I help you explore Laravel packages today?