محتوای آموزشی وبلاگ نت‌آرام
در گزارش سرور مجازی ایران پیامی شبیه
state file is already locked می‌بینید و چرخش لاگ انجام نمی‌شود. معمولاً یک اجرای دیگر logrotate همان فایل وضعیت را در اختیار دارد. فایل وضعیت زمان چرخش قبلی را نگه می‌دارد و قفل کمک می‌کند دو اجرا هم‌زمان روی یک برنامه چرخش کار نکنند.وجود قفل همیشه به معنی خرابی نیست؛ ممکن است اجرای قبلی هنوز طبیعی و مشغول فشرده‌سازی باشد. اگر دو زمان‌بند یک دستور را هم‌زمان اجرا کنند، یکی هم ممکن است با کد ۳ متوقف شود. حذف فایل وضعیت یا غیرفعال‌کردن قفل بدون شناخت علت می‌تواند تاریخچه چرخش را خراب یا دو عملیات را هم‌زمان کند. در ادامه دقیقاً مشخص می‌کنیم چه چیزی اجرا شده و چطور تداخل را برطرف کنیم.
۱. زمان، مسیر فایل و پیام کامل را پیدا کنید
در ترمینال با حساب مدیر اجرا کنید:
کد / دستورsystemctl status logrotate.service --no-pager -l
sudo journalctl -u logrotate.service --since '2 days ago' --no-pager
logrotate --version
اگر سیستم شما به‌جای سرویس systemd از cron استفاده می‌کند، لاگ cron را با نام سرویس همان توزیع بررسی کنید؛ نبود واحد
logrotate.service لزوماً خرابی نیست. زمان خطا و مسیر فایل state را از پیام یادداشت کنید. مسیر پیش‌فرض در توزیع‌ها ممکن است /var/lib/logrotate/status یا /var/lib/logrotate.status باشد و دستور با --state می‌تواند مسیر دیگری انتخاب کرده باشد.در بعضی نسخه‌ها وقتی قفل قابل دریافت نیست، logrotate با کد خروج ۳ تمام می‌شود. متن کنار کد مهم است؛ خروج با کد دیگر می‌تواند به تنظیم نامعتبر، مجوز یا دستور پس از چرخش مربوط باشد. راهنمای logrotate اوبونتو رفتار گزینه‌ها را برای آن نسخه توضیح می‌دهد.
۲. اجرای دیگر را شناسایی کنید
کد / دستورps -eo pid,ppid,etime,stat,args | grep '[l]ogrotate'
systemctl list-timers --all | grep -i logrotate
systemctl cat logrotate.service logrotate.timer
خروجی اول شماره پردازش، والد، مدت اجرا و دستور را نشان می‌دهد. دو دستور بعدی اگر timer و service موجود باشند زمان‌بندی و فرمانشان را نمایش می‌دهند. نبود واحد خطا را توضیح نمی‌دهد؛ ممکن است cron یا ابزار دیگری آن را اجرا کند. به مسیر فایل تنظیم و گزینه
--state هر پردازش نگاه کنید تا مطمئن شوید هر دو درباره همان فایل حرف می‌زنند.اگر ابزار
کد / دستورfuser نصب است، مسیر واقعی اعلام‌شده در لاگ را جایگزین کنید:sudo fuser -v /var/lib/logrotate/status
این خروجی پردازش‌هایی را که فایل را باز کرده‌اند نشان می‌دهد؛ بازبودن فایل به‌تنهایی همیشه اثبات نمی‌کند همان پردازش قفل مورد نظر را نگه داشته است. در صورت وجود
lslocks، خروجی sudo lslocks نیز می‌تواند نوع قفل و صاحب آن را نشان دهد. اگر پردازش تمام شده باشد، ممکن است دیگر در خروجی دیده نشود؛ زمان‌بندی و لاگ را برای نوبت بعد ثبت کنید.۳. اگر اجرای قبلی هنوز کار می‌کند
به مدت اجرا، نوع کار و لاگ نگاه کنید. فشرده‌سازی فایل بزرگ یا دستور
postrotate کند می‌تواند اجرای معمولی را طولانی کند. چند دقیقه بعد همان ps را تکرار کنید و ببینید زمان و وضعیت فرایند تغییر می‌کند یا نه. اگر کار در حال پیشرفت است، منتظر پایان آن بمانید و اجرای دستی دیگری شروع نکنید. فضای آزاد دیسک را با df -h نیز ببینید؛ فشرده‌سازی یا ساخت فایل جدید ممکن است به فضای کافی نیاز داشته باشد.اگر کار مدت غیرعادی بدون پیشرفت مانده، نام فرایند فرزند و علت انتظار را بررسی کنید. مثلاً در صورت گیرکردن یک ارسال شبکه‌ای در اسکریپت postrotate، اتصال یا timeout همان اسکریپت را اصلاح کنید. توقف اجباری ممکن است چرخش را نیمه‌کاره بگذارد؛ پیش از پایان‌دادن به آن با مسئول سرویس، نتیجه روی فایل‌های لاگ و روش بازیابی را روشن کنید. هر PID را صرفاً به‌خاطر نام مشابه kill نکنید.
۴. اگر دو زمان‌بند یک کار را شروع می‌کنند
ابتدا زمان اجرای timer، فایل‌های cron سیستم و job اختصاصی برنامه را مقایسه کنید:
کد / دستورsystemctl list-timers --all
sudo ls -l /etc/cron.daily /etc/cron.d
sudo crontab -l
وجود یک فایل cron به‌تنهایی نشان نمی‌دهد واقعاً اجرا می‌شود؛ محتوای آن و وضعیت cron را بخوانید. خروجی crontab فقط jobهای کاربر root است و کاربران دیگر یا ابزار مدیریت پیکربندی می‌توانند job داشته باشند. اگر همان تنظیم و همان state هم از timer و هم از cron فراخوانی می‌شود، مسئولیت را به یک زمان‌بند مشخص بسپارید و job تکراری اختصاصی خودتان را با روش مدیریت همان سیستم غیرفعال یا زمانش را اصلاح کنید. بسته سیستم یا timer استاندارد را بدون فهم وابستگی‌ها حذف نکنید.
اگر یک job اختصاصی عمداً جداست، باید فایل‌های لاگ آن با برنامه اصلی هم‌پوشانی نداشته باشند و فایل state مستقل داشته باشد. دو state مجزا برای چرخش یک لاگ مشترک، قفل مشترک را دور می‌زند و خود می‌تواند تداخل و حذف یا چرخش دوباره بسازد. پیش از جداسازی، فایل تنظیم و مالک هر لاگ را بررسی کنید.
۵. تنظیم را بدون چرخش واقعی بررسی کنید
کد / دستورsudo logrotate -d /etc/logrotate.conf
حالت debug در نسخه‌های معمول logrotate تنظیم و تصمیم‌ها را نمایش می‌دهد و لاگ‌ها یا فایل state را تغییر نمی‌دهد. مسیر پیکربندی نمونه را در صورت تفاوت عوض کنید. پیام‌هایی مثل تکرار تعریف یک لاگ یا خطای مسیر و مجوز را جداگانه برطرف کنید؛ debug نشان نمی‌دهد یک چرخش واقعی و اجرای postrotate حتماً موفق خواهد شد.
گزینه
--wait-for-state-lock در بعضی نسخه‌ها اجازه می‌دهد اجرا منتظر قفل بماند، اما انتظار می‌تواند طولانی یا نامحدود شود و جای اصلاح زمان‌بندی تکراری را نمی‌گیرد. قبل از استفاده، وجود آن را در logrotate --help و اثرش را در job خود بررسی کنید. --skip-state-lock و حذف فایل state راه‌حل عمومی نیستند؛ قفل بازشده روی فایل حذف‌شده هم ممکن است هنوز برای پردازش قبلی وجود داشته باشد.۶. نتیجه را در اجرای بعدی تأیید کنید
بعد از اصلاح زمان‌بندی، زمان اجرای بعدی را ببینید و پس از آن journal یا لاگ cron را بررسی کنید. نبود خطای قفل، سالم‌بودن چرخش را به‌تنهایی ثابت نمی‌کند: تاریخ فایل‌های چرخیده، فضای دیسک و ادامه نوشته‌شدن لاگ جدید توسط برنامه را هم کنترل کنید. اگر نیاز به آزمون عملی است، آن را روی یک فایل و پیکربندی آزمایشی جدا با state مخصوص انجام دهید؛ اجرای اجباری روی لاگ‌های واقعی می‌تواند خلاف برنامه نگه‌داری فایل‌ها عمل کند.
اگر با وجود نبود اجرای هم‌زمان خطا تکرار می‌شود، مسیر state، نوع فایل‌سیستم و مجوز را با لاگ دقیق بررسی کنید. برای لاگ‌های کانتینر، سازوکار Docker ممکن است مستقل از logrotate سیستم باشد؛ راهنمای چرخش لاگ Docker آن مسیر جداگانه را توضیح می‌دهد.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام