ما هي المهام المجدولة (Cron Jobs) وكيف تستخدمها في استضافتك؟

الكثير مما يبقي موقعك حيًّا لا يحدث بضغطة زر: النسخة الاحتياطية التي تُؤخذ فجرًا، رسائل السلّة المتروكة، تقرير المبيعات الذي يصلك السابعة صباحًا، حذف الملفات المؤقتة التي تلتهم مساحتك. كل هذه مهام متكرّرة بقواعد ثابتة، وهي بالضبط ما صُمّم له cron قبل أربعة عقود ولا يزال يعمل به كل خادم لينكس حتى اليوم. هذا الدليل يشرح الصيغة حرفًا حرفًا، ثم ينتقل إلى الإنشاء العملي من لوحة الاستضافة، فوصفات جاهزة للنسخ واللصق، وينتهي بأكثر ما يُفشِل المهام وكيف تشخّصه بنفسك.

ما هي المهمة المجدولة ولماذا تحتاجها أصلًا؟

على كل خادم لينكس تعمل خدمة صغيرة في الخلفية اسمها cron daemon (أو crond). وظيفتها الوحيدة أن تستيقظ كل دقيقة، تقرأ جداول المواعيد المخزّنة على الخادم، وتسأل: هل حان وقت أي أمر الآن؟ إن كان الجواب نعم نفّذته، وإلّا نامت دقيقة أخرى. هذا كل شيء — فكرة بسيطة إلى حدّ السذاجة، لكنها العمود الفقري لكل أتمتة تحدث على الخوادم منذ الثمانينيات.

الجدول الذي تقرأه هذه الخدمة يُسمّى crontab (اختصار cron table)، وهو ملف نصّي عادي، كل سطر فيه يمثّل مهمة واحدة: موعد + أمر. والمهمة الواحدة تُسمّى cron job، وهي ما تراه في لوحة الاستضافة تحت مسمّى «المهام المجدولة» أو «Cron Jobs».

الفارق الجوهري بين cron وبين أي أتمتة تعتمد على المتصفّح هو الاستقلال عن الزائر. صفحة الموقع لا تُنفَّذ إلّا حين يطلبها أحد؛ أما المهمة المجدولة فتعمل والخادم صامت تمامًا في الثالثة فجرًا. هذا الفارق ليس تفصيلًا تقنيًا، بل هو ما يجعل النسخ الاحتياطي المجدول موثوقًا والتقارير الدورية تصل في موعدها.

هذا الاستقلال هو أيضًا ما يجعل cron الطبقة الأساس التي تُبنى فوقها أدوات الأتمتة الأحدث. إذا كنت تفكّر في نطاق أوسع من مجرد أمر على خادم واحد، فمقالنا عن أتمتة المهام المتكرّرة في عملك يرسم الصورة الكاملة لاختيار ما يستحق الأتمتة أصلًا؛ لكن حتى تلك الأدوات تعتمد في جوهرها على مُشغِّل زمني لا يختلف كثيرًا عمّا سنشرحه هنا.

ويجدر التنبيه من البداية إلى أن cron ليس بديلًا عن التطبيق بل ذراعه الزمنية: المهمة المجدولة لا «تفهم» موقعك ولا تعرف ما هي السلّة المتروكة، هي فقط تشغّل أمرًا في موعده. المنطق كلّه يبقى في السكربت أو الإضافة التي تستدعيها. ومن هنا القاعدة العملية التي توفّر أغلب المتاعب: اكتب سكربتًا يعمل صحيحًا حين تشغّله بيدك أولًا، تحقّق من مخرجاته، ثم جدوِله — لا العكس أبدًا.

كيف تقرأ صيغة الجدولة الخمسية؟

هنا يتعثّر أغلب المبتدئين، مع أن القاعدة أبسط ممّا تبدو. سطر cron يبدأ بخمسة حقول مفصولة بمسافات، ثم يأتي الأمر المطلوب تنفيذه. الحقول الخمسة تُقرأ من اليسار إلى اليمين بترتيب ثابت لا يتغيّر: تبدأ بأصغر وحدة زمنية (الدقيقة) وتنتهي بأكبرها (يوم الأسبوع).

القاعدة الذهنية التي تُثبّت الترتيب: دقيقة، ساعة، يوم، شهر، أسبوع. وكل حقل يقبل إمّا قيمة محدّدة، أو نجمة * تعني «كل القيم الممكنة في هذا الحقل».

انتبه لتفصيلين يوقعان كثيرين. الأول أن الساعة بنظام 24، فلا وجود لصباح ومساء: الثامنة مساءً هي 20 لا 8. الثاني أن حقل يوم الأسبوع يبدأ من الأحد بالرقم 0، وأن الرقم 7 مقبول أيضًا ويعني الأحد نفسه — وهذا تسامح مقصود في تنفيذات cron الشائعة لأن بعض الأنظمة تعدّ الأسبوع من الاثنين.

معظم الخوادم تقبل كذلك الأسماء المختصرة بالإنجليزية بدل الأرقام: JAN حتى DEC في حقل الشهر، وSUN حتى SAT في حقل يوم الأسبوع. فـ0 3 * * SUN مطابقة تمامًا لـ0 3 * * 0. الأسماء أوضح للقراءة، لكن الأرقام أضمن للعمل على أي خادم، والأهم أن الأسماء لا تُقبَل داخل مدى بخطوة في بعض التنفيذات، فالتزم بالأرقام في التعبيرات المركّبة.

الرموز الأربعة التي تحتاجها فعلًا

بعد النجمة، تكفيك أربعة رموز لبناء أي جدول تقريبًا. لا تحتاج إلى حفظ صيغ جاهزة إن فهمت هذه الأربعة، لأنها تتركّب مع بعضها بحرّية.

الخطوة / هي الأكثر إساءة فهم. */15 في حقل الدقيقة لا تعني «بعد 15 دقيقة من الآن»، بل «عند كل دقيقة تقبل القسمة على 15» — أي الدقائق 0 و15 و30 و45 من كل ساعة، بمواعيد ثابتة لا تتعلّق بلحظة إنشاء المهمة. وهي مكافئة تمامًا لكتابة 0-59/15.

ومن هنا تأتي حالة حافة تستحق الانتباه: الخطوة التي لا تقسم الستّين قسمة صحيحة تُحدث فجوة عند رأس الساعة. */7 في حقل الدقيقة تشغّل المهمة عند الدقائق 0، 7، 14، 21، 28، 35، 42، 49، 56 — ثم تعود الساعة إلى الصفر، فتكون المسافة بين تشغيلَي 56 و00 أربع دقائق فقط بدل سبع. الأمر نفسه ينطبق على */45 وغيرها. إن كان انتظام الفاصل مهمًّا لك، التزم بقواسم الستّين: 1، 2، 3، 4، 5، 6، 10، 12، 15، 20، 30.

الرمز , يحلّ مشكلة لا يحلّها المدى: المواعيد غير المتجاورة. لا يمكنك التعبير عن «الثالثة فجرًا والثالثة عصرًا» بمدى، لكن 0 3,15 * * * تفعلها في حرفين. ويمكنك مزج الرموز في الحقل الواحد: 0 0,6-9,18 * * * تعني منتصف الليل، ثم كل ساعة من السادسة إلى التاسعة صباحًا، ثم السادسة مساءً.

أمثلة صيغ شائعة ومعناها بالعربي

هذا الجدول مرجع سريع تعود إليه كلما احتجت صيغة. تحقّق من كل صيغة بقراءتها حقلًا حقلًا قبل حفظها؛ خطأ في حقل واحد يحوّل مهمة يومية إلى مهمة تعمل ستّين مرّة في الساعة.

لاحظ السطر الأخير: لا توجد طريقة مباشرة للتعبير عن «آخر يوم في الشهر» لأن الشهور تختلف أطوالها. الحيلة المعتادة أن تجدول المهمة في الأيام من 28 إلى 31، ثم تضع في بداية السكربت فحصًا يتحقّق إن كان الغد أول الشهر فيتابع، وإلّا خرج فورًا.

كيف تنشئ مهمة مجدولة من لوحة الاستضافة؟

على الاستضافة المشتركة لن تحتاج إلى طرفية أصلًا؛ لوحة التحكّم توفّر نموذجًا بسيطًا. الخطوات على cPanel — وهي متشابهة في DirectAdmin وCyberPanel وغيرها — كالتالي.

ادخل إلى لوحتك، وابحث في مربّع البحث العلوي عن Cron Jobs؛ ستجدها عادةً ضمن قسم «Advanced» أو «المتقدّم». إن كنت جديدًا على اللوحة فمقالنا شرح لوحة cPanel للمبتدئين يعرّفك بأقسامها كلها ويوفّر عليك التيه بين الأيقونات.

أول ما تراه في الصفحة حقل Cron Email: عنوان بريد تُرسَل إليه مخرجات كل مهمة. اتركه فارغًا أو ضع بريدًا مخصّصًا للسجلّات، لا بريدك الرئيسي — سنعود لهذه النقطة بعد قليل لأنها أكثر ما يزعج أصحاب المواقع.

ثم تجد قائمة منسدلة باسم Common Settings تحتوي على مواعيد جاهزة (كل خمس دقائق، كل ساعة، يوميًا، أسبوعيًا…). اختيار أحدها يملأ الحقول الخمسة نيابةً عنك، وهو أسرع طريق للمبتدئ. وإن أردت موعدًا غير موجود في القائمة، املأ الحقول يدويًا واحدًا واحدًا — وهي مرتّبة على الشاشة بالترتيب نفسه الذي شرحناه: Minute، Hour، Day، Month، Weekday.

الحقل الأخير والأهم هو Command: الأمر الفعلي الذي سيُنفَّذ. اكتبه كاملًا بمسارات مطلقة، ثم اضغط «Add New Cron Job». ستظهر المهمة في جدول أسفل الصفحة مع خيارَي تعديل وحذف.

قبل أن تضغط الإضافة، تحقّق من ثلاثة أشياء: أن المسار الذي كتبته موجود فعلًا، أن الملف قابل للتنفيذ إن كان سكربتًا، وأن الفاصل الزمني الذي اخترته مسموح في خطتك. فهذه النقطة الأخيرة تحديدًا تختلف بين الخطط.

هذه الحدود ليست تعسّفًا من المضيف بل حماية للخادم المشترك: مهمة ثقيلة تعمل كل دقيقة على مئة حساب تعني مئة عملية متزامنة. إن لم تكن متأكّدًا من طبيعة الخطة المشتركة وحدودها، فشرحنا لـالاستضافة المشتركة وكيف تعمل يوضّح لماذا تُفرَض هذه القيود ومتى تصبح ضيّقة عليك. ولفهم أثر المهام على استهلاكك، راجع موارد الخادم وكيف تُقاس.

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

ماذا تضع في حقل الأمر؟

هذا موضع أغلب الأخطاء. الأمر الذي يعمل في طرفيتك قد يفشل صامتًا في cron، لأن بيئة cron ليست بيئتك: لا تقرأ ملف .bashrc، ومتغيّر PATH فيها مختصر جدًا (غالبًا /usr/bin:/bin فقط)، ومجلّد العمل هو مجلّد المستخدم الرئيسي لا مجلّد السكربت. النتيجة أن php script.php تعمل عندك وتفشل في cron ببساطة لأن cron لا يعرف أين php.

القاعدة إذًا: مسارات مطلقة لكل شيء — للمفسّر وللسكربت وللملفات التي يكتب فيها.

تشغيل ملف PHP

هذه أشيع حالة على الإطلاق. الصيغة:

0 3 * * * /usr/local/bin/php -q /home/user/public_html/scripts/task.php

مسار PHP يختلف بين المضيفين، وهذا سبب فشل شائع جدًا. اعرف المسار الصحيح على خادمك بأمر واحد عبر SSH:

which php
# أو للبحث عن كل النسخ المتاحة
ls -1 /usr/local/bin/ | grep -i php

الراية -q تعني «الوضع الصامت» وتمنع طباعة ترويسات HTTP في المخرجات. تحتاجها إذا كان المضيف يوجّه أمر php إلى الثنائي php-cgi بدل نسخة سطر الأوامر؛ ومن دونها ستجد رسائل بريد المهمة مليئة بترويسات Content-type عديمة الفائدة. إضافتها آمنة في الحالتين.

تشغيل سكربت Bash

30 2 * * * /bin/bash /home/user/scripts/backup.sh

يمكنك الاستغناء عن /bin/bash إن كان السكربت يبدأ بسطر shebang صحيح #!/bin/bash وكانت صلاحية التنفيذ مضبوطة بـchmod +x. لكن كتابة المفسّر صراحةً تُلغي الاعتماد على الصلاحيات وتوفّر عليك تشخيصًا مزعجًا لاحقًا.

استدعاء رابط على الموقع

بعض الإضافات والأنظمة تتوقّع استدعاء رابط بدل تشغيل ملف. استخدم curl أو wget بمسارهما المطلق:

*/10 * * * * /usr/bin/curl -s "https://example.com/cron/run.php" >/dev/null 2>&1

انتبه لأمرين: ضع الرابط بين علامتَي تنصيص إن احتوى على ? أو &، واستخدم -s مع curl (أو -q -O - مع wget) لكتم شريط التقدّم الذي يملأ سجلّاتك بلا فائدة. وتذكّر أن هذه الطريقة تمرّ عبر خادم الويب، فهي محكومة بمهلة PHP القصوى — لا تناسب المهام الطويلة.

وصفات جاهزة: نسخ احتياطي، تنظيف، وتقارير

إليك ثلاث مهام يحتاجها كل موقع تقريبًا، مكتوبة كاملة وجاهزة للتعديل.

1) نسخة احتياطية يومية لقاعدة البيانات والملفات

أنشئ الملف /home/user/scripts/backup.sh:

#!/bin/bash
set -euo pipefail

STAMP=$(date +%F)
DEST=/home/user/backups
SITE=/home/user/public_html

mkdir -p "$DEST"

# نسخة قاعدة البيانات (بيانات الدخول تُقرأ من ~/.my.cnf)
mysqldump --single-transaction --quick my_database > "$DEST/db-$STAMP.sql"
gzip -f "$DEST/db-$STAMP.sql"

# نسخة ملفات الموقع
tar -czf "$DEST/files-$STAMP.tar.gz" -C "$(dirname "$SITE")" "$(basename "$SITE")"

# احذف النسخ الأقدم من 14 يومًا
find "$DEST" -type f -mtime +14 -delete

echo "[$(date +'%F %T')] اكتملت النسخة الاحتياطية بنجاح"

لا تضع كلمة مرور قاعدة البيانات في سطر الأمر — أي مستخدم على الخادم يستطيع رؤيتها في قائمة العمليات. ضعها بدل ذلك في ملف ~/.my.cnf بصلاحيات مغلقة:

# محتوى الملف ~/.my.cnf
[client]
user=my_db_user
password=ضع_كلمة_المرور_هنا

chmod 600 ~/.my.cnf
chmod +x /home/user/scripts/backup.sh

ثم سطر crontab:

30 2 * * * /bin/bash /home/user/scripts/backup.sh >> /home/user/logs/backup.log 2>&1

هذه نسخة محلّية على الخادم نفسه، وهي ليست استراتيجية نسخ احتياطي كاملة: نسخة تعيش على القرص نفسه تضيع مع القرص. اقرأ دليل النسخ الاحتياطي للموقع لفهم قاعدة النسخ الثلاث ووجهات التخزين الخارجية، وإن كنت على ووردبريس فـدليل النسخ الاحتياطي لووردبريس يغطّي الإضافات والاستعادة تفصيلًا.

2) تنظيف الملفات المؤقتة والسجلّات

تراكم الملفات المؤقتة يستهلك المساحة وعدد الملفات المسموح (inodes) معًا، وقد يوقف موقعك دون سبب ظاهر:

# حذف الملفات المؤقتة الأقدم من 7 أيام — يوميًا الرابعة فجرًا
0 4 * * * /usr/bin/find /home/user/tmp -type f -mtime +7 -delete >/dev/null 2>&1

# تقليم سجلّ التصحيح إن تجاوز حجمه المعقول — كل يوم أحد
0 5 * * 0 /usr/bin/find /home/user/public_html/wp-content -maxdepth 1 -name "debug.log" -size +50M -delete >> /home/user/logs/cleanup.log 2>&1

3) تقرير يومي يُرسَل بالبريد

سكربت PHP يقرأ من قاعدة البيانات ويرسل ملخّصًا. احفظه في /home/user/scripts/daily-report.php:

<?php
// تقرير مبيعات الأمس — يُشغَّل من cron عبر PHP CLI

$dsn  = 'mysql:host=localhost;dbname=my_database;charset=utf8mb4';
$user = 'my_db_user';
$pass = getenv('DB_PASSWORD') ?: '';

try {
    $pdo = new PDO($dsn, $user, $pass, [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    ]);

    $since = date('Y-m-d 00:00:00', strtotime('-1 day'));
    $until = date('Y-m-d 00:00:00');

    $stmt = $pdo->prepare(
        'SELECT COUNT(*) AS orders_count, COALESCE(SUM(total), 0) AS revenue
         FROM orders
         WHERE created_at >= :since AND created_at < :until'
    );
    $stmt->execute([':since' => $since, ':until' => $until]);
    $row = $stmt->fetch(PDO::FETCH_ASSOC);

    $body = sprintf(
        "تقرير يوم %s\nعدد الطلبات: %d\nإجمالي المبيعات: %s\n",
        date('Y-m-d', strtotime('-1 day')),
        $row['orders_count'],
        number_format((float) $row['revenue'], 2)
    );

    $subject = '=?UTF-8?B?' . base64_encode('تقرير المبيعات اليومي') . '?=';
    $headers = "MIME-Version: 1.0\r\n"
             . "Content-Type: text/plain; charset=UTF-8\r\n"
             . "Content-Transfer-Encoding: 8bit\r\n";

    mail('owner@example.com', $subject, $body, $headers);
    echo "تم إرسال التقرير\n";
} catch (PDOException $e) {
    // اطبع الخطأ ليُسجَّل في ملف سجلّ المهمة
    fwrite(STDERR, 'فشل التقرير: ' . $e->getMessage() . PHP_EOL);
    exit(1);
}

وسطر crontab:

0 7 * * * /usr/local/bin/php -q /home/user/scripts/daily-report.php >> /home/user/logs/report.log 2>&1

لاحظ ترميز عنوان الرسالة بصيغة =?UTF-8?B?...?=: بدونه تصل عناوين البريد العربية كرموز مشوّهة في معظم برامج البريد. وكذلك exit(1) عند الفشل — رمز الخروج غير الصفري يجعل أدوات المراقبة قادرة على اكتشاف فشل المهمة آليًا.

المهام المجدولة على VPS: التعامل مع crontab مباشرة

إن كنت على خادم افتراضي خاص VPS فلديك وصول كامل، وتحرير الجدول يتمّ عبر SSH. إن لم تكن مرتاحًا بعد مع الطرفية، فـأساسيات SSH للمبتدئين نقطة البداية الصحيحة.

crontab -e     # فتح جدولك للتحرير
crontab -l     # عرض المهام الحالية
crontab -l > ~/crontab-backup.txt   # نسخة احتياطية من الجدول نفسه
crontab -r     # حذف كل مهامك — خطر، لا تراجع عنه

خذ عادة أخذ نسخة قبل أي تعديل. المسافة الصغيرة على لوحة المفاتيح بين -e و-r كلّفت كثيرين جداولهم كاملةً.

يمكنك أيضًا ضبط بيئة المهام في أعلى ملف crontab، وهو حلّ أنيق لمشكلة PATH الفقيرة:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=""

0 3 * * * /home/user/scripts/backup.sh
*/10 * * * * /home/user/scripts/health-check.sh

للتأكّد من أن خدمة cron نفسها تعمل — وهي خطوة يهملها كثيرون قبل تشخيص المهمة نفسها:

systemctl status cron     # على Debian وUbuntu
systemctl status crond    # على AlmaLinux وRocky وCentOS

إدارة هذه الخدمات وقراءة حالتها موضوع قائم بذاته يغطّيه دليل إدارة الخدمات على Linux، وفيه أيضًا مقارنة بين cron وبديله الحديث systemd timers.

الصيغة العملية للقفل داخل سطر crontab:

*/5 * * * * /usr/bin/flock -n /tmp/sync.lock /home/user/scripts/sync.sh >> /home/user/logs/sync.log 2>&1

الراية -n تعني: إن كان القفل مأخوذًا فاخرج فورًا بدل الانتظار — وهذا بالضبط ما تريده، لأن انتظار المهمة السابقة يراكم العمليات بدل أن يمنعها.

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

wp-cron مقابل cron الحقيقي: الفرق الذي يكسر المواقع

هنا الجزء الذي يجب أن يقرأه كل صاحب موقع ووردبريس مرّتين.

ووردبريس يملك نظام جدولة داخليًا اسمه WP-Cron، تعتمد عليه وظائف كثيرة: نشر المقالات المجدولة، فحص التحديثات، تنظيف المراجعات، وجدولة مهام الإضافات كإرسال الرسائل ونسخ النسخ الاحتياطية. المشكلة أن هذا النظام ليس cron حقيقيًا ولا علاقة له بخدمة النظام. إنه مجرد قائمة مهام مخزّنة في قاعدة البيانات، ولا يفحصها ووردبريس إلّا عند تحميل صفحة: مع كل زيارة، يستدعي ووردبريس الملف wp-cron.php في طلب داخلي ليسأل «هل فات موعد أي مهمة؟».

النتيجة معادلة عكسية غريبة تضرّ الطرفين:

• الموقع قليل الزيارات: لا زيارات تعني لا استدعاء. المقال المجدول للسادسة صباحًا لا يُنشَر حتى يفتح أحدهم الموقع ظهرًا. النسخة الاحتياطية «اليومية» تصير عشوائية. رسالة تأكيد الطلب تتأخّر ساعات.
• الموقع كثير الزيارات: كل زيارة تطلق طلب HTTP داخليًا إضافيًا. عشرة آلاف زيارة يوميًا تعني آلاف الاستدعاءات لمهمة قد لا تحتاج التنفيذ إلّا مرّتين. الأثر مباشر على المعالج وزمن الاستجابة، وهو من أسباب البطء التي يغفلها كثيرون — راجع تسريع ووردبريس لباقي العوامل.

كيف تستبدله بالطريقة الصحيحة

الخطوة الأولى: عطّل الاستدعاء التلقائي. افتح ملف wp-config.php في جذر الموقع — يمكنك تحريره من مدير الملفات في اللوحة — وأضف السطر التالي قبل سطر /* That's all, stop editing! */:

define('DISABLE_WP_CRON', true);

الخطوة الثانية — ولا تؤجّلها دقيقة واحدة — أنشئ المهمة البديلة:

*/10 * * * * /usr/bin/curl -s "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

أو بـwget إن لم يكن curl متاحًا:

*/10 * * * * /usr/bin/wget -q -O - "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

الطريقة الأفضل: WP-CLI

إن كانت أداة سطر الأوامر WP-CLI متاحة على استضافتك — وهي متوفّرة على معظم الخطط الجادّة، وأداة لا غنى عنها عند إصلاح أخطاء ووردبريس الشائعة — فاستخدامها أفضل من استدعاء الرابط لثلاثة أسباب: لا يمرّ عبر خادم الويب فلا يخضع لمهلة PHP القصوى، ولا يستهلك عاملًا من عمّال الويب، ويعطي رمز خروج واضحًا عند الفشل.

*/10 * * * * cd /home/user/public_html && /usr/local/bin/wp cron event run --due-now >> /home/user/logs/wpcron.log 2>&1

وأوامر مفيدة للفحص اليدوي عبر SSH:

wp cron event list          # عرض المهام المجدولة ومواعيدها
wp cron event run --due-now # تشغيل المستحقّ الآن
wp cron test                # فحص هل يعمل نظام wp-cron أصلًا

ويمكنك استغلال الوصول نفسه لصيانة دورية أخرى، مثل تحسين جداول قاعدة البيانات أسبوعيًا:

0 5 * * 0 cd /home/user/public_html && /usr/local/bin/wp transient delete --expired --quiet && /usr/local/bin/wp db optimize --quiet >> /home/user/logs/wp-maint.log 2>&1

لكن انتبه: تحسين الجداول ليس دواءً لكل بطء، وقاعدة بيانات منتفخة بمراجعات وبيانات إضافات محذوفة تحتاج تنظيفًا أعمق يشرحه تحسين قاعدة بيانات ووردبريس.

استكشاف الأخطاء: لماذا لا تعمل مهمّتي؟

هذا القسم يوفّر عليك ساعات. ابدأ دائمًا من الجدول أدناه، ثم انزل إلى التفاصيل.

المهمة لا تعمل إطلاقًا

ابدأ بأبسط اختبار ممكن: جدوِل مهمة لا تفعل شيئًا سوى كتابة الوقت في ملف.

* * * * * /bin/date >> /home/user/logs/cron-test.log 2>&1

انتظر دقيقتين ثم افحص الملف. إن امتلأ، فخدمة cron تعمل والمشكلة في أمرك أنت. وإن بقي فارغًا، فالمشكلة أعمق: الخدمة متوقّفة، أو حسابك ممنوع من cron، أو ملف crontab لا ينتهي بسطر جديد (بعض التنفيذات القديمة تتجاهل السطر الأخير غير المنتهي بـEnter).

بعدها انتقل لسجلّات النظام على VPS:

grep CRON /var/log/syslog | tail -30    # على Debian وUbuntu
tail -30 /var/log/cron                  # على AlmaLinux وRocky
journalctl -u cron --since "1 hour ago" # عبر systemd

السجلّ سيخبرك إن كان cron قد حاول التشغيل أصلًا. هذا يفصل بين احتمالين مختلفين تمامًا: صيغة زمنية لم تتحقّق (لا يظهر شيء في السجلّ)، أو أمر فشل عند التنفيذ (يظهر سطر التشغيل ثم خطأ).

المهمة تعمل مرّتين

سببان شائعان. الأول أن المهمة مُعرَّفة في مكانين: أضفتها من لوحة الاستضافة ثم أضفتها مرّة أخرى بـcrontab -e — وهما في الواقع الجدول نفسه، لكن واجهتين مختلفتين قد تخدعانك. افحص crontab -l وقارنه بما تراه في اللوحة.

السبب الثاني هو منطق «أو» بين يوم الشهر ويوم الأسبوع الذي شرحناه سابقًا. وهناك سبب ثالث أخبث: مهمة طويلة تُشغَّل بفاصل أقصر من مدّتها، فتتراكب النسخ وتبدو كأنها تعمل مرّتين. القفل بملف يحلّها.

رسائل البريد المزعجة من cron

بشكل افتراضي، يرسل cron كل مخرجات المهمة إلى بريد المستخدم — حتى المخرجات الناجحة. مهمة كل خمس دقائق تطبع سطرًا واحدًا تعني 288 رسالة يوميًا. أمامك ثلاثة خيارات، وترتيبها من الأسوأ إلى الأفضل:

# 1) إسكات كل شيء — يخفي الأخطاء أيضًا، لا ينصح به
0 3 * * * /home/user/scripts/task.sh >/dev/null 2>&1

# 2) إسكات المخرجات الناجحة فقط، وإبقاء بريد الأخطاء
0 3 * * * /home/user/scripts/task.sh >/dev/null

# 3) الأفضل: كل شيء إلى ملف سجلّ يمكنك مراجعته
0 3 * * * /home/user/scripts/task.sh >> /home/user/logs/task.log 2>&1

الفرق بين الأول والثاني دقيق ومهم: الرمز 2>&1 يعني «وجّه تيار الأخطاء إلى حيث ذهبت المخرجات العادية». إسقاطه في الخيار الثاني يعني أن المخرجات العادية تُهمَل بينما الأخطاء تصلك بريدًا — وهو تصرّف ممتاز للمهام الحرجة. أما إن أردت إيقاف بريد cron كليًا، ضع في أعلى crontab سطر MAILTO="".

المهمة تعمل في وقت خاطئ

توقيت الخادم قد يخالف توقيتك المحلّي، وهذا أكثر شيوعًا ممّا تظن: كثير من الخوادم تعمل بتوقيت UTC افتراضيًا. مهمة جدولتها للثالثة فجرًا ستعمل في السادسة صباحًا بتوقيت الرياض إن كان الخادم على UTC.

date              # الوقت الحالي على الخادم
timedatectl       # المنطقة الزمنية المضبوطة (على VPS)

على VPS يمكنك تغيير المنطقة الزمنية للنظام كله، لكن لا تفعل ذلك على خادم يعمل إلّا بعد التفكير: تغيير التوقيت يربك السجلّات ويؤثّر على تطبيقات أخرى. البديل الأبسط أن تحسب الفارق مرّة واحدة وتكتب المواعيد بتوقيت الخادم.

وانتبه لتفصيل يخصّ ووردبريس: المنطقة الزمنية التي تضبطها في إعدادات ووردبريس تخصّ عرض التواريخ داخل الموقع فقط، ولا علاقة لها بموعد تشغيل مهام cron على الخادم. الاثنان نظامان مستقلّان تمامًا.

ماذا تجدول فعلًا؟ خطة لموقع ومتجر

ليس كل شيء يستحق الجدولة، والإفراط في المهام يستهلك مواردك دون فائدة. هذه المصفوفة تساعدك على الاختيار:

وهذه خطة عملية جاهزة لموقع محتوى أو متجر صغير إلى متوسط:

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

الأسئلة الشائعة

هل تدعم كل خطط الاستضافة المشتركة المهام المجدولة؟ معظمها نعم، لكن ليس كلها. الخطط الاقتصادية جدًا وبعض حزم البناء المبسّطة تُخفي قسم Cron Jobs تمامًا لتقليل الحمل على الخادم المشترك. الطريقة الأسرع للتأكّد: ادخل لوحتك وابحث عن «Cron» في مربّع البحث — إن لم يظهر شيء، فالميزة معطّلة في خطتك. في هذه الحالة أمامك خياران: الترقية إلى خطة تدعمها، أو استخدام خدمة خارجية تستدعي رابطًا على موقعك في مواعيد محدّدة، وهي حلّ مقبول للمهام الخفيفة لكنها تعتمد على طرف ثالث.

ما أقلّ فاصل زمني يمكن أن تعمل به المهمة؟ الحدّ التقني لـcron نفسه هو دقيقة واحدة، لأن الخدمة تستيقظ كل دقيقة ولا تعرف وحدات أصغر. لا توجد صيغة قياسية للثواني إطلاقًا. أما عمليًا، فأغلب المضيفين على الاستضافة المشتركة يفرضون حدًّا أدنى أعلى من ذلك — خمس دقائق أو خمس عشرة — لأن مهامًا تعمل كل دقيقة عبر مئات الحسابات تُثقل الخادم. إن حاولت جدولة أقلّ من الحدّ المسموح فقد ترفض اللوحة الحفظ، أو تقبله وتتجاهله الخدمة صامتة.

هل تعطيل wp-cron يضرّ موقعي؟ لا يضرّه إن استبدلته فورًا بمهمة خادم حقيقية — بل يحسّنه أداءً وموثوقية معًا. الضرر يقع في حالة واحدة: أن تعطّله وتنسى البديل. حينها تتوقّف كل الجدولة في ووردبريس بصمت، فلا مقالات مجدولة تُنشَر ولا نسخ احتياطية تُؤخذ ولا رسائل تُرسَل، ولن تظهر رسالة خطأ واحدة تنبّهك. لذلك الترتيب الآمن دائمًا: أنشئ مهمة cron الحقيقية، تأكّد بالتجربة أنها تعمل فعلًا، ثم أضف سطر التعطيل في wp-config.php.

لماذا تصلني رسائل بريد بعد كل تشغيل للمهمة؟ لأن هذا السلوك الافتراضي لـcron: كل ما تطبعه المهمة على الشاشة يُرسَل بريدًا إلى صاحب الحساب. حتى رسالة نجاح بسيطة أو ترويسة HTTP تكفي لتوليد رسالة. الحلّ الأنظف توجيه المخرجات إلى ملف سجلّ بإضافة >> /path/to/log 2>&1 في نهاية سطر الأمر. وإن أردت إيقاف البريد كليًا ضع MAILTO="" في أعلى crontab، أو أفرغ حقل Cron Email في اللوحة. تجنّب >/dev/null 2>&1 للمهام الحرجة لأنها تخفي الأخطاء أيضًا.

كيف أعرف أن المهمة عملت فعلًا؟ ثلاث طبقات من التحقّق. أولًا اجعل المهمة تكتب سطرًا في ملف سجلّ يحمل التاريخ والوقت والنتيجة، ثم افحص الملف بعد الموعد المتوقّع. ثانيًا على VPS راجع سجلّ النظام بـgrep CRON /var/log/syslog لترى إن كان cron حاول التشغيل أصلًا — هذا يفصل بين خطأ في الصيغة الزمنية وخطأ في الأمر. ثالثًا وللمهام الحرجة، اجعل السكربت يرسل إشعارًا عند الفشل فقط، أو يحدّث ملفًا يفحصه نظام مراقبة خارجي.

هل يمكن تشغيل مهمة كل 30 ثانية؟ ليس بصيغة cron مباشرة، لأن أصغر وحدة يفهمها هي الدقيقة. الحيلة المعروفة أن تجدول المهمة كل دقيقة وتشغّلها مرّتين مع تأخير: * * * * * /home/user/scripts/task.sh ثم سطر ثانٍ * * * * * sleep 30; /home/user/scripts/task.sh. تعمل هذه الطريقة لكنها ليست دقيقة وتستهلك عملية إضافية نائمة طوال الوقت. إن كنت تحتاج فواصل بالثواني فعلًا، فالأداة الصحيحة ليست cron بل عملية خلفية دائمة أو systemd timer بدقّة أعلى.

ما الفرق بين cron وأدوات الأتمتة الحديثة؟ cron مُشغِّل زمني بسيط: ينفّذ أمرًا في موعده، ولا يعرف شيئًا عن نتيجة الأمر ولا يتعامل مع فشل ولا يربط خطوات ببعضها. أدوات الأتمتة الحديثة تضيف فوقه طبقة منطق: شروط، وتفريعات، وإعادة محاولة عند الفشل، وربط بخدمات خارجية عبر واجهات برمجية. القاعدة العملية: إن كانت المهمة «شغّل هذا الأمر في هذا الوقت» فـcron أبسط وأخفّ وأكثر موثوقية. أمّا إن كانت سلسلة خطوات مشروطة تمرّ عبر أنظمة متعدّدة، فأنت تحتاج أداة أتمتة كاملة، وستبقى مجدولة بمُشغِّل زمني في جوهره.

هل تستهلك المهام المجدولة من موارد استضافتي؟ نعم، وهذا ما يغفله كثيرون. كل تشغيل يفتح عملية على الخادم تستهلك معالجًا وذاكرة ودخل وخرج للقرص، ويُحتسب ضمن حصّتك تمامًا كأي زيارة. مهمة خفيفة كل خمس دقائق لا تُذكَر، لكن نسخة احتياطية كاملة تضغط جيجابايتات قد ترفع استهلاك المعالج إلى السقف لدقائق وتُبطئ الموقع. لذلك القاعدة: جدوِل الثقيل خارج ساعات الذروة، وباعد بين المهام الكبيرة، وراقب استهلاكك بعد إضافة أي مهمة جديدة لأسبوع.

المصادر

• ووردبريس للمطوّرين — نظام WP-Cron