Linux β€’ Background Workers & Daemons

How to Run Background Workers (Celery, BullMQ, Sidekiq) with Systemd

Background workers consuming Redis, RabbitMQ, or SQS queues (like Celery, BullMQ, Sidekiq, or Laravel Queue) require aggressive auto-recovery. This service provides memory limits, restart backoff, and graceful termination.

/etc/systemd/system/queue-worker.service
[Unit]
Description=Asynchronous Background Queue Consumer
After=network.target redis.service
Requires=redis.service

[Service]
Type=simple
User=worker
Group=worker
WorkingDirectory=/var/www/app
ExecStart=/usr/bin/node worker.js
Restart=always
RestartSec=10
TimeoutStopSec=60
KillMode=mixed
KillSignal=SIGTERM
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
Customize:
User:
WorkingDir:
ExecStart:

Systemctl Lifecycle & Journalctl Monitoring

sudo systemctl daemon-reloadUpdate systemd configurations
sudo systemctl enable --now queue-workerStart worker daemon
sudo systemctl stop queue-workerGracefully stop worker (waits TimeoutStopSec for in-flight jobs to finish)

Linux & Systemd Production Best Practices

  • `TimeoutStopSec=60` ensures that when you restart or stop the service, systemd gives the worker 60 seconds to finish processing in-flight jobs before sending SIGKILL.
  • Use `Requires=redis.service` so the worker will not attempt to start if Redis is down.

Frequently Asked Questions About Background Queue Worker Service

Frequently Asked Questions

Frequently Asked Questions

Everything you need to know regarding specifications, syntax, and security best practices.

It sends SIGTERM to the main process, waits for the stop timeout, and if child worker processes are still lingering, forcefully kills them with SIGKILL.