تشغيل مهام ownCloud في الخلفية بشكل موثوق باستخدام مؤقت Systemd

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

هذا الدليل مخصص لخادم ownCloud Classic المُثبّت مباشرةً على نظام Linux. لا ينطبق على ownCloud Infinite Scale، الذي يتميز ببنية مختلفة، أو على صورة Docker الرسمية لـ ownCloud، التي تُشغّل cron داخليًا. بالنسبة لـ Docker، اتبع الإعدادات الموثقة للصورة بدلًا من إنشاء مؤقت مضيف ثانٍ. راجع وثائق مهام الخلفية الحالية لخادم ownCloud .

تحقق من الأمر قبل تغيير الجدول الزمني

تُحدد خدمة systemd الأمر المراد تنفيذه؛ ويقوم مؤقت بتشغيل هذه الخدمة دوريًا. تأكد أولًا من مسار تثبيت ownCloud وحساب خادم HTTP. تستخدم الأمثلة أدناه حسابي `systemd` /var/www/owncloudو`systemd` www-data، وهما شائعان في Debian وUbuntu. قد تستخدم توزيعات Linux الأخرى حساب wwwrun`systemd` apacheأو `systemd` أو حسابًا آخر.

قم بتشغيل أمر ownCloud يدويًا باستخدام هذا الحساب للتمييز بين الأمر المعطل والجدول الزمني المعطل:

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

غيّر ملف PHP التنفيذي ومساره occليتوافق مع خادمك. توصي ownCloud باستخدام الأمر ` system:cronphp` للمهام التي تعمل في الخلفية؛ cron.phpقد تشير الأدلة القديمة التي تُجدول المهام إلى سلوكيات قديمة. قد ينتهي الأمر الحالي دون طباعة رسالة نجاح، لذا تحقق من حالة خروجه echo $?مباشرةً بعد ذلك: ` 0php` تعني أن الأمر قد انتهى بنجاح. إذا أعاد خطأً، فقم أولاً بإصلاح المسار، أو تثبيت PHP CLI، أو الأذونات، أو اتصال قاعدة البيانات، أو خطأ ownCloud. سيُعيد المؤقت تشغيل نفس الأمر الفاشل بشكل متكرر إذا تخطيت هذا الفحص.

قم بضبط ownCloud على وضع Cron

في إعدادات مسؤول ownCloud، افتح قسم "المهام الخلفية" أو "Cron" واختر "Cron" . يمكنك أيضًا ضبط المُجدوِل من مجلد التثبيت باستخدام الأمر التالي:

cd /var/www/owncloud
sudo -E -u www-data php occ background:cron

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

أنشئ خدمة systemd والمؤقت

أنشئ /etc/systemd/system/owncloudcron.serviceباستخدام حساب HTTP الفعلي ومسار ownCloud الخاص بك:

[Unit]
Description=ownCloud background jobs

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

Type=oneshotيُخبر هذا الأمر نظام systemd بأنه يُنفّذ حتى اكتماله ثم يتوقف. يُجنّب توفير مسار PHP الكامل الاعتماد على الموارد المحدودة PATHالمتاحة لخدمات النظام. يُساعد دليل العمل ownCloud على حلّ المسارات النسبية. حافظ على توافق حساب الخدمة مع مالك ملفات وبيانات ownCloud. لا تُشغّل المهمة بصلاحيات المستخدم الجذر (root).

ثم أنشئ /etc/systemd/system/owncloudcron.timer:

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

[Timer]
OnBootSec=5min
OnUnitActiveSec=15min
Unit=owncloudcron.service

[Install]
WantedBy=timers.target

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

قم بإخبار systemd بإعادة تحميل تعريفات الوحدات الخاصة به، ثم قم بتمكين المؤقت وبدء تشغيله:

sudo systemctl daemon-reload
sudo systemctl enable --now owncloudcron.timer

daemon-reloadيُشترط تفعيل هذه الخاصية بعد إنشاء ملفات الوحدة أو تعديلها. يؤدي تفعيل المؤقت إلى تشغيله تلقائيًا عند إعادة تشغيل الجهاز في المرات اللاحقة؛ --nowكما يؤدي إلى تشغيله في الجلسة الحالية. فعّل وحدة المؤقت، وليس الخدمة فقط.

اكتشف سبب تخطي أو فشل عملية الجري

تحقق مما إذا كان المؤقت مفعلاً ومتى سيتم تشغيله في المرة القادمة:

systemctl is-enabled owncloudcron.timer
systemctl list-timers --all owncloudcron.timer
systemctl status owncloudcron.timer

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

systemctl status owncloudcron.service
sudo journalctl -u owncloudcron.service --since today

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

تأكد من أن ownCloud يقوم بمعالجة المهام

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

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