محتوای آموزشی وبلاگ نت‌آرام
پس از راه‌اندازی مجدد یا انتقال برنامه، سرویس لینوکس دیگر شروع نمی‌شود. در گزارش آن پیامی شبیه
Failed to load environment files: No such file or directory می‌بینید. معمولاً سرویس انتظار دارد تنظیماتش را از یک فایل مشخص بخواند، اما فایل در مسیر مورد انتظار نیست یا مسیر در تنظیم سرویس اشتباه است.گاهی فایل از بین نرفته؛ روی دیسکی است که هنوز نصب نشده یا نام آن در نسخه جدید برنامه تغییر کرده است. ساختن یک فایل خالی ممکن است خطای اول را پنهان کند ولی برنامه را بدون تنظیمات ضروری اجرا کند. این راهنما کمک می‌کند علت واقعی را پیدا کنید و تنها همان قسمت را اصلاح کنید.
دستورها برای سرویس سیستمی systemd روی Linux نوشته شده‌اند. به SSH و دسترسی sudo نیاز دارید.
myapp.service و مسیرهای /etc/myapp/ فقط نمونه‌اند؛ نام واقعی سرویس و مسیرهای خودتان را جایگزین کنید. اگر سرویس توسط نرم‌افزار دیگری نصب شده، پیش از ایجاد فایل از راهنمای همان نسخه و نسخه پشتیبان کمک بگیرید.۱. پیام و سرویس درست را پیدا کنید
کد / دستورsudo systemctl status myapp.service --no-pager -l
در خروجی، نام سرویس و خطای نزدیک به آخرین زمان شروع را ببینید. سپس گزارش بوت فعلی را بخوانید:
کد / دستورsudo journalctl -u myapp.service -b --no-pager -n 100
اگر پیام به فایل محیطی اشاره دارد، مسیر کامل و ساعت آن را یادداشت کنید. اگر به جای آن
203/EXEC می‌بینید، اجرای فایل برنامه علت دیگری دارد؛ راهنمای خطای 203/EXEC را دنبال کنید. گزارش ممکن است اطلاعات داخلی برنامه داشته باشد؛ رمزها و نشانی‌های خصوصی را در تیکت منتشر نکنید.۲. systemd دقیقاً کدام مسیر را می‌خواهد؟
فایل اصلی سرویس و فایل‌های تکمیلی آن را ببینید:
کد / دستورsudo systemctl cat myapp.service
در بخش
کد / دستور[Service] به همه خط‌های EnvironmentFile= دقت کنید. ممکن است چند فایل یا یک override وجود داشته باشد. برای دیدن اطلاعات مسیرهایی که systemd برای این سرویس ثبت کرده است:systemctl show myapp.service -p EnvironmentFiles
مثلاً خط زیر یک فایل مشخص را اجباری معرفی می‌کند:
کد / دستورEnvironmentFile=/etc/myapp/app.env
اگر قبل از مسیر یک علامت منفی باشد، مانند
EnvironmentFile=-/etc/myapp/optional.env، نبودن آن فایل از نظر systemd نادیده گرفته می‌شود. این موضوع به معنی اختیاری بودن تنظیمات برای خود برنامه نیست. پیش از تغییر، همه فایل‌ها و ترتیب آن‌ها را ثبت کنید؛ ممکن است یک تنظیم تکمیلی مقادیر قبلی را تغییر دهد.برای سرویس‌هایی که با
systemctl --user اجرا می‌شوند، مدیر سرویس متعلق به همان کاربر است؛ به جای دستورهای سیستمی این مقاله، همان عملیات را با systemctl --user در نشست آن کاربر و مطابق راهنمای برنامه انجام دهید. خواننده فایل و مجوزها در دو حالت می‌تواند متفاوت باشد.۳. وجود مسیر و دیسک آن را بررسی کنید
در سرور، مسیر واقعی فایل مورد انتظار را جایگزین کنید:
کد / دستورsudo ls -ld /etc/myapp /etc/myapp/app.env
اگر فایل وجود دارد، مالک و مجوز آن را بدون چاپ محتوا ببینید:
کد / دستورsudo stat -c '%a %U %G %n' /etc/myapp/app.env
اگر مسیر شامل چند پوشه است، این دستور وضعیت اجزای مسیر را نشان می‌دهد:
کد / دستورsudo namei -l /etc/myapp/app.env
پیام
کد / دستورNo such file or directory می‌تواند مربوط به پوشه میانی هم باشد. اگر فایل روی دیسکی مانند /srv/config است، ببینید آن مسیر واقعاً روی فایل‌سیستم مورد انتظار قرار گرفته است:findmnt -T /srv/config
برای مسیری که قرار است خودش mountpoint باشد:
کد / دستورmountpoint /srv/config
اگر دیسک نصب نشده، ابتدا علت mount و ترتیب راه‌اندازی را اصلاح کنید. ساختن یک فایل همنام در پوشه خالی زیر mountpoint ممکن است بعد از نصب دیسک ناپدید شود و مشکل را پیچیده‌تر کند. systemd فایل EnvironmentFile را از دید مدیر سرویس و پیش از اعمال بعضی تغییرات محیط فایل‌سیستم سرویس می‌خواند؛ مسیر داخل container یا
RootDirectory را بدون تطبیق با مستند نسخه، معادل مسیر میزبان فرض نکنید.۴. اگر فایل حذف شده است
بهترین راه، بازگرداندن فایل درست همان برنامه از نسخه پشتیبان معتبر یا روش نصب مستند است. اگر نسخه پشتیبان دارید، ابتدا فایل و مالک آن را در محل بکاپ مشخص و با مسئول برنامه تطبیق دهید. پیش از جایگزینی از وضعیت فعلی و تنظیمات موجود نسخه پشتیبان بگیرید؛ فایل یک سرویس دیگر را به این مسیر کپی نکنید.
برای برنامه سفارشی تازه‌ای که خودتان نوشته‌اید و می‌دانید فقط به مقادیر غیرمحرمانه زیر نیاز دارد، ساخت یک فایل نمونه می‌تواند مشکل را حل کند. این مثال برای بازسازی رمزهای گمشده یا تنظیمات ناشناخته مناسب نیست. اگر پوشه واقعی از قبل وجود دارد و متعلق به برنامه است، فقط فایل تازه را بدون رونویسی ایجاد کنید:
کد / دستورsudo sh -c 'umask 077; set -C; : > /etc/myapp/app.env'
این دستور اگر فایل از قبل وجود داشته باشد باید خطا بدهد. اگر پوشه وجود ندارد، ابتدا بر اساس راهنمای برنامه و با مجوزهای مناسب آن را بسازید؛ نام و مسیر نمونه را به‌صورت خودکار در هر سروری ایجاد نکنید. حالا فایل تازه را با ویرایشگر باز کنید:
کد / دستورsudo nano /etc/myapp/app.env
برای این برنامه فرضی، مقدارهای غیرمحرمانه می‌توانند این‌گونه باشند:
کد / دستورAPP_MODE=production
APP_PORT=8080
نام متغیرها و مقدارهای واقعی را از مستند برنامه بگیرید. در nano با Ctrl+O و Enter ذخیره و با Ctrl+X خارج شوید. فایل EnvironmentFile مشابه فایل دستور shell نیست؛ انتظار اجرای دستورها یا جایگزینی خودکار متغیرهای shell در مقدارها را نداشته باشید. برای مقدار دارای فاصله یا کاراکتر ویژه، قواعد و نسخه systemd خود را طبق مستند رسمی بررسی کنید.
مجوز فایل را با همان دستور
stat بررسی کنید. systemd توصیه می‌کند رمز و کلید محرمانه را از راه متغیر محیطی به سرویس ندهید، چون این مقادیر ممکن است از مسیرهای دیگری هم قابل مشاهده شوند. در صورت پشتیبانی نسخه و برنامه، از مکانیزم‌های اختصاصی credential مانند LoadCredential= یا راهکار مدیریت اسرار سازمان استفاده کنید. فایل موجودی را که رمز دارد در لاگ چاپ نکنید.۵. اگر فایل وجود دارد ولی مسیر سرویس اشتباه است
فرض کنید مستندات و فایل سالم تأیید می‌کنند مسیر درست
کد / دستور/etc/myapp/app.env است، ولی سرویس به مسیر دیگری اشاره می‌کند. اگر سرویس متعلق به بسته نصب‌شده است، به‌جای ویرایش مستقیم فایل بسته، یک override بسازید:sudo systemctl edit myapp.service
در حالتی که فقط یک EnvironmentFile برای این سرویس لازم است، می‌توانید در فایل تکمیلی بنویسید:
کد / دستور[Service]
EnvironmentFile=
EnvironmentFile=/etc/myapp/app.env
خط خالی اول فهرست قبلی EnvironmentFile را پاک می‌کند و خط دوم مسیر درست را اضافه می‌کند. اگر چند فایل لازم دارید، این مثال را همان‌طور اجرا نکنید؛ باید بعد از خط خالی، تمام مسیرهای موردنیاز و ترتیبشان را دوباره مشخص کنید. در غیر این صورت تنظیمات دیگر برنامه حذف می‌شوند. پس از ذخیره:
کد / دستورsudo systemctl daemon-reload
کد / دستورsystemctl show myapp.service -p EnvironmentFiles
مسیر جدید باید در خروجی دیده شود. اگر تغییر حاصل نشد، فایل override را با
systemctl cat دوباره بخوانید و نحوه ذخیره ویرایشگر را بررسی کنید.۶. اگر فایل پس از هر ریبوت ناپدید می‌شود
مسیرهایی مانند
کد / دستور/run معمولاً برای داده موقت‌اند و ممکن است در راه‌اندازی مجدد خالی شوند. ببینید کدام نصب‌کننده، سرویس یا ابزار استقرار باید فایل را هنگام بوت بسازد. اگر فایل از یک سرویس سازنده، volume یا ابزار مدیریت اسرار تأمین می‌شود، وضعیت آن جزء و ترتیب آغازش را بررسی کنید:systemctl list-dependencies myapp.service
این فهرست شروع خوبی برای شناخت وابستگی‌هاست، ولی به‌تنهایی ثابت نمی‌کند سازنده فایل با موفقیت اجرا شده است. گزارش سرویس سازنده و مستند همان برنامه را ببینید. اگر انتظار دارید فایل قبل از شروع برنامه ساخته شود، تنظیم وابستگی و زمان آماده شدن آن را در روش استقرار اصلاح کنید. جایگزین کردن فایل موقت با نسخه دائمی بدون دانستن مسئول تولید آن ممکن است تنظیم قدیمی یا ناامن ایجاد کند.
۷. راه‌اندازی دوباره و کنترل نتیجه
وقتی مسیر، محتوا و مجوزها طبق مستند برنامه درست شد، در بازه مجاز سرویس را راه‌اندازی مجدد کنید:
کد / دستورsudo systemctl restart myapp.service
کد / دستورsudo systemctl status myapp.service --no-pager -l
اگر خطای فایل برطرف شده اما برنامه هنوز اجرا نمی‌شود، گزارش تازه
journalctl را بخوانید؛ ممکن است یک مقدار لازم، مجوز فایل برنامه یا اتصال دیتابیس مشکل داشته باشد. در پایان، علاوه بر وضعیت active، عملکرد واقعی مثل باز شدن صفحه یا انجام یک کار آزمایشی را بررسی کنید.این راهنما برای برنامه‌های systemd روی سرور مجازی ایران و سرور اختصاصی ایران قابل استفاده است. توضیح ترتیب خواندن فایل و رفتار علامت منفی را در مستند رسمی systemd.exec ببینید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام