حل مشكلة عدم تشغيل مهمة Cron في ownCloud: إعداد مؤقت systemd موثوق

عند فتح صفحة إدارة ownCloud، تلاحظ أن مهام الخلفية لم تُنفذ مؤخرًا، أو أن مهام التنظيف والنشاط والتخزين الخارجي وغيرها من المهام المُدرجة في قائمة الانتظار تبدو متأخرة. رد الفعل الشائع هو تعديل cron.phpأو إضافة إدخال جديد في crontab. لكن وفقًا لوثائق خادم ownCloud الحالية، هذه ليست أفضل نقطة بداية: توصي ownCloud باستخدام وضع Cron في الخلفية والأمر occ system:cronالمناسب. يمكن لمؤقت systemd توفير طبقة الجدولة بدلًا من crontab التقليدي على مضيف Linux.

يركز هذا الدليل على تثبيت حزمة أو تثبيت نظام تشغيل أساسي حيث يوجد ownCloud في مسار مثل /var/www/owncloud. إذا كنت تستخدم صورة Docker الرسمية لـ ownCloud، فتوقف قبل إنشاء مؤقت المضيف: تشير وثائق ownCloud إلى أن الصورة تُهيئ cron داخليًا، ويتم التحكم فيه بواسطة متغيرات مثل OWNCLOUD_CROND_ENABLEDو . راجع وثائق مهام الخلفيةOWNCLOUD_CROND_SCHEDULE الحالية لـ ownCloud .

ما الذي تم التحقق منه، وما الذي يعتمد على خادمك، وما الذي لا يزال بحاجة إلى التحقق؟

• تم التحقق: توصي ownCloud باستخدام Cron بدلاً من AJAX لتنفيذ المهام في الخلفية بشكل موثوق، وتوثق occ system:cronذلك كأمر لتنفيذ المهام الخلفية المدرجة في قائمة الانتظار.
• يعتمد ذلك على عملية التثبيت الخاصة بك: دليل ownCloud، وملف PHP الثنائي، وحساب خادم الويب، وبيئة PHP، وما إذا كنت تقوم بتشغيل تثبيت حزمة، أو حاوية، أو جهاز، أو نشر مخصص.
• لا يمكن معرفة سبب فشل مهمتك الحالية من دليل عام . قد تكون المشكلة متعلقة بالمجدول، ولكن قد تكون أيضاً متعلقة بالأذونات، أو مسار خاطئ، أو إعدادات مختلفة لواجهة سطر أوامر PHP، أو اتصال قاعدة البيانات، أو قفل الملفات، أو فشل مهمة تعمل في الخلفية على مستوى التطبيق.

الإجراء: لا تقم بإنشاء مؤقت حتى يعمل أمر ownCloud المحدد يدويًا تحت نفس الحساب الذي سيستخدمه المؤقت.

الخطوة 1: تأكيد وضع Cron واختبار ownCloud يدويًا

في تثبيت نموذجي لـ Apache/Debian، يكون مستخدم الويب هو www-data. استبدل كلاً من المستخدم والمسار إذا كانت بيئتك مختلفة.

sudo -u www-data /var/www/owncloud/occ background:cron
sudo -u www-data /var/www/owncloud/occ system:cron

يُفعّل الأمر الأول وضع تشغيل المهام الخلفية في Cron الخاص بـ ownCloud. أما الأمر الثاني فيُشغّل المهام الخلفية المُدرجة في قائمة الانتظار. تشير وثائق أمر occsystem:cron الخاص بـ ownCloud إلى أنه مُخصّص للتنفيذ المُجدول، وأنه لا ينبغي تفعيل عرض التقدم في مُجدول غير تفاعلي.

سوء فهم شائع: لا يعني "وضع Cron" في ownCloud أنه يجب عليك استخدام cronالبرنامج الخفي تحديدًا. بل يعني أن ownCloud يتوقع وجود مُجدوِل خارجي لتشغيل مُشغِّل المهام الخلفية. ويمكن أن يكون مؤقت systemd هو هذا المُجدوِل.

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

الخطوة الثانية: العثور على مسارات PHP و ownCloud الصحيحة

بعض عمليات التثبيت تجعل occالملف قابلاً للتنفيذ مباشرةً؛ بينما تكون عمليات تثبيت أخرى أكثر قابلية للتنبؤ عند استدعائها باستخدام ملف PHP CLI الثنائي. تأكد من كلا الخيارين:

command -v php
readlink -f /var/www/owncloud/occ
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ system:cron

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

الإجراء: استبدل القيم /usr/bin/php، /var/www/owncloudو www-dataفي الأمثلة المتبقية بالقيم التي نجحت على جهازك المضيف.

الخطوة 3: إنشاء خدمة systemd لمرة واحدة

يخلق /etc/systemd/system/owncloud-cron.service:

[Unit]
Description=Run ownCloud background jobs
After=network.target

[Service]
Type=oneshot
User=www-data
Group=www-data
WorkingDirectory=/var/www/owncloud
ExecStart=/usr/bin/php -f /var/www/owncloud/occ system:cron

لا تحتاج عادةً إلى [Install]قسم خاص بالخدمة لأن المؤقت يُفعّلها. Type=oneshotكما أن إبقاء الخدمة على حالها يُسهّل فهم دورة حياتها: تبدأ، تُنفّذ الأمر مرة واحدة، ثم تتوقف، وتصبح غير نشطة مرة أخرى.

سوء فهم شائع: خدمة التشغيل لمرة واحدة غير النشطة لا تتعطل تلقائيًا. بعد تشغيل ناجح، RemainAfterExit=yesتصبح خدمة التشغيل لمرة واحدة غير نشطة عادةً.

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

الخطوة 4: إنشاء مؤقت systemd

يخلق /etc/systemd/system/owncloud-cron.timer:

[Unit]
Description=Run ownCloud background jobs every 15 minutes

[Timer]
OnCalendar=*:0/15
Persistent=true
Unit=owncloud-cron.service

[Install]
WantedBy=timers.target

توصي وثائق host-cron الخاصة بـ ownCloud بجدولة مدتها 15 دقيقة. يتبع المؤقت المذكور أعلاه هذه الوتيرة. Persistent=trueيُعد استخدام المؤقت مفيدًا OnCalendarلأن systemd قد يُفعّل تنشيط التقويم الفائت بعد عودة الجهاز للعمل. مع ذلك، يعتمد السلوك الدقيق على إصدار systemd ومدة توقف الجهاز.

الإجراء: إذا كنتَ بحاجة إلى فاصل زمني مختلف عن قصد، فغيّره عمدًا بدلًا من نسخ قيمة من خادم آخر. قد يؤدي التنفيذ المتكرر إلى زيادة الحمل على النظام، بينما قد يؤدي التنفيذ الأقل تكرارًا إلى تأخير العمل المُدرج في قائمة الانتظار.

الخطوة 5: أعد تحميل systemd وقم بتفعيل المؤقت

sudo systemctl daemon-reload
sudo systemctl enable --now owncloud-cron.timer
sudo systemctl status owncloud-cron.timer

daemon-reloadيقوم هذا الأمر بإعادة قراءة ملفات الوحدة في نظام systemd. enable --nowكما أنه يُفعّل المؤقت لعمليات التشغيل المستقبلية ويبدأ تشغيله فورًا.

الإجراء: إذا لم يكن المؤقت نشطًا، فقم بالفحص systemctl status owncloud-cron.timerقبل تغيير إعدادات ownCloud مرة أخرى.

الخطوة 6: التحقق من عمليات تشغيل المؤقت التالية والسابقة

systemctl list-timers owncloud-cron.timer
systemctl list-timers --all | grep owncloud-cron

list-timersتُعدّ هذه أسرع طريقة للتأكد من أن نظام systemd قد جدول عملية التنشيط التالية، ولمعرفة آخر وقت تم فيه تشغيل المؤقت. وهذا يُميّز بين حالة "لم يتم تشغيل المؤقت مطلقًا" وحالة "تم تشغيل المؤقت ولكن فشل ownCloud داخل الخدمة".

الإجراء: إذا كان NEXT مفقودًا أو لم يتم إدراج المؤقت، فأعد التحقق من اسم ملف المؤقت [Install]والقسم وما إذا كانت الوحدة مفعلة.

الخطوة 7: تحقق من سجل الصيانة، وليس فقط المؤقت

يسجل نظام systemd مخرجات الخدمة في سجل النظام ما لم تقم بإعادة توجيهها إلى مكان آخر عمدًا. توضح وثائق journalctl الرسمية كيفية تصفية إدخالات السجل حسب وحدة systemd.

sudo journalctl -u owncloud-cron.service --since today
sudo journalctl -u owncloud-cron.service -n 100 --no-pager

سوء فهم شائع: "المؤقت نشط، لذا فإن خدمة ownCloud cron تعمل". إن وجود مؤقت نشط لا يثبت سوى أن المجدول ينتظر التشغيل. ما زلت بحاجة إلى استدعاء ناجح للخدمة.

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

الخطوة 8: تشغيل عملية واحدة عند الطلب والتحقق من ownCloud

لا داعي للانتظار 15 دقيقة لإجراء الاختبار النهائي:

sudo systemctl start owncloud-cron.service
sudo systemctl status owncloud-cron.service
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ status

بعد تشغيل ناجح لمرة واحدة، systemctl statusيمكن الإبلاغ عن الخدمة على أنها غير نشطة مع عرضها أيضًا status=0/SUCCESS. والنتيجة المهمة هي أن الأمر قد اكتمل بنجاح.

الإجراء: بعد نجاح اختبار الخدمة اليدوي، انتظر حتى يتم تفعيل مؤقت مجدول واحد على الأقل وتأكد من ظهور إدخال سجل جديد دون تدخل يدوي.

إذا لم يتم تشغيله بعد: قم باستكشاف الأخطاء وإصلاحها حسب الطبقة

ملاحظة حول ملف cron.php والأدلة القديمة

غالبًا ما كانت تعليمات ownCloud القديمة تستدعي الأوامر cron.phpمباشرةً. أما وثائق ownCloud الحالية فتوصي باستخدام هذه الطريقة occ system:cron، وتشرح ملاحظات إصدار ownCloud عملية الانتقال من cron.phpالأسلوب المباشر القديم. راجع ملاحظات إصدار خادم ownCloud .

الإجراء: إذا ورثت وحدة crontab أو systemd قديمة تعمل cron.php، فقارنها بالوثائق الخاصة بإصدار ownCloud المثبت لديك قبل الاحتفاظ بها.

قائمة التحقق النهائية

• تم إعداد ownCloud لتشغيل مهام Cron في الخلفية.
• يتم تنفيذ الأمر المحدد occ system:cronبنجاح باستخدام حساب خادم الويب المقصود.
• owncloud-cron.timerتم تفعيلها و active (waiting).
• systemctl list-timersيعرض كلاً من التنشيط التالي والتنشيط السابق بعد مرور وقت كافٍ.
• journalctl -u owncloud-cron.serviceيُظهر عمليات التنفيذ المجدولة بنجاح.
• لا يقوم الإعداد بتكرار cron الذي تم توفيره بالفعل بواسطة صورة ownCloud Docker الرسمية أو أي جدولة أخرى.

عندما تجتاز جميع تلك الفحوصات، تكون قد تحققت من أكثر من مجرد "وجود مؤقت": لقد أظهرت أن systemd يقوم بجدولة المهمة، ويستدعي ownCloud تحت الحساب الصحيح، ويكمل تشغيل مهمة الخلفية الفعلية بنجاح.