Daemon Bundle Laravel Package

Product Decisions This Supports

• Background processing architecture (build vs. buy). This package is a data point, not a dependency. It represents the "hand-rolled daemon" option for long-running PHP workers — the pattern of forking a process, writing a PID file, trapping SIGTERM, and looping. Evaluating it forces the real decision: do we own process supervision in application code, or delegate to supervisor/systemd plus a queue abstraction?
• Framework strategy. The artifact is a Symfony2 bundle. For a Laravel roadmap this is a compatibility non-starter: no service provider, no Laravel container bindings, and no support for anything past PHP 5.x-era Symfony. It is useful mainly as evidence that "daemon bundle" as a category was superseded by queue workers + a process manager.
• Roadmap de-risking. Zero stars, zero dependents, and no maintenance signal mean the package carries unquantifiable security and longevity risk. Any roadmap item that depends on it should be re-scoped around Laravel Queues, Horizon, or Symfony Messenger before commitment.
• Prior art for a thin internal worker wrapper. If we ever build a first-party long-running worker base class, this repo's PID-file and signal-handling logic is worth 30 minutes of reading as a checklist of failure modes (orphaned PID files, double-start, unclean shutdown), not as code to vendor.
• Use case fit. The problem space is legitimate — long-lived consumers for queue backends, socket listeners, scheduled pollers. The package is not the right vehicle for solving it.

When to Consider This Package

Adopt only if all of the following hold:

• You are maintaining a legacy Symfony2 (2.3–2.8) application on PHP 5.x that cannot be upgraded.
• You need in-process daemon lifecycle management (PID file, signals, restart) and have no process supervisor available in the deployment environment.
• You have an engineer who will fork and own the code, including security review, because upstream will not.
• The daemon is non-critical and internal-facing.

Look elsewhere — decisively — when any of these are true:

• The target application is Laravel or any Symfony ≥ 3.4. There is no supported integration path.
• You need PHP 7/8 support, typed code, or modern PSR compliance.
• You require a maintained dependency with a security response path. Zero stars and zero dependents indicate no community backstop and no evidence of production use.
• You need observability, retries, backoff, or horizontal scaling — all absent from a bare daemon bundle.
• Your deployment already has systemd, Kubernetes, or Supervisor. Those solve process lifecycle better and outside the application.

Recommended substitute: supervisor (or systemd unit files) for lifecycle, plus Laravel Queues/Horizon or Symfony Messenger for the work itself. This is the standard, and it removes daemon handling from application code entirely.

How to Pitch It (Stakeholders)

To executives: A team member may surface this package as a shortcut for running background jobs. It should not be adopted. It is an unmaintained Symfony2-era component with no users and no maintainer, built for a framework generation we no longer run. Taking it on would mean owning a security-sensitive, always-running process with no upgrade path — a standing liability with no offsetting cost saving. The capability it nominally provides is already covered by our process supervisor and queue tooling at effectively zero marginal cost.

To engineering: This solves a real problem — supervised long-running PHP workers — but it solves it for Symfony2 on PHP 5.x, and it does so with roughly a hundred lines of PID-file and signal handling. We are not adopting it. We are standardizing on Supervisor for process lifecycle and Laravel Queues/Horizon (or Symfony Messenger, if the affected service is Symfony) for the work. If you want the PID-file logic as reference for an internal worker base class, read it, don't depend on it. If you believe there is a gap our current stack does not cover, bring the specific failure mode — that is a worthwhile conversation; this package is not the answer to it.