Cron Bundle Laravel Package

Getting Started

First, note the mismatch: sbk/cron-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no config/cron.php, no artisan integration. If you're running Laravel day-to-day, you will not composer require this into an app — you'd only touch it if you're maintaining a legacy Symfony 2/3/4 service that already depends on it. Given it is archived and has zero dependents, treat it as a reference implementation rather than something to adopt.

If you are working in an old Symfony app that uses it:

1. Register the bundle in AppKernel.php (or bundles.php on Symfony 4): new Sbk\CronBundle\SbkCronBundle().
2. Look first at DependencyInjection/Configuration.php in the repo to see the exact config tree — that file is the contract for how jobs are declared.
3. Declare one job in config.yml:

sbk_cron:
    jobs:
        cleanup_logs:
            command: "app:clean-logs"
            expression: "0 3 * * *"
            enabled: true

4. Confirm the bundle registered a console command (bin/console list — look for an sbk:cron:* namespace) and a system crontab entry that calls it every minute. The bundle's model is a dispatcher: the OS fires one bin/console sbk:cron:run each minute, and the bundle decides which of your configured jobs are due.

The first realistic use case is replacing a pile of raw * * * * * php bin/console app:foo crontab lines with a single managed entry plus YAML-declared jobs — deployment-friendly because job schedules live in version control alongside the app.

Implementation Patterns

One dispatcher, many jobs. The idiomatic pattern is a single system cron line (* * * * * cd /var/www && bin/console sbk:cron:run) and all schedule logic in YAML. This gives you atomic deploys of schedule changes: ship code, schedule updates with it, no server access needed to edit crontab.

Thin commands, fat services. The bundle only shells out to your Symfony console commands. Keep the command as a one-line adapter ($this->getContainer()->get(FooService::class)->run()) so the job remains testable and the cron config stays declarative. Never put business logic in the command.

Environment-scoped job definitions. Split config into config_cron.yml / config_cron_dev.yml and import conditionally, or gate jobs with the enabled flag keyed off an env var. Typical pattern:

sbk_cron:
    jobs:
        billing_sync:
            command: "app:billing-sync"
            expression: "*/15 * * * *"
            enabled: "%billing_sync_enabled%"

Overlap protection is your job, not the bundle's. Because the dispatcher is stateless per-minute, a long-running command will be re-launched on the next tick. Standard workaround: wrap the job in a lockfile check, or use Symfony's Lock component inside the command:

$lock = $factory->createLock('billing-sync', 3600);
if (!$lock->acquire()) { return; }
try { /* work */ } finally { $lock->release(); }

Logging integration. Pipe stdout/stderr from the dispatcher into your existing log shipper, and make each command emit structured start/finish lines. With no dependents and no maintenance, you cannot rely on the bundle for observability — you must supply it at the command and cron level.

Testing the schedule logic. Don't test through the dispatcher. Test the cron expression evaluation in isolation (the underlying cron-expression library) and test the command independently with CommandTester. This decouples you from a dead bundle.

Gotchas and Tips

It's archived — plan an exit. No security patches, no PHP 8.1+ guarantee, and PSR/ Symfony deprecations will accumulate. Before adopting the pattern, budget a migration path: either a maintained alternative (cron/cron-bundle-style packages, or Symfony's own symfony/scheduler on 6.3+) or a ~50-line custom command that loops over config and evaluates expressions. The concept is trivial to reimplement; the bundle adds little beyond YAML parsing and a due-check.

The version constraints pin you to old Symfony. An archived bundle from this era is almost certainly constrained to Symfony 2/3/4 branch lines. Check composer.json before require — a stale constraint will fight your composer update and can force you to pin transitive packages.

No timezone clarity. Most bundles of this vintage evaluate expressions against the server's PHP timezone. If your app sets date_default_timezone_set() or php.ini's date.timezone, schedules silently shift. Confirm whether the bundle respects a configured timezone key, and if not, normalize the server TZ explicitly.

"Missed" ticks are dropped. A pure per-minute dispatcher does not backfill. If the host is down from 03:00–05:00, the 03:00 job never runs — no catch-up. For anything that must not be skipped (billing, digests), you need a "last run" watermark stored in the DB and a catch-up branch, not just cron expressions.

Config is cached. In Symfony, config is compiled into the container cache, so editing the YAML requires bin/console cache:clear (or a deploy that warms the cache). A newly added job that "doesn't run" is very often a stale cache, not a schedule bug. Always clear before debugging.

Overlap and drift. Sub-minute-jitter, execution longer than the interval, and concurrent deploys during a tick all interact badly. Add locks (see above), and prefer jobs whose intervals are much larger than their expected runtime.

Debugging checklist when a job doesn't fire: (1) cache cleared? (2) expression valid five-field cron (the parser rejects six-field @-style)? (3) enabled resolving true for this env? (4) command name exactly matches bin/console list output? (5) the dispatch cron line actually in the crontab (crontab -l as the correct user — a common failure is cron as root vs www-data)? (6) command exits 0 when run manually?

Extension point to lean on. If you do keep the bundle, the sane extension point is not the bundle's internals but the console command layer — keep commands tiny and idempotent so the dead dependency is a thin, easily-removable shell. That's the difference between a two-hour migration and a two-week one when this inevitably gets ripped out.