محتوای آموزشی وبلاگ نت‌آرام
یک کار روزانه روی سرور لینوکسی تنظیم کرده‌اید، ولی در ساعتی که باید اجرا شود سرور خاموش بوده یا تایمر غیرفعال شده است. بعد از روشن‌شدن چه می‌شود؟ پاسخ به نوع تایمر و تنظیمات آن بستگی دارد. گاهی باید تا نوبت بعدی صبر کنید؛ گاهی systemd یک اجرای جبرانی راه می‌اندازد. این اجرا لزوماً همه نوبت‌های ازدست‌رفته را یکی‌یکی تکرار نمی‌کند.
در این راهنما یاد می‌گیریم اول مشخص کنیم تایمر فعال است یا خیر، بعد زمان و گزارش سرویس را بخوانیم و در صورت نیاز تنظیم جبران را با احتیاط انجام دهیم. مثال برای سرورهایی است که از systemd استفاده می‌کنند؛ cron یا WP-Cron سازوکار متفاوتی دارند.
تایمر و سرویس چه فرقی دارند؟
تایمر شبیه زنگ ساعت است؛ زمان اجرا را تعیین می‌کند. سرویس کاری است که بعد از زنگ باید انجام شود؛ مثلاً ساخت یک گزارش. در مثال ما تایمر
example.timer سرویس example.service را اجرا می‌کند. نام‌های واقعی روی سرور شما فرق دارند و ممکن است تایمر با گزینه‌ای سرویس دیگری را هدف بگیرد.قبل از تغییر، نام تایمر و وظیفه سرویس را از مدیر یا مستندات برنامه مشخص کنید. این کار مهم است چون یک اجرای ناخواسته ممکن است پرداخت، ارسال پیام یا عملیات دیگری را دوباره انجام دهد. اجرای آزمایشی را روی سرویس حساس سایت اصلی انجام ندهید.
قدم اول: وضعیت و زمان بعدی را ببینید
با SSH وارد سرور مجاز شوید. اگر دستور زیر به دسترسی مدیر نیاز داشت، آن را با حساب مجاز و در صورت نیاز
کد / دستورsudo اجرا کنید:systemctl status example.timer
در خروجی،
کد / دستورactive (waiting) معمولاً یعنی تایمر فعال است و منتظر زمان اجراست. inactive یا failed یعنی باید علت غیرفعال یا ناموفق بودن را بررسی کنید. برای خروج از صفحه گزارش کلید q را بزنید. حالا زمان‌ها را ببینید:systemctl list-timers --all example.timer
ستون
NEXT زمان بعدی و LAST آخرین زمان ثبت‌شده تایمر را نشان می‌دهد. این اطلاعات ثابت نمی‌کند خود کار با موفقیت تمام شده است. اگر تایمر پیدا نشد، نام دقیق آن، نصب بودن واحد و سطح دسترسی را بررسی کنید. تایمرهای کاربری با systemctl --user و نشست کاربر مدیریت می‌شوند و شرایطشان با سرویس سیستمی فرق دارد.قدم دوم: برنامه، ساعت و گزارش واقعی کار را مقایسه کنید
برای دیدن تنظیمات مؤثر تایمر، همراه تغییرات اضافه‌شده، اجرا کنید:
کد / دستورsystemctl cat example.timer
به
OnCalendar، Persistent، Unit و گزینه‌هایی مانند RandomizedDelaySec نگاه کنید. OnCalendar برنامه مبتنی بر ساعت و تقویم است. گزینه تأخیر تصادفی یا دقت تایمر می‌تواند شروع را از ساعت دقیق عقب ببرد. اگر Unit نام دیگری دارد، در دستور گزارش بعدی نام همان سرویس را استفاده کنید.ساعت و منطقه زمانی سرور را هم بخوانید:
کد / دستورtimedatectl
زمان محلی، منطقه زمانی و وضعیت ساعت را با زمان مورد انتظار خود مقایسه کنید. تغییر منطقه زمانی روی برنامه‌های دیگر نیز اثر می‌گذارد؛ بدون بررسی همه سرویس‌ها آن را تغییر ندهید. اگر زمان‌بندی تقویمی دارید، برای فهم زمان بعدی می‌توانید عبارت واقعی تنظیم را با
کد / دستورsystemd-analyze calendar آزمایش کنید. برای مثال:systemd-analyze calendar 'daily'
این دستور معنی عبارت نمونه و زمان بعدی آن را با ساعت سیستم نشان می‌دهد و کاری را اجرا نمی‌کند. برای برنامه خود، عبارت موجود در
کد / دستورOnCalendar را جایگزین کنید. سپس گزارش سرویس را بخوانید:journalctl -u example.service --since 'today' --no-pager
اینجا نام سرویس واقعی را بگذارید. گزارش از شروع امروز سرور را نشان می‌دهد؛ در صورت نیاز بازه دیگری انتخاب کنید. اگر شروع دیده می‌شود اما خطا یا وضعیت خروج ناموفق وجود دارد، مشکل در خود سرویس است نه الزاماً تایمر. اگر برنامه خروجی مستقلی دارد، همان خروجی یا نتیجه واقعی آن را هم بررسی کنید.
Persistent چه می‌کند و چه نمی‌کند؟
در تایمرهای مبتنی بر
OnCalendar، گزینه Persistent=true زمان آخرین فعال‌سازی را نگه می‌دارد. وقتی تایمر دوباره فعال شود و حداقل یک نوبت در زمان غیرفعال‌بودن از دست رفته باشد، طبق شرایط systemd یک فعال‌سازی جبرانی انجام می‌شود؛ ممکن است تنظیم تأخیر تصادفی نیز اعمال شود. این گزینه برای تایمرهای صرفاً مبتنی بر OnBootSec یا OnUnitActiveSec همان اثر را ندارد. توضیح دقیق در مستند systemd.timer آمده است.این ویژگی به معنی اجرای جداگانه تمام نوبت‌های ازدست‌رفته یا تضمین موفقیت کار نیست. اگر سرویس هنگام موعد هنوز فعال باشد، systemd معمولاً نمونه تازه‌ای از همان سرویس راه نمی‌اندازد. همچنین بعضی سرویس‌ها با
RemainAfterExit=yes فعال باقی می‌مانند و برای تکرار دوره‌ای مناسب نیستند؛ پیکربندی و نتیجه سرویس را بررسی کنید.اگر اجرای جبرانی برای کار شما امن است
اول روی سرور آزمایشی یا تایمر مخصوص آزمایش، رفتار را بررسی کنید. مطمئن شوید اجرای دوباره، پیام یا تراکنش تکراری نمی‌سازد و برنامه قادر است نتیجه نوبت قبلی را تشخیص دهد. از پیکربندی و وضعیت فعلی نیز نسخه نگه دارید.
مدیر سرور می‌تواند به‌جای ویرایش مستقیم فایل اصلی، یک override بسازد:
کد / دستورsudo systemctl edit example.timer
در بخش قابل ویرایش فایل بازشده این خطوط را وارد و فایل را ذخیره کنید؛ روش ذخیره به ویرایشگر بازشده بستگی دارد:
کد / دستور[Timer]
Persistent=true
پس از ذخیره، با
systemctl cat example.timer مطمئن شوید override دیده می‌شود. اگر برای اعمال وضعیت نیاز به بارگذاری دوباره یا راه‌اندازی تایمر دارید، آن را ابتدا با مستندات نسخه خود و در محیط آزمایشی انجام دهید: فعال‌کردن یا راه‌اندازی مجدد تایمر ممکن است کار جبرانی را فوراً شروع کند. تا زمانی که اثر آن را نمی‌دانید، روی سرویس واقعی این کار را نکنید.نتیجه را چطور تأیید کنیم؟
در آزمایش، زمان ثبت‌شده تایمر را با گزارش سرویس و خروجی واقعی کار مقایسه کنید. اگر سرویس گزارش موفق می‌دهد اما فایل یا نتیجه مورد انتظار ساخته نشده، کد خروج و گزارش برنامه را دقیق‌تر بخوانید. اگر خطا به دسترسی، مسیر فایل یا متغیر محیطی مربوط است، تنظیم اجرای سرویس را اصلاح کنید؛ ساعت تایمر به‌تنهایی آن مشکلات را برطرف نمی‌کند.
برای کارهای مهم روی سرور مجازی ایران، هشدار مستقل برای موفقیت واقعی و جلوگیری از اجرای تکراری در نظر بگیرید. تایمر روشن به‌تنهایی تضمین نمی‌کند کار مشتری انجام شده است.
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام