Daemons Bundle Laravel Package

Technical Evaluation

Architecture fit — weak, and the framing is wrong. Despite being listed in a Laravel/PHP evaluation context, edo/daemons-bundle is a Symfony bundle. Laravel does not have a bundle system: there is no registerBundles(), no Bundle base class consumption, no DI Extension/CompilerPass lifecycle. Laravel's service-provider model is a different abstraction that happens to sit on top of symfony/console for the command layer only. The command-layer overlap is real — Illuminate\Console\Command extends Symfony\Component\Console\Command\Command — but the package's value is in its bootstrap and process-management code, which is precisely the part that does not port. Net: we cannot composer require this into a Laravel app and expect it to function.

Integration feasibility — low as a dependency, moderate as a reference. Realistically the only viable path is source-level extraction: read the daemonization implementation and reimplement it as an artisan command or a process supervisor config. That demotes the package from "dependency" to "design input," and we should value it accordingly.

Technical risk — high. Zero stars, zero dependents, score 0, and an empty stars field together indicate no adoption signal and likely no maintenance. Open questions that materially change the risk profile:

• Does it use pcntl_fork + posix_setsid, or does it shell out to nohup/supervisord? The former means we inherit fork/zombie-reaping responsibilities; the latter means the package is a thin config wrapper we should replace outright.
• What are the composer.json constraints? If it pins symfony/* to ^3/^4, Composer will refuse to install alongside Laravel 10/11 (PHP 8.1+, Symfony 6/7 components). This is a hard blocker, not a soft one.
• Signal handling: what happens on SIGTERM? Is there graceful shutdown, or does the process die mid-job?
• PID file handling, log file handles, and restart-on-crash semantics — or is the "daemon" a while (true) { sleep(); } loop?
• License, last commit date, open issue count, and whether the maintainer responds at all.
• Does it require the full Symfony HTTP kernel even for console-only use? If so, the dependency footprint is disproportionate.

Recommendation: do not adopt. Treat as a reading exercise at most.

Integration Approach

Stack fit. There is no direct fit. A Symfony bundle assumes a Kernel, a bundle registry, and a container compilation pass. Laravel's Application/ServiceProvider bootstrap is structurally different. Any attempt to install it would require either running a Symfony kernel inside Laravel (absurd overhead) or stripping the bundle scaffolding and keeping only the process loop.

Migration path. Two options, in order of preference:

1. Replace, don't port. The problem this package claims to solve — long-running background work — is already solved idiomatically in Laravel: php artisan queue:work under Supervisor or systemd, Horizon for Redis-backed queues, or the scheduler for cron-shaped work. These have restart semantics, SIGTERM handling, memory-limit recycling (--max-jobs, --max-time), and observability built in. Choosing this path means the package never enters the tree.
2. Port the loop. If there is a genuine requirement for a bespoke long-running artisan command (e.g., a socket listener), extract the daemon logic into a first-party command and own it. Budget for this as a small internal library, not a dependency.

Compatibility. Composer resolution is the first gate. Laravel 10/11 with Symfony 6/7 components will almost certainly conflict with an older bundle's pins. Validate this with a dry-run composer require --dry-run in a scratch branch before investing any further analysis time. Also confirm PHP version support — a package written for PHP 7.x may use syntax or pcntl semantics that behave differently on 8.x.

Sequencing.

1. Timeboxed spike (half day): read composer.json, the bundle class, and the daemon implementation. Answer the key questions above.
2. If the implementation contains a reusable idea, write a one-page internal note; do not vendor the code.
3. Prototype the equivalent as an artisan command or — preferably — a Supervisor/Horizon configuration in a non-production environment.
4. Formalize the decision as an ADR: "background processing via Supervisor + queue workers," with this package recorded as evaluated-and-rejected and the reasons stated.
5. Only if the spike surfaces something genuinely novel should a port be scoped, and then as an owned internal component with tests and an owner.

Operational Impact

Maintenance. Effectively 100% ours from day one. An unmaintained dependency with no dependents means no upstream fixes, no security advisories we'd be notified about, and no community issue tracker to search when it breaks. In a production stack, that is a liability with negative expected value — we take on the code without the benefit of shared maintenance.

Support. None. Zero dependents implies no Stack Overflow corpus, no blog posts, no one else's incident reports to learn from. Every failure is a first-principles debugging exercise for whoever is on call.

Scaling. Daemonized PHP processes scale poorly by nature. They are host-affine: one process tree per machine, PID files that don't survive container restarts, and no clean story for horizontal scale-out. In a container-orchestrated environment the whole model fights the platform — Kubernetes wants foreground processes with proper signal handling, not self-daemonizing children. Supervisor, systemd, or the orchestrator's restart policy are the correct layers for this concern, and they give us metrics, backoff, and log capture for free.

Failure modes. The ones to expect:

• Silent death. The process exits and nothing restarts it. Supervisor solves this; a hand-rolled daemon usually does not.
• Orphaned and zombie processes. pcntl_fork without correct pcntl_waitpid reaping leaks PIDs until the box is exhausted.
• Stale PID files. After a crash or container restart the PID file points at a dead or recycled PID, and a naive stop command kills an unrelated process.
• Memory growth. PHP is not designed for unbounded process lifetimes; long-running workers accumulate memory. No built-in recycling means OOM kills on a schedule we don't control.
• Signal mishandling on deploy. If SIGTERM isn't trapped, in-flight work is truncated. This is the classic cause of "job ran twice" or "job vanished" incidents.
• Log handle exhaustion. Reopening or failing to rotate log file descriptors in a long-lived process.
• Composer/autoload drift. Because we vendored or forked, upgrades to Laravel or Symfony Console won't be validated against this code by anyone but us.

Ramp-up. The code volume is likely small, so comprehension cost is low. The operational learning cost is the opposite — the team must become fluent in process supervision, signal handling, and PID hygiene to run this safely, which is knowledge we'd otherwise rent from Supervisor or the platform. Budget for an on-call runbook and a documented restart procedure if this ever reaches production.

Bottom line. The package solves a real problem for a framework we are not using, with no adoption or maintenance signal behind it. The TPM call is to reject it, standardize on Laravel's native queue + Supervisor/Horizon model, and record the evaluation so the question doesn't get re-litigated.