Skip to content
VDS · ایپس اور بوٹس

شیڈول شدہ ٹاسکس: cron اور systemd ٹائمرز

شیڈول شدہ ٹاسکس کیسے چلائیں، کوئی ٹاسک دستی طور پر کیوں چلتا ہے مگر cron میں خاموش رہتا ہے، اور systemd ٹائمرز پر کب منتقل ہونا چاہیے۔

اپ ڈیٹ 23 اگست، 2026

بیک اپ، سرٹیفکیٹ کی تجدید، عارضی فائلوں کی صفائی، رات کی رپورٹس — یہ سب شیڈول شدہ ٹاسکس ہیں۔ Linux پر آپ انہیں دو طریقوں سے حل کرتے ہیں: کلاسک cron اور systemd timers۔

Cron: فوری آغاز

آپ کسی صارف کا شیڈول اس طرح ایڈٹ کرتے ہیں:

crontab -e
crontab -l

لائن کی ساخت پانچ فیلڈز اور ایک کمانڈ پر مشتمل ہوتی ہے:

# min  hour  day  month  day-of-week  command
  0    4    *     *      *            /usr/local/bin/backup.sh
  */15 *    *     *      *            /usr/local/bin/check.sh
  30   3    *     *      0            /usr/bin/systemctl restart myapp

مفید شارٹ کٹس: @daily، @hourly، @reboot۔ یہ جانچنے کے لیے کہ جابز چلی ہیں یا نہیں:

grep CRON /var/log/syslog | tail -30
journalctl -u cron --since "1 hour ago"

اسکرپٹ ہاتھ سے کیوں چلتی ہے مگر cron میں نہیں

یہ سب سے عام مسئلہ ہے، اور اس کی وجہ تقریباً ہمیشہ تین میں سے ایک ہوتی ہے۔

مختلف ماحول۔ Cron کا PATH بہت محدود ہوتا ہے اور .bashrc کے آپ کے متغیرات وہاں موجود نہیں ہوتے۔ پروگرامز کے مکمل پاتھ استعمال کریں اور متغیرات کو اسکرپٹ کے آغاز میں یا crontab میں واضح طور پر سیٹ کریں:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

مختلف ڈائریکٹری۔ جاب صارف کی ہوم ڈائریکٹری میں شروع ہوتی ہے، اس لیے نسبتاً پاتھ کسی اور جگہ کی طرف اشارہ کرتے ہیں۔ ہمیشہ مطلق پاتھ استعمال کریں۔

آؤٹ پٹ کہیں نہیں جاتا۔ کوئی خرابی آئی، مگر کسی نے دیکھی نہیں۔ لاگ لکھیں:

0 4 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

دو مزید چھوٹی باتیں: cron لائن میں % کریکٹر کو \% کے طور پر escape کرنا ضروری ہے، اور crontab فائل کا اختتام نئی لائن پر ہونا چاہیے — ورنہ آخری جاب نظر انداز ہو جاتی ہے۔

آپ کو باہر سے تصدیق کرنی ہوگی کہ جاب چلی ہے۔ خاموش cron بالکل کامیاب cron جیسی نظر آتی ہے۔ Uptime Kuma میں پش چیک سیٹ اپ کریں: اسکرپٹ آخر میں کسی ایڈریس کو پنگ کرتی ہے، اور اگر ایک دن تک پنگ نہ آئے تو آپ کو الرٹ مل جاتا ہے۔

systemd timers

جب کوئی ٹاسک ایک کمانڈ سے زیادہ پیچیدہ ہو، تو timer زیادہ آسان ہوتا ہے: اس میں journal، dependencies، وسائل کی حدود، اور ایک وقت میں دو کاپیاں چلنے سے تحفظ موجود ہوتا ہے۔

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
# /etc/systemd/system/backup.timer
[Unit]
Description=Run nightly backup

[Timer]
OnCalendar=*-*-* 04:00:00
Persistent=true
RandomizedDelaySec=15m

[Install]
WantedBy=timers.target
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers
journalctl -u backup.service -n 50

Persistent=true مشین بند ہونے کی صورت میں چھوٹی ہوئی رن کی تلافی کر لیتا ہے — cron یہ نہیں کر سکتا۔ RandomizedDelaySec لوڈ کو پھیلا دیتا ہے تاکہ درجن بھر ٹاسکس ایک ہی سیکنڈ میں شروع نہ ہوں۔

کن باتوں کا خیال رکھیں

  • مشین کا وقت بطور ڈیفالٹ UTC ہوتا ہے۔ ”صبح 4 بجے“ مقرر کرنے سے پہلے timedatectl چیک کریں۔
  • بھاری ٹاسکس (آرکائیوز، بیک اپ کی تصدیق) ڈسک سے جڑے ہوتے ہیں۔ ڈسک کی رفتار دیکھیں اور انہیں رات کے لیے شیڈول کریں۔
  • ہر پانچ منٹ میں چلنے والا طویل ٹاسک خود سے اوورلیپ ہو جائے گا۔ systemd میں Type=oneshot مدد کرتا ہے؛ cron میں flock کے ذریعے لاک استعمال کریں:
*/5 * * * * /usr/bin/flock -n /tmp/job.lock /usr/local/bin/job.sh