محتوای آموزشی وبلاگ نت‌آرام
دستوری را در ترمینال سرور اجرا می‌کنید و درست کار می‌کند، اما همان دستور در cron نتیجه‌ای ندارد. ممکن است زمان‌بندی اصلاً اجرا نشده باشد، یا اجرا شده و به دلیل تفاوت مسیر، حساب کاربری، دسترسی یا تنظیمات محیط شکست خورده باشد. این دو وضعیت راه‌حل متفاوت دارند.
اول نشانه اجرای cron را می‌بینیم، سپس خروجی خود برنامه را نگه می‌داریم و با اجرای دستی مقایسه می‌کنیم. دستورهای نمونه برای لینوکس دارای سرویس cron هستند و با WP-Cron وردپرس یا تایمر systemd یکی نیستند. اگر هاست اشتراکی دارید، بخشی از تنظیمات و گزارش‌ها ممکن است فقط در اختیار میزبان باشد.
قدم اول: کار متعلق به کدام حساب است؟
با همان حسابی که کار باید زیر آن اجرا شود وارد SSH شوید و این دستور را بزنید:
کد / دستورcrontab -l
این دستور جدول cron حساب فعلی را فقط نمایش می‌دهد. اگر می‌گوید جدولی وجود ندارد، احتمال دارد کار در حساب دیگری، پنل هاست یا فایل سیستم ثبت شده باشد. جدول کاربر عادی، جدول ریشه و فایل‌های سیستمی یکی نیستند. در فایل‌های سیستمی مانند
/etc/crontab معمولاً ستون نام کاربر هم وجود دارد، اما در جدول شخصی crontab -e چنین ستونی قرار نمی‌گیرد.یک خط زمان‌بندی معمولاً پنج بخش زمان و بعد دستور دارد: دقیقه، ساعت، روز ماه، ماه و روز هفته. برای مثال، خط زیر هر روز ساعت ۹:۱۵ بر اساس تنظیم زمان cron اجرا می‌شود:
کد / دستور15 9 * * * /usr/bin/python3 /home/site/scripts/check.py
این فقط مثال است. مسیر، حساب و ساعت واقعی خودتان را به کار ببرید و آن را بدون شناخت وظیفه کپی نکنید. منطقه زمانی سرور و در صورت پشتیبانی تنظیم
CRON_TZ در پیاده‌سازی مورد استفاده را نیز بررسی کنید. timedatectl ساعت و منطقه زمانی سیستم را نشان می‌دهد، اما لزوماً همه تنظیمات ویژه هر cron را نشان نمی‌دهد.قدم دوم: آیا سرویس زمان‌بندی فعال است؟
روی Ubuntu یا Debian که از سرویس رایج
کد / دستورcron استفاده می‌کنند، مدیر سرور می‌تواند وضعیت را ببیند:systemctl status cron
در برخی خانواده‌های RHEL مانند AlmaLinux، نام سرویس معمولاً
کد / دستورcrond است:systemctl status crond
این فرمان‌ها وضعیت را فقط نشان می‌دهند و چیزی را تغییر نمی‌دهند. اگر سرویس در توزیع شما وجود ندارد، ابتدا نام و روش زمان‌بندی همان سرور را پیدا کنید. در هاست اشتراکی ممکن است کاربر مجوز دیدن یا مدیریت سرویس را نداشته باشد. مدیر باید دلیل غیرفعال بودن را بررسی کند؛ روشن‌کردن بی‌برنامه می‌تواند کارهای عقب‌مانده یا تنظیمات دیگر را تحت تأثیر قرار دهد.
برای سروری که گزارش cron را در journal ثبت می‌کند، می‌توانید گزارش مرتبط را با نام صحیح سرویس و زمان مشکل ببینید:
کد / دستورsudo journalctl -u cron --since 'today' --no-pager
این نمونه مخصوص سرویسی به نام
cron است؛ برای crond نام واحد را متناسب تغییر دهید. همه توزیع‌ها جزئیات کار را در journal ثبت نمی‌کنند و ممکن است گزارش در فایل دیگری باشد. ثبت شروع دستور در لاگ cron فقط نشان‌دهنده تلاش برای اجراست، نه موفقیت خود برنامه.قدم سوم: مسیر کامل برنامه و فایل‌ها را بنویسید
محیط cron اغلب شبیه ترمینال تعاملی شما نیست. ممکن است مسیرهای تعریف‌شده در فایل تنظیمات shell بارگذاری نشوند. راهنمای crontab اوبونتو توضیح می‌دهد کار هر جدول با حساب صاحب آن و در محیط تعیین‌شده برای cron اجرا می‌شود. جزئیات نسخه‌های دیگر ممکن است متفاوت باشد. در ترمینال همان حساب، محل برنامه موردنظر را ببینید:
کد / دستورcommand -v python3
این فرمان مسیر برنامه‌ای را که ترمینال فعلی پیدا می‌کند نشان می‌دهد؛ مثلاً
/usr/bin/python3. بررسی کنید همان برنامه و همان نسخه برای کار شما مناسب باشد. سپس در cron به‌جای نام کوتاه، مسیر کامل و تأییدشده برنامه و اسکریپت را قرار دهید. اگر برنامه به محیط مجازی پایتون نیاز دارد، مسیر مفسر همان محیط را به کار ببرید، نه صرفاً Python سیستم.مسیرهای داخل اسکریپت هم مهم‌اند. اجرای دستی ممکن است از پوشه پروژه شروع شود ولی cron از جای دیگری. مسیر کامل فایل‌های ورودی و خروجی را در برنامه تنظیم کنید، یا در خط cron پیش از اجرای برنامه به پوشه درست بروید. نمونه زیر فقط زمانی قابل استفاده است که مسیرها و حساب متعلق به شما باشند:
کد / دستور15 9 * * * cd /home/site && /usr/bin/python3 /home/site/scripts/check.py
بخش
cd وارد پوشه پروژه می‌شود و && باعث می‌شود فقط در صورت موفقیت آن، برنامه اجرا شود. این تغییر را ابتدا با یک کار بی‌خطر در محیط آزمایشی امتحان کنید. دادن دسترسی ریشه یا بازکردن دسترسی همه فایل‌ها راه‌حل مناسب مشکل مسیر نیست.قدم چهارم: خطای خود برنامه را ثبت کنید
اگر پوشه گزارش خصوصی و قابل نوشتن برای همان حساب دارید، نمونه زیر خروجی عادی و خطا را به یک فایل اضافه می‌کند:
کد / دستور15 9 * * * cd /home/site && /usr/bin/python3 /home/site/scripts/check.py >> /home/site/logs/check.log 2>&1
علامت
>> خروجی را به انتهای فایل اضافه می‌کند و 2>&1 خطا را هم به همان مقصد می‌فرستد. پوشه /home/site/logs باید از قبل موجود و خارج از مسیر عمومی سایت باشد. گزارش ممکن است حاوی اطلاعات حساس شود؛ آن را با دسترسی محدود، بدون رمز و با برنامه مناسب برای نگهداری کنترل کنید.بعد از رسیدن نوبت آزمایشی، با دستور زیر آخرین خطوط را بخوانید:
کد / دستورtail -n 50 /home/site/logs/check.log
اگر
command not found دیدید، مسیر برنامه یا محیط را اصلاح کنید. اگر Permission denied دیدید، حساب اجراکننده و مالکیت و مجوز همان فایل یا پوشه را با مدیر بررسی کنید. اگر فایل گزارش ساخته نشده، ممکن است خود پوشه مقصد وجود نداشته باشد یا بخش cd شکست خورده باشد؛ همچنین احتمال دارد زمان‌بندی اصلاً اجرا نشده باشد. برای کار حساس، در اسکریپت پیام شروع و وضعیت پایان و یک شناسه اجرای غیرمحرمانه ثبت کنید.اگر هنوز نتیجه دلخواه حاصل نشد
اسکریپت را با همان حساب و مسیر کامل در محیط آزمایشی اجرا کنید و وابستگی‌های آن، از جمله متغیرهای محیطی، فایل تنظیمات و دسترسی شبکه را بررسی کنید. رمزها را داخل متن crontab یا گزارش عمومی قرار ندهید. برخی دستورها در حالت دستی ورودی از صفحه‌کلید می‌خواهند و در cron منتظر ورودی می‌مانند؛ روش غیرتعاملیِ مستند همان ابزار را استفاده کنید.
ساعت ثبت لاگ، وضعیت پایان و خروجی واقعی برنامه را با نوبت انتظار مقایسه کنید. اگر وظیفه ساخت بکاپ است، وجود یک فایل به‌تنهایی کافی نیست؛ کامل‌شدن و بازیابی آزمایشی هم لازم است. برای سرور مجازی ایران، هشدار مستقل روی نتیجه کار کمک می‌کند اگر اجرای زمان‌بندی‌شده شکست خورد، پیش از نیاز به بکاپ یا گزارش متوجه شوید.
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام