آموزش اجرای خودکار سرور MTA با systemd

اگر سرور MTA را مستقیماً از SSH اجرا کنید، بعد از ریبوت VPS باید دوباره وارد سرور شوید و آن را به‌صورت دستی اجرا کنید. همچنین اگر Process به‌دلیل خطا متوقف شود، سرور تا زمان اجرای مجدد آفلاین باقی می‌ماند.

با ساخت یک Service در systemd می‌توان سرور MTA را مانند سایر سرویس‌های لینوکس مدیریت کرد؛ یعنی سرور بعد از روشن‌شدن VPS به‌صورت خودکار اجرا شود، درصورت Crash دوباره بالا بیاید و وضعیت و Logهای آن از طریق systemctl و journalctl قابل بررسی باشد.

در این آموزش ساخت سرویس systemd برای MTA Server، تنظیم کاربر اختصاصی، اجرای خودکار پس از Boot، Restart خودکار، مشاهده Logها، عیب‌یابی خطاهای رایج و مدیریت سرور را مرحله‌به‌مرحله بررسی می‌کنیم.

systemd چیست و چه کاربردی برای MTA دارد؟

systemd مدیر سرویس و فرایند در بسیاری از توزیع‌های امروزی لینوکس است. سرویس‌هایی مانند SSH، وب‌سرور، دیتابیس و برنامه‌های Server را می‌توان از طریق آن اجرا و مدیریت کرد.

پس از ساخت Service برای MTA می‌توان از دستورهای استاندارد زیر استفاده کرد:

systemctl start mtaserver
systemctl stop mtaserver
systemctl restart mtaserver
systemctl status mtaserver

همچنین می‌توان سرویس را برای اجرای خودکار هنگام Boot فعال کرد.

مزایای اجرای MTA با systemd

اجرای خودکار MTA بعد از روشن‌شدن VPS
Restart خودکار بعد از Crash
مدیریت ساده Start، Stop و Restart
مشاهده وضعیت Process
ثبت خروجی سرور در systemd Journal
اجرای MTA با کاربر محدود به‌جای root
مدیریت بهتر سرور پس از بروزرسانی
امکان بررسی دقیق خطاهای Startup

سرور MTA را تا حد امکان با حساب root اجرا نکنید. استفاده از یک کاربر اختصاصی سطح دسترسی Process را محدود می‌کند.

مرحله اول: پیدا کردن مسیر نصب MTA

قبل از ساخت Service باید مسیر دقیق MTA Server مشخص باشد.

در این آموزش فرض می‌کنیم MTA در مسیر زیر نصب شده است:

/home/mta/multitheftauto_linux_x64

فایل اجرایی نسخه 64 بیتی نیز:

/home/mta/multitheftauto_linux_x64/mta-server64

اگر مسیر نصب شما متفاوت است، تمام مسیرهای نمونه این مقاله را با مسیر واقعی سرور جایگزین کنید.

بررسی وجود فایل اجرایی

ls -lh /home/mta/multitheftauto_linux_x64/mta-server64

همچنین می‌توانید نسخه سرور را بررسی کنید:

cd /home/mta/multitheftauto_linux_x64

./mta-server64 --version

قبل از ساخت Service بهتر است مطمئن شوید MTA به‌صورت دستی و بدون خطا اجرا می‌شود.

مرحله دوم: بررسی کاربر mta

بررسی کنید کاربری با نام mta وجود دارد:

id mta

اگر اطلاعات UID و GID نمایش داده شد، کاربر وجود دارد و نیازی به ساخت مجدد آن نیست.

اگر کاربر وجود ندارد، می‌توان یک حساب سیستمی مخصوص MTA ایجاد کرد:

sudo useradd \
--system \
--create-home \
--home-dir /home/mta \
--shell /usr/sbin/nologin \
mta

گزینه nologin باعث می‌شود این حساب برای Login عادی SSH استفاده نشود.

مرحله سوم: تنظیم مالکیت فایل‌های MTA

کاربری که در Service مشخص می‌شود باید اجازه خواندن و نوشتن فایل‌های موردنیاز MTA را داشته باشد.

اگر قرار است سرور با کاربر mta اجرا شود:

sudo chown -R mta:mta \
/home/mta/multitheftauto_linux_x64

سپس مالکیت را بررسی کنید:

ls -ld \
/home/mta/multitheftauto_linux_x64

اگر پروژه شما ساختار Permission اختصاصی دارد، قبل از اجرای chown روی کل پوشه تنظیمات فعلی را بررسی کنید.

مرحله چهارم: تنظیم Permission فایل اجرایی

sudo chmod +x \
/home/mta/multitheftauto_linux_x64/mta-server64

سپس اجرای فایل با کاربر mta را آزمایش کنید:

sudo -u mta \
/home/mta/multitheftauto_linux_x64/mta-server64 \
--version

اگر نسخه MTA نمایش داده شود، کاربر mta به فایل اجرایی دسترسی دارد.

مرحله پنجم: ساخت فایل Service

فایل Service را در مسیر استاندارد تنظیمات محلی systemd ایجاد کنید:

sudo nano /etc/systemd/system/mtaserver.service

کل محتوای زیر را داخل فایل قرار دهید:

[Unit]
Description=MTA:SA Dedicated Server
Wants=network-online.target
After=network-online.target

[Service]
Type=simple

User=mta
Group=mta

WorkingDirectory=/home/mta/multitheftauto_linux_x64

ExecStart=/home/mta/multitheftauto_linux_x64/mta-server64

Restart=on-failure
RestartSec=5

StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

فایل را ذخیره کنید و از nano خارج شوید.

توضیح بخش Unit

[Unit]
Description=MTA:SA Dedicated Server
Wants=network-online.target
After=network-online.target

Description نام قابل‌خواندن سرویس است.

network-online.target برای سرویس‌هایی استفاده می‌شود که هنگام شروع به شبکه نیاز دارند. After مشخص می‌کند اجرای MTA بعد از رسیدن سیستم به این مرحله انجام شود.

توضیح Type=simple

Type=simple

MTA Server به‌صورت یک Process اصلی اجرا می‌شود و برای این ساختار نیازی به Fork یا PID File اختصاصی نداریم.

توضیح User و Group

User=mta
Group=mta

با این تنظیم، Process سرور با سطح دسترسی کاربر mta اجرا می‌شود و نه با root.

اگر فایل‌های سرور متعلق به کاربر دیگری هستند، باید نام همان کاربر را قرار دهید یا Permissionها را اصلاح کنید.

توضیح WorkingDirectory

WorkingDirectory=/home/mta/multitheftauto_linux_x64

WorkingDirectory تعیین می‌کند MTA از چه پوشه‌ای اجرا شود. این موضوع برای پیدا کردن فایل‌های mods، تنظیمات، Resourceها و سایر فایل‌های نسبی سرور اهمیت دارد.

توضیح ExecStart

ExecStart=/home/mta/multitheftauto_linux_x64/mta-server64

ExecStart مسیر فایل اجرایی MTA Server را مشخص می‌کند.

برای نسخه 32 بیتی، نام فایل اجرایی ممکن است به‌شکل زیر باشد:

mta-server

در سرورهای 64 بیتی معمول امروزی از mta-server64 استفاده می‌شود.

توضیح Restart خودکار

Restart=on-failure
RestartSec=5

با Restart=on-failure اگر Process به‌صورت غیرعادی متوقف شود، systemd دوباره آن را اجرا می‌کند.

RestartSec=5 نیز پنج ثانیه بین Failure و تلاش بعدی فاصله ایجاد می‌کند.

از Restart=always بدون بررسی نیاز پروژه استفاده نکنید. on-failure برای بسیاری از سرویس‌های دائمی انتخاب مناسب‌تری است، زیرا Stop عادی توسط مدیر را فوراً خنثی نمی‌کند.

توضیح ثبت Logها

StandardOutput=journal
StandardError=journal

خروجی عادی و خطاهای Process در Journal سیستم ثبت می‌شوند و با journalctl قابل مشاهده هستند.

توضیح WantedBy

[Install]
WantedBy=multi-user.target

این بخش برای Enable کردن سرویس هنگام Boot استفاده می‌شود.

مرحله ششم: بارگذاری Service جدید

پس از ساخت یا تغییر فایل Service باید systemd دوباره Unitها را بخواند:

sudo systemctl daemon-reload

بررسی فایل Service قبل از اجرا

می‌توان فایل Service را از نظر خطاهای ساختاری بررسی کرد:

sudo systemd-analyze verify \
/etc/systemd/system/mtaserver.service

اگر خطایی درباره Directive یا Syntax مشاهده شد، قبل از Start آن را اصلاح کنید.

مرحله هفتم: اجرای سرویس MTA

sudo systemctl start mtaserver

چند ثانیه بعد وضعیت سرویس را مشاهده کنید:

sudo systemctl status mtaserver

در حالت صحیح باید سرویس در وضعیت active و Process فایل mta-server64 در حال اجرا باشد.

نمایش وضعیت بدون Pager

sudo systemctl status \
mtaserver \
--no-pager

مرحله هشتم: فعال‌کردن اجرای خودکار بعد از ریبوت

sudo systemctl enable mtaserver

اکنون systemd سرویس را هنگام Boot معمول سیستم اجرا خواهد کرد.

وضعیت Enable را بررسی کنید:

systemctl is-enabled mtaserver

خروجی مورد انتظار:

enabled

Enable و Start با یک دستور

اگر Service هنوز اجرا نشده است، می‌توان Enable و Start را هم‌زمان انجام داد:

sudo systemctl enable --now mtaserver

بررسی فعال بودن Process

systemctl is-active mtaserver

اگر سرویس در حال اجرا باشد:

active

مدیریت روزمره سرور MTA

پس از ساخت Service دیگر نیازی نیست فایل mta-server64 را برای مدیریت عادی مستقیماً اجرا کنید.

شروع سرور:

sudo systemctl start mtaserver

توقف سرور:

sudo systemctl stop mtaserver

Restart:

sudo systemctl restart mtaserver

مشاهده وضعیت:

sudo systemctl status mtaserver

مشاهده Logهای MTA با journalctl

برای مشاهده آخرین Logهای Service:

sudo journalctl \
-u mtaserver.service \
-n 100 \
--no-pager

برای مشاهده زنده Logها:

sudo journalctl \
-u mtaserver.service \
-f

برای خروج از حالت Follow کلید Ctrl+C را بزنید.

مشاهده Logهای همین Boot

sudo journalctl \
-u mtaserver.service \
-b

این دستور فقط Logهای مربوط به Boot فعلی سیستم را نمایش می‌دهد.

Log داخلی MTA را هم بررسی کنید

علاوه بر systemd Journal، MTA Log اختصاصی خود را نیز در پوشه deathmatch نگهداری می‌کند.

tail -f \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/logs/server.log

برای عیب‌یابی بهتر، هم Journal و هم server.log را بررسی کنید.

آزمایش اجرای خودکار بعد از ریبوت VPS

پس از تأیید عملکرد صحیح Service، در زمان مناسب VPS را ریبوت کنید:

sudo reboot

پس از بالا آمدن سیستم دوباره با SSH وارد شوید و وضعیت را بررسی کنید:

sudo systemctl status mtaserver

همچنین Process را بررسی کنید:

ps aux | grep mta-server

بررسی پورت‌ها بعد از Boot

برای تنظیمات پیش‌فرض MTA:

sudo ss -lntup | \
grep -E '22003|22005|22126'

اگر از پورت‌های دیگری استفاده می‌کنید، شماره‌های واقعی سرور را جایگزین کنید.

آزمایش Restart خودکار بعد از Crash

برای سرور Production عمداً Process را Kill نکنید. این آزمایش را فقط در سرور تست یا زمان Maintenance انجام دهید.

PID سرویس را مشاهده کنید:

systemctl show \
-p MainPID \
--value \
mtaserver

پس از توقف غیرعادی Process، با Restart=on-failure باید systemd پس از زمان تعیین‌شده دوباره Service را اجرا کند.

وضعیت Restart را از Journal بررسی کنید:

sudo journalctl \
-u mtaserver.service \
-n 50 \
--no-pager

چرا از screen یا tmux استفاده نکنیم؟

screen و tmux برای اجرای دستی برنامه و داشتن Terminal دائمی بسیار مفید هستند؛ اما جایگزین کامل Service Manager نیستند.

ویژگی	systemd	screen / tmux
اجرای خودکار بعد از Boot	بله	نیاز به تنظیم اضافه
Restart خودکار بعد از Failure	بله	به‌صورت پیش‌فرض خیر
مدیریت با systemctl	بله	خیر
Journal مرکزی	بله	خیر
Terminal تعاملی	خیر	بله

برای سرور Production، systemd معمولاً روش مناسب‌تری برای مدیریت دائمی Process است.

ارسال دستور به Console در حالت systemd

وقتی MTA مستقیماً داخل Terminal اجرا نمی‌شود، Console تعاملی قبلی در اختیار مدیر نیست.

برای مدیریت روزمره می‌توان از Admin Panel، Webadmin یا فرمان‌های داخل بازی استفاده کرد.

برای عملیات سیستمی مانند Restart کامل سرور نیز systemctl استفاده می‌شود:

sudo systemctl restart mtaserver

خطای Failed to start mtaserver.service

اگر Service اجرا نشد، ابتدا وضعیت کامل را ببینید:

sudo systemctl status \
mtaserver.service \
-l \
--no-pager

سپس Journal را بررسی کنید:

sudo journalctl \
-u mtaserver.service \
-n 100 \
--no-pager

خطای Permission denied

در صورت مشاهده Permission denied موارد زیر را بررسی کنید:

مالکیت فایل‌های MTA
وجود کاربر mta
Permission فایل mta-server64
Permission پوشه‌های mods و resources
Permission دیتابیس‌های internal.db و registry.db
Permission فایل‌های Log

بررسی فایل اجرایی:

ls -lh \
/home/mta/multitheftauto_linux_x64/mta-server64

اصلاح Permission اجرا:

sudo chmod +x \
/home/mta/multitheftauto_linux_x64/mta-server64

خطای WorkingDirectory

اگر مسیر WorkingDirectory وجود نداشته باشد یا قابل دسترس نباشد، Service قبل از اجرای MTA متوقف می‌شود.

مسیر را بررسی کنید:

ls -ld \
/home/mta/multitheftauto_linux_x64

سپس مقدار داخل mtaserver.service را با مسیر واقعی مقایسه کنید.

خطای ExecStart

اگر مسیر فایل اجرایی اشتباه باشد، systemd نمی‌تواند Process را اجرا کند.

sudo -u mta \
/home/mta/multitheftauto_linux_x64/mta-server64 \
--version

اگر همین دستور نیز خطا می‌دهد، ابتدا مشکل مسیر، Permission یا کتابخانه‌های MTA را برطرف کنید.

خطای Start request repeated too quickly

این پیام معمولاً زمانی دیده می‌شود که Process بلافاصله پس از Start چند بار پشت‌سرهم Fail شود و systemd تلاش‌های مجدد را محدود کند.

ابتدا علت اصلی را در Journal پیدا کنید:

sudo journalctl \
-u mtaserver.service \
-n 100 \
--no-pager

بعد از رفع خطا وضعیت Failed را پاک کنید:

sudo systemctl reset-failed mtaserver

و دوباره Service را اجرا کنید:

sudo systemctl start mtaserver

خطای Address already in use

اگر نسخه دیگری از MTA قبلاً به‌صورت دستی اجرا شده باشد، Service جدید نمی‌تواند همان پورت را استفاده کند.

ps aux | grep mta-server

پورت اصلی را نیز بررسی کنید:

sudo ss -lunp | grep 22003

قبل از Start سرویس، نمونه MTA که به‌صورت دستی اجرا شده است را متوقف کنید.

Service اجرا می‌شود ولی سرور قابل اتصال نیست

Active بودن systemd فقط نشان می‌دهد Process اجرا شده است. برای اتصال بازیکنان باید تنظیمات MTA و شبکه نیز صحیح باشند.

serverport را بررسی کنید.
پورت UDP بازی را در Firewall باز کنید.
پورت HTTP را بررسی کنید.
فایروال پنل VPS را بررسی کنید.
خروجی openports را بررسی کنید.
Log داخلی MTA را مطالعه کنید.

راهنمای کامل این بخش در مقاله باز کردن پورت‌های سرور MTA در لینوکس قرار دارد.

تغییر فایل Service بعداً چگونه انجام می‌شود؟

فایل را دوباره باز کنید:

sudo nano \
/etc/systemd/system/mtaserver.service

بعد از هر تغییر:

sudo systemctl daemon-reload

sudo systemctl restart mtaserver

فقط ویرایش فایل Service کافی نیست؛ بعد از تغییر Unit باید daemon-reload اجرا شود.

بروزرسانی MTA و ارتباط آن با systemd

اگر هنگام بروزرسانی MTA مسیر اصلی نصب ثابت باقی بماند، معمولاً نیازی به تغییر ExecStart نیست.

برای نمونه اگر بعد از بروزرسانی همچنان مسیر زیر استفاده شود:

/home/mta/multitheftauto_linux_x64/mta-server64

کافی است سرویس را پس از تکمیل بروزرسانی دوباره اجرا کنید:

sudo systemctl restart mtaserver

روش کامل بروزرسانی در مقاله آموزش بروزرسانی سرور MTA در لینوکس توضیح داده شده است.

اگر مسیر MTA بعد از بروزرسانی تغییر کند

اگر پوشه نصب را تغییر داده‌اید، هر دو مقدار زیر باید اصلاح شوند:

WorkingDirectory=
ExecStart=

بعد:

sudo systemctl daemon-reload
sudo systemctl restart mtaserver

غیرفعال‌کردن اجرای خودکار

اگر دیگر نمی‌خواهید MTA هنگام Boot اجرا شود:

sudo systemctl disable mtaserver

این دستور Service در حال اجرای فعلی را الزاماً متوقف نمی‌کند.

برای Stop و Disable هم‌زمان:

sudo systemctl disable --now mtaserver

حذف کامل Service

ابتدا سرویس را متوقف و Disable کنید:

sudo systemctl disable --now mtaserver

سپس فایل Unit را حذف کنید:

sudo rm \
/etc/systemd/system/mtaserver.service

در پایان:

sudo systemctl daemon-reload
sudo systemctl reset-failed

اجرای چند سرور MTA با systemd

اگر چند MTA Server روی یک VPS دارید، برای هر Instance می‌توان Service جداگانه ایجاد کرد.

برای نمونه:

mtaserver1.service
mtaserver2.service
mtaserver3.service

هر Service باید WorkingDirectory و ExecStart مربوط به همان Instance را داشته باشد.

همچنین هر سرور MTA باید پورت‌های بازی، HTTP و ASE متفاوت داشته باشد.

نمونه Service برای سرور دوم

[Unit]
Description=MTA:SA Server 2
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mta
Group=mta
WorkingDirectory=/home/mta/server2
ExecStart=/home/mta/server2/mta-server64
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

سرویس دوم را می‌توان با نام مستقل مدیریت کرد:

sudo systemctl enable --now mtaserver2

امنیت بیشتر برای Service MTA

مهم‌ترین اقدام امنیتی اولیه، اجرا نکردن MTA با root و محدودکردن مالکیت فایل‌ها به کاربر مخصوص Server است.

از User اختصاصی برای MTA استفاده کنید.
به کاربر mta دسترسی sudo ندهید مگر واقعاً لازم باشد.
Resourceهای ناشناس را نصب نکنید.
فایل‌های Server را فقط برای کاربران ضروری قابل نوشتن کنید.
ACL سرور را محدود نگه دارید.
فایروال را فقط برای پورت‌های موردنیاز باز کنید.
MTA و Resourceهای اصلی را بروزرسانی نگه دارید.
از تنظیمات و دیتابیس بکاپ دوره‌ای تهیه کنید.

اشتباهات رایج هنگام ساخت Service

نوشتن مسیر اشتباه در ExecStart
نوشتن مسیر اشتباه در WorkingDirectory
فراموش‌کردن chmod +x
اجرا با User بدون دسترسی به فایل‌ها
فراموش‌کردن daemon-reload
فعال نکردن Service با systemctl enable
اجرای هم‌زمان نسخه دستی و systemd
اشغال بودن پورت‌های MTA
بررسی نکردن journalctl بعد از Failure
اجرای دائمی سرور با root بدون نیاز
تغییر مسیر سرور بدون اصلاح Unit

جدول سریع عیب‌یابی systemd و MTA

مشکل	علت احتمالی	راه‌حل
Service پیدا نمی‌شود	daemon-reload اجرا نشده	systemctl daemon-reload
Permission denied	Permission یا مالکیت اشتباه	User و chown/chmod را بررسی کنید
ExecStart failed	مسیر فایل اشتباه	مسیر mta-server64 را اصلاح کنید
WorkingDirectory failed	پوشه وجود ندارد	مسیر نصب MTA را بررسی کنید
Address already in use	MTA دیگری در حال اجرا است	Process و پورت را بررسی کنید
Service بعد از Boot اجرا نمی‌شود	Enable نشده است	systemctl enable mtaserver
Service مرتب Restart می‌شود	MTA بلافاصله Crash می‌کند	Journal و server.log را بررسی کنید
Active است ولی اتصال ممکن نیست	پورت یا Firewall	پورت‌ها و mtaserver.conf را بررسی کنید
بعد از تغییر Unit تغییری نمی‌کند	daemon-reload فراموش شده	Reload و Restart کنید

چک‌لیست نهایی اجرای خودکار MTA

مسیر نصب MTA مشخص است.
mta-server64 به‌صورت دستی اجرا می‌شود.
کاربر mta وجود دارد.
فایل‌های MTA Permission مناسب دارند.
فایل mtaserver.service ساخته شده است.
WorkingDirectory صحیح است.
ExecStart صحیح است.
Restart=on-failure تنظیم شده است.
daemon-reload اجرا شده است.
Service بدون خطا Start می‌شود.
Service Enable شده است.
journalctl بررسی شده است.
پس از Reboot سرور خودکار بالا می‌آید.
پورت‌های MTA در حال Listen هستند.
اتصال واقعی Client آزمایش شده است.

ترتیب سریع ساخت Service

مسیر MTA را پیدا کنید.
اجرای دستی mta-server64 را آزمایش کنید.
کاربر mta را بررسی یا ایجاد کنید.
مالکیت فایل‌ها را تنظیم کنید.
فایل mtaserver.service را بسازید.
Unit را با systemd-analyze verify بررسی کنید.
systemctl daemon-reload را اجرا کنید.
Service را Start کنید.
وضعیت را با systemctl status بررسی کنید.
Logها را با journalctl مشاهده کنید.
Service را Enable کنید.
VPS را در زمان مناسب Reboot کنید.
اجرای خودکار MTA را بررسی کنید.

جمع‌بندی

با ساخت یک Service در systemd می‌توان سرور MTA را بعد از روشن‌شدن VPS به‌صورت خودکار اجرا کرد و درصورت توقف غیرعادی دوباره بالا آورد.

مهم‌ترین مقادیر فایل Service شامل User، Group، WorkingDirectory، ExecStart، Restart و WantedBy هستند. مسیرها باید دقیقاً با محل واقعی نصب MTA مطابقت داشته باشند.

برای بررسی مشکلات نیز systemctl status، journalctl و Log داخلی MTA مهم‌ترین ابزارها هستند.

برای نصب اولیه سرور، مقاله آموزش ساخت سرور MTA روی VPS لینوکس را مطالعه کنید.

برای بروزرسانی امن نیز راهنمای آموزش بروزرسانی سرور MTA در لینوکس را ببینید.

اگر Server اجرا می‌شود اما بازیکنان امکان اتصال ندارند، مقاله آموزش باز کردن پورت‌های سرور MTA در لینوکس را بررسی کنید.

برای بررسی و مدیریت زیرساخت پروژه می‌توانید از خدمات پشتیبانی فنی گیم‌سرور و راه‌اندازی و کانفیگ سرور MTA استفاده کنید.

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

چگونه MTA را بعد از ریبوت VPS خودکار اجرا کنیم؟

یک Service برای systemd بسازید و سپس دستور systemctl enable mtaserver را اجرا کنید.

چگونه وضعیت MTA را در systemd ببینیم؟

از دستور systemctl status mtaserver استفاده کنید.

چگونه Log سرور را ببینیم؟

برای Logهای systemd از journalctl -u mtaserver.service استفاده کنید و برای Log داخلی MTA فایل mods/deathmatch/logs/server.log را بررسی کنید.

آیا MTA بعد از Crash خودکار Restart می‌شود؟

اگر در Service مقدار Restart=on-failure تنظیم شده باشد، systemd پس از Failure تلاش می‌کند Process را دوباره اجرا کند.

آیا باید MTA را با root اجرا کنیم؟

برای اجرای عادی نیازی به root نیست و بهتر است Process با یک User اختصاصی مانند mta اجرا شود.

بعد از ویرایش فایل Service چه دستوری لازم است؟

ابتدا systemctl daemon-reload و سپس systemctl restart mtaserver را اجرا کنید.

چگونه اجرای خودکار MTA را غیرفعال کنیم؟

دستور systemctl disable mtaserver را اجرا کنید. برای توقف هم‌زمان سرویس می‌توان از disable –now استفاده کرد.