مشکل در start نشدن سرویس exim در دایرکت ادمین

پاسخ کوتاه: اگر سرویس exim روی دایرکت‌ادمین استارت نمی‌شود، قبل از هر کاری خروجی systemctl status exim و فایل‌های /var/log/exim/mainlog و /var/log/exim/paniclog را بخوانید؛ exim تقریباً همیشه دلیل بالا نیامدنش را دقیقاً همان‌جا می‌نویسد. رایج‌ترین علت‌ها هم مشخص‌اند: خطای نحوی در exim.conf بعد از یک ویرایش دستی، نبودن فایل‌های لازم در /etc/virtual، اشغال بودن پورت ۲۵ توسط سرویس دیگر، نبودن یا غیرقابل‌خواندن بودن فایل گواهی TLS، پر شدن دیسک، و در نهایت یک به‌روزرسانی نیمه‌کاره که فایل PID یا lock را جا گذاشته است. اگر سرویس بالاست و فقط ایمیل‌ها ارسال نمی‌شوند، مشکل جای دیگری است و در بخش پایانی همین مطلب آمده.

پیام «Exim dead but pid file exists» یعنی چه؟

این پیام از دوران اسکریپت‌های init قدیمی باقی مانده و معنایش ساده است: سیستم یک فایل PID یا lock برای exim پیدا کرده، اما پروسه‌ای که آن فایل به آن اشاره می‌کند دیگر زنده نیست. یعنی exim یا اصلاً بالا نیامده یا بعد از استارت کرش کرده و فایل قفل را پاک نکرده است. خود پیام علت را نمی‌گوید، پس نباید به آن اکتفا کرد.

روی سیستم‌های امروزی (AlmaLinux، Rocky Linux، Ubuntu و Debian) که همه با systemd کار می‌کنند، معادل همین وضعیت را به شکل Active: failed یا Active: inactive (dead) در خروجی systemctl status exim می‌بینید. دستورهای قدیمی service exim start و /etc/init.d/exim start هنوز روی خیلی از سرورها جواب می‌دهند، ولی فقط یک لایه سازگاری‌اند و خطای واقعی را نشان نمی‌دهند؛ از systemctl استفاده کنید.

قدم اول: لاگ و ژورنال را بخوانید

روی سرورهایی که با لایسنس دایرکت‌ادمین مدیریت می‌شوند نام سرویس معمولاً exim است. (روی دبیان و اوبونتو اگر بسته خود توزیع نصب باشد نام یونیت exim4 است؛ اگر مطمئن نیستید با systemctl list-units --type=service | grep -i exim نام دقیق را ببینید.) با این دستورها وضعیت و دلیل خطا را ببینید:

• systemctl status exim -l --no-pager — وضعیت سرویس و چند خط آخر خطا
• journalctl -u exim -n 100 --no-pager — تاریخچه کامل‌تر تلاش‌های استارت
• tail -n 100 /var/log/exim/mainlog — لاگ اصلی تحویل و اتصال‌ها
• tail -n 50 /var/log/exim/paniclog — مهم‌ترین فایل؛ خطاهای مرگبار زمان راه‌اندازی اینجا می‌نشینند

اگر باز هم چیزی دستگیرتان نشد، exim را دستی و در حالت دیباگ اجرا کنید. این دستور در پیش‌زمینه اجرا می‌شود و با Ctrl+C متوقف می‌شود؛ ضمناً چون خودش پورت را می‌گیرد، اول سرویس را متوقف کنید:

systemctl stop exim
exim -bd -d+all

تا وقتی این پروسه دستی در حال اجراست سرویس اصلی خاموش است و سرور هیچ ایمیلی نمی‌پذیرد، پس به‌محض تمام شدن دیباگ سرویس را برگردانید:

systemctl start exim

علت ۱: خطای نحوی در exim.conf

شایع‌ترین سناریو این است که کسی برای اضافه کردن یک روتر یا تغییر محدودیت حجم ایمیل، /etc/exim.conf را دستی ویرایش کرده و یک براکت یا کلمه کلیدی جا افتاده است. صحت کانفیگ را با این دستور بسنجید:

exim -bV

اگر ایرادی باشد، exim شماره خط دقیق را چاپ می‌کند. راه‌حل، اصلاح همان خط یا برگرداندن نسخه پشتیبان است. اگر پشتیبان ندارید یا فایل آن‌قدر دستکاری شده که اصلاحش نمی‌ارزد، کانفیگ رسمی را با CustomBuild دوباره بسازید — کاری که به دسترسی روت نیاز دارد و روی سرور مجازی یا سرور اختصاصی امکان‌پذیر است.

بازسازی اصولی exim.conf با CustomBuild

این کار exim.conf را بازنویسی می‌کند، پس اول نسخه فعلی را کنار بگذارید. ترتیب درست روی CustomBuild 2.0 این است:

cp -a /etc/exim.conf /etc/exim.conf.bak
cd /usr/local/directadmin/custombuild
./build update
./build set eximconf yes
./build set spamassassin yes
./build exim_conf
systemctl restart exim

چند نکته که معمولاً از قلم می‌افتد:

• ./build exim_conf فقط فایل‌های کانفیگ را می‌سازد؛ ./build exim خودِ باینری exim را دوباره کامپایل می‌کند. برای خطای نحوی کانفیگ، اولی کافی است.
• خط ./build set spamassassin yes باعث می‌شود کانفیگ تولیدشده بخش‌های مربوط به اسکن هرزنامه را هم داشته باشد. اگر SpamAssassin روی سرور نصب و فعال نیست، این گزینه را yes نگذارید؛ وگرنه کانفیگ به سرویسی ارجاع می‌دهد که بالا نیست و در mainlog خطای اسکن می‌بینید. برای نصب و راه‌اندازی درست آن نصب SpamAssassin در دایرکت ادمین را ببینید.
• در راهنماهای قدیمی خطی مثل ./build set eximconf_release 4.4 هم دیده می‌شود. این عدد به نسخه فایل کانفیگ رسمی دایرکت‌ادمین اشاره می‌کند و با گذشت زمان تغییر کرده است، پس آن را روی عدد قدیمی قفل نکنید. برای دیدن مقداری که الان روی سرور شما تنظیم است ./build options را در همان مسیر custombuild اجرا کنید و اگر روی نسخه‌ای قدیمی گیر کرده، به مقدار پیش‌فرض همان CustomBuildی که نصب دارید برگردانید.
• پشتیبان‌گیری را به exim.conf محدود نکنید. بقیه فایل‌های کانفیگ رسمی exim هم در این مرحله به نسخه رسمی برمی‌گردند، پس اگر آن‌ها را دستکاری کرده بودید، قبل از اجرا از همه‌شان کپی بگیرید.
• بعد از بازسازی حتماً یک بار exim -bV بزنید و paniclog را نگاه کنید؛ ری‌استارت موفق به‌تنهایی به معنای سالم بودن کانفیگ نیست.

برای اینکه تغییرات سفارشی‌تان با هر به‌روزرسانی از بین نرود، آن‌ها را در فایل‌های custom مثل /etc/exim.variables.conf.custom بگذارید، نه در خود exim.conf. فایل‌های custom را CustomBuild بازنویسی نمی‌کند.

روش قدیمی‌تری هم هست که در نوشته‌های مربوط به CustomBuild 1.2 تکرار شده: دانلود مستقیم exim.conf و exim.pl با wget از سرور دایرکت‌ادمین و بعد chmod 755 /etc/exim.pl. این روش را توصیه نمی‌کنیم. CustomBuild 1.2 سال‌هاست منسوخ شده، آن آدرس‌ها روی http و بدون رمزنگاری بودند، و فایلی که دستی جایگزین می‌کنید ممکن است با نسخه exim نصب‌شده روی سرور هم‌خوان نباشد و دقیقاً همان استارت نشدنی را بسازد که دنبال رفعش هستید. اگر روی سروری هستید که هنوز CustomBuild 1.2 دارد، کار درست ارتقا به CustomBuild 2.0 است، نه جایگزینی دستی فایل کانفیگ.

علت ۲: فایل‌های لازم در /etc/virtual وجود ندارند

کانفیگ رسمی دایرکت‌ادمین در چند جا به فایل‌های داخل /etc/virtual ارجاع می‌دهد: لیست‌های بلاک و وایت‌لیست فرستنده و دامنه، فهرست RBLها و فایل محدودیت ارسال. اگر این فایل‌ها پاک شده باشند یا مالکشان درست نباشد، exim یا موقع خواندن کانفیگ خطا می‌دهد یا بالا می‌آید و بعد در paniclog از باز نشدن فایل شکایت می‌کند. اول ببینید چه چیزی هست:

ls -l /etc/virtual/

ساده‌ترین راه درست کردنشان همان ./build exim_conf بالاست، چون CustomBuild خودش فایل‌های غایب را می‌سازد. اگر خواستید دستی بسازید:

mkdir -p /etc/virtual
cd /etc/virtual
touch blacklist_domains whitelist_from use_rbl_domains bad_sender_hosts blacklist_senders whitelist_domains whitelist_hosts whitelist_senders
if [ ! -e limit ]; then echo 0 > limit; fi
mkdir -p usage
chown mail:mail blacklist_domains whitelist_from use_rbl_domains bad_sender_hosts blacklist_senders whitelist_domains whitelist_hosts whitelist_senders limit usage

فایل limit سقف ارسال روزانه پیش‌فرض را نگه می‌دارد و مقدار 0 یعنی بدون محدودیت؛ اگر قبلاً روی سرور سقف مشخصی تعریف کرده بودید، همان عدد را از پشتیبان برگردانید و با 0 جایگزینش نکنید. پوشه usage هم شمارنده ارسال کاربران است.

علت ۳: پورت ۲۵ از قبل اشغال شده است

اگر در لاگ عبارتی شبیه socket bind() to port 25 failed: Address already in use دیدید، سرویس دیگری پورت را گرفته است. معمولاً یا Postfix یا Sendmail هنوز فعال است، یا یک پروسه قدیمی exim از استارت قبلی باقی مانده:

• ss -lntp | grep ':25' یا lsof -i :25 — پیدا کردن پروسه اشغال‌کننده
• ps aux | grep '[e]xim' — بررسی پروسه‌های باقی‌مانده exim
• systemctl disable --now postfix — غیرفعال کردن دائمی MTA رقیب (اگر Sendmail بود، همین دستور را با نام sendmail بزنید)

دستور آخر را کورکورانه نزنید: اول از خروجی ss یا lsof مطمئن شوید دقیقاً همان سرویس پورت ۲۵ را گرفته است. روی سروری که عمداً با Postfix ایمیل می‌فرستد، خاموش کردن آن یعنی قطع شدن کل ارسال ایمیل.

پروسه‌های سرگردان exim را با kill ببندید و فقط در صورت پاسخ ندادن سراغ kill -9 بروید. این دستورها به دسترسی روت نیاز دارند؛ روی هاست اشتراکی چنین دسترسی‌ای وجود ندارد و باید موضوع را به مدیر سرور بسپارید.

علت ۴: فایل گواهی TLS نیست یا خوانده نمی‌شود

خطاهایی مثل TLS error on connection یا ناتوانی در بارگذاری گواهی، معمولاً بعد از تغییر hostname یا تمدید گواهی سرور پیش می‌آید: مسیر داخل کانفیگ به فایلی اشاره می‌کند که دیگر وجود ندارد، یا کاربر exim اجازه خواندن کلید خصوصی را ندارد. اول وجود و مالکیت فایل‌ها را ببینید:

ls -l /etc/exim.cert /etc/exim.key

در دایرکت‌ادمین این فایل‌ها باید متعلق به کاربر سرویس ایمیل باشند و کلید خصوصی نباید برای همه خواندنی باشد:

• chown mail:mail /etc/exim.cert /etc/exim.key
• chmod 600 /etc/exim.key

اگر خود فایل گم شده، گواهی سرور را از بخش مدیریت دایرکت‌ادمین دوباره صادر یا نصب کنید تا مسیرها بازسازی شوند. اگر به‌جای گواهی self-signed یک گواهی SSL معتبر می‌خواهید، نصب آن روی دایرکت‌ادمین هم انجام می‌شود.

علت ۵: پر شدن دیسک یا تمام شدن inode

exim برای نوشتن در spool و لاگ به فضای آزاد نیاز دارد و بدون آن بالا نمی‌آید. هر دو مورد را چک کنید:

• df -h — فضای آزاد پارتیشن‌ها
• df -i — تعداد inode آزاد (صف ایمیل با هزاران فایل کوچک، inode را زودتر از فضا تمام می‌کند)
• du -sh /var/log/* | sort -h — پیدا کردن لاگ‌های حجیم
• همین پر شدن دیسک اگر در سطح سهمیهٔ یک کاربر رخ دهد، به تعلیق شدن اکانت در دایرکت ادمین هم منجر می‌شود

هشدار: پیش از حذف هر فایلی مطمئن شوید چه چیزی را پاک می‌کنید. حذف نسنجیده محتویات /var/spool/exim یعنی از دست رفتن ایمیل‌های در صف؛ این کار برگشت‌پذیر نیست.

علت ۶: به‌روزرسانی ناتمام و فایل قفل باقی‌مانده

اگر ./build exim نصفه‌کاره قطع شده باشد، ممکن است باینری یا مجوزهای spool ناسازگار بمانند. وقتی مطمئن شدید هیچ پروسه exim فعالی وجود ندارد، فایل‌های قفل را پاک کنید و سرویس را دوباره بسازید:

rm -f /var/lock/subsys/exim
rm -f /run/exim.pid
chown -R mail:mail /var/spool/exim
cd /usr/local/directadmin/custombuild
./build update
./build exim

سه نکته: مسیر /var/lock/subsys/ یادگار CentOS 6 است و روی توزیع‌های امروزی معمولاً اصلاً وجود ندارد — اگر نبود، نگران نباشید. مسیر /var/run هم روی سیستم‌های systemd فقط یک لینک به /run است، پس /var/run/exim.pid و /run/exim.pid یک فایل‌اند. و مهم‌تر اینکه محل دقیق فایل PID بسته به نسخه دایرکت‌ادمین و یونیت نصب‌شده فرق می‌کند و ممکن است اصلاً داخل مسیر spool باشد؛ پیش از حذف، با systemctl show exim -p PIDFile ببینید سیستم دنبال کدام فایل می‌گردد و همان را پاک کنید.

اگر همین ./build update با پیام Unable to establish SSL Connection شکست خورد، ایراد از گواهی‌های ریشه، ساعت سیستم یا پورت ۴۴۳ خروجی سرور است؛ همان عواملی که در رفع خطای SSL Connection در دایرکت ادمین تست و رفع می‌شوند.

بعد از رفع مشکل: چطور مطمئن شویم درست کار می‌کند؟

سرویس را ری‌استارت کنید و وضعیت و صف را ببینید:

• systemctl restart exim && systemctl is-active exim
• exim -bpc — تعداد پیام‌های در صف
• exim -bt user@example.com — تست مسیریابی یک آدرس بدون ارسال واقعی
• tail -f /var/log/exim/mainlog — مشاهده زنده تحویل‌ها

سرویس بالاست ولی ایمیل‌ها ارسال نمی‌شوند

گاهی systemctl is-active exim می‌گوید سرویس فعال است، اما ایمیل‌های خروجی برنمی‌گردند، در صف می‌مانند یا مقصد ردشان می‌کند. این دیگر مشکل استارت نیست و ترتیب بررسی‌اش فرق می‌کند. سه چیز را به همین ترتیب چک کنید.

۱. آی‌پی سرور بلاک شده است؟

قبل از دست زدن به کانفیگ، مطمئن شوید آی‌پی سرور در بلک‌لیست‌های ایمیل نیفتاده باشد؛ اگر افتاده باشد هر تغییری در exim.conf بدهید باز هم ایمیل‌ها رد می‌شوند. نشانه‌اش هم در mainlog پیداست: پیام رد شدن از سمت سرور مقصد که معمولاً نام همان بلک‌لیست را ذکر می‌کند. روش بررسی و خارج شدن از این لیست‌ها را در رفع بلاک شدن آی‌پی سرور ایمیل جداگانه توضیح داده‌ایم.

۲. DNS سرور و رکوردهای دامنه سالم‌اند؟

exim برای پیدا کردن مقصد هر ایمیل باید رکورد MX را resolve کند. اگر /etc/resolv.conf خالی باشد یا به resolverهایی اشاره کند که دیگر جواب نمی‌دهند، ایمیل‌ها در صف می‌مانند و در mainlog خطاهای مربوط به پیدا نشدن میزبان مقصد و Unrouteable address ظاهر می‌شود:

cat /etc/resolv.conf
dig MX example.com +short

اگر dig نصب نیست، host -t mx example.com هم همین کار را می‌کند. بعد از سالم بودن resolver، نوبت رکوردهای خود دامنه است: از بخش DNS Management دایرکت‌ادمین بررسی کنید که رکوردهای MX و A و SPF دامنه درست تعریف شده باشند. دامنه‌ای که MX ندارد یا MX آن به میزبان اشتباه اشاره می‌کند، ایمیلش تحویل داده نمی‌شود حتی اگر exim کاملاً سالم باشد.

۳. exim.conf قدیمی مانده است

اگر آی‌پی سالم است و DNS هم درست کار می‌کند، احتمال بعدی این است که کانفیگ exim سرور سال‌هاست به‌روز نشده و با ACLها و سیاست‌های امروزی هم‌خوان نیست. در این حالت همان روال «بازسازی اصولی exim.conf با CustomBuild» که بالاتر آمد را اجرا کنید: پشتیبان بگیرید، ./build exim_conf بزنید، سرویس را ری‌استارت کنید و بعد یک ایمیل آزمایشی بفرستید و mainlog را زنده تماشا کنید.

پیشگیری از تکرار

سه عادت ساده جلوی بیشتر این خطاها را می‌گیرد: قبل از هر ویرایش از exim.conf نسخه پشتیبان بگیرید و بعد از ویرایش حتماً exim -bV بزنید؛ تغییرات سفارشی را فقط در فایل‌های custom نگه دارید تا به‌روزرسانی‌ها آن‌ها را پاک نکنند؛ و برای فضای دیسک و در دسترس بودن پورت ۲۵ مانیتورینگ بگذارید تا قبل از قطع شدن ایمیل‌ها خبردار شوید. همچنین با systemctl enable exim مطمئن شوید سرویس بعد از ری‌بوت خودکار بالا می‌آید.

اگر لاگ‌ها را خواندید و باز هم exim بالا نیامد، یا نمی‌خواهید روی یک سرور ایمیل فعال ریسک کنید، بهتر است کار را به تیم فنی بسپارید. خدمات پشتیبانی و مدیریت سرور آنلاین سرور شامل عیب‌یابی و رفع مشکل کنترل‌پنل‌های میزبانی است و می‌تواند همین مسیر عیب‌یابی را روی سرور شما دنبال کند.