خطای status=217/USER در systemd یعنی آماده‌سازی هویت کاربری سرویس پیش از اجرای برنامه شکست خورده است. ابتدا با systemctl status و journalctl پیام دقیق را ببینید؛ سپس مقدار User=، Group=، وضعیت حساب در NSS و تنظیمات DynamicUser= و PrivateUsers= را بررسی کنید. صرفاً افزایش تعداد Restart یا اجرای سرویس با root راه‌حل امنی نیست.
کد 217/USER چه تفاوتی با خطاهای دیگر دارد؟
در مستند رسمی systemd.exec، کد ۲۱۷ با نام EXIT_USER ثبت شده و به شکست تعیین/تغییر اطلاعات کاربری یا راه‌اندازی User Namespace اشاره دارد. بنابراین این کد لزوماً به معنای خرابی فایل اجرایی یا مشکل دسترسی به فایل‌های برنامه نیست. برای نمونه، 203/EXEC مربوط به اجرای خود برنامه است؛ اگر آن کد را می‌بینید، راهنمای عیب‌یابی status=203/EXEC در systemd مسیر دقیق‌تری دارد.
اگر پس از چند تلاش خطای start-limit-hit هم دیده می‌شود، آن پیام معمولاً نتیجه تلاش‌های مکرر ناموفق است، نه علت اولیه؛ پس از اصلاح هویت کاربر می‌توانید از مراحل رفع خطای start request repeated too quickly برای پاک‌کردن وضعیت شکست استفاده کنید.
پیش‌نیازها و نکات ایمنی
این مراحل برای سرویس‌های systemd در Linux روی VPS یا سرور اختصاصی با دسترسی مدیریتی نوشته شده‌اند. به‌جای example.service نام Unit واقعی را قرار دهید. پیش از تغییر Unit، خروجی systemctl cat را بررسی و از فایل‌های تنظیمات مرتبط نسخه پشتیبان بگیرید؛ ممکن است متغیرهای محیطی حساس در Unit وجود داشته باشند، پس آن‌ها را در تیکت یا خروجی عمومی منتشر نکنید. بدون بررسی DynamicUser کاربر جدید نسازید و سرویس را با User=root راه نیندازید.
گام اول: تأیید خطا در Status و Journal
sudo systemctl status example.service --no-pager -l
sudo journalctl -u example.service -b -n 80 --no-pagerدر خروجی به عبارت‌هایی مانند status=217/USER، Failed at step USER یا پیام خطای شناسایی کاربر دقت کنید. اگر به‌جای ۲۱۷، کد دیگری می‌بینید، پیش از هر تغییری همان کد را دنبال کنید. نمونه خروجی:
example.service: Failed at step USER spawning /usr/local/bin/example: No such process
example.service: Main process exited, code=exited, status=217/USERعبارت پایانی سیستم ممکن است بسته به توزیع، نسخه systemd و علت اصلی متفاوت باشد؛ تنها به متن «No such process» برای نتیجه‌گیری درباره وجود یا نبود کاربر تکیه نکنید.
گام دوم: مقدار User، Group و تنظیمات Unit را بخوانید
sudo systemctl cat example.service
systemctl show example.service -p User -p Group -p DynamicUser -p PrivateUsers -p FragmentPath -p DropInPathsدر خروجی systemctl cat، فایل اصلی و همه Drop-inها را می‌بینید. تنظیمی که در Drop-in مؤثرتر قرار دارد می‌تواند مقدار Unit اصلی را تغییر دهد. نمونه:
User=appsvc
Group=appsvc
DynamicUser=no
PrivateUsers=noاگر User= به حسابی اشاره می‌کند که در NSS Resolve نمی‌شود، این علت مهمی برای 217/USER است. خطای گروه معمولاً با کد جداگانه 216/GROUP دیده می‌شود؛ بااین‌حال Group= را هم برای کامل‌بودن بررسی کنید. اگر DynamicUser=yes است، نبود کاربر ثابت در /etc/passwd به‌تنهایی خطا نیست؛ systemd می‌تواند حساب موقت مدیریت کند. در این حالت سراغ بررسی User Namespace و خطاهای مربوط بروید.
گام سوم: حساب سرویس و NSS را بررسی کنید
getent passwd appsvc
id appsvc
getent group appsvc
grep -E '^(passwd|group):' /etc/nsswitch.confنام appsvc صرفاً مثال است و در فرمان‌های مربوط به کاربر باید با User= و در فرمان getent group با نام گروه واقعی Group= جایگزین شود. در سرویس با حساب ثابت, getent passwd باید رکورد معتبر برگرداند. اگر کاربر از LDAP/SSSD یا منبع هویت شبکه‌ای می‌آید، ممکن است سرویس نام کاربری را در زمان راه‌اندازی Resolve نکند؛ در این صورت وضعیت سرویس هویت و اتصال آن را بررسی کنید، نه اینکه یک حساب محلی هم‌نام بسازید.
برای محیطی که واقعاً SSSD دارد، پس از تأیید استفاده از آن در nsswitch.conf، می‌توانید systemctl status sssd و journalctl -u sssd -b را بررسی کنید. وجود نداشتن SSSD در سروری که فقط حساب محلی دارد، خودِ مشکل نیست.
گام چهارم: راه‌حل مناسب را بر اساس علت انتخاب کنید
۱. نام کاربر یا گروه در Unit اشتباه است
اگر حساب صحیح از قبل وجود دارد، مقدار اشتباه را در Drop-in اختصاصی همین سرویس اصلاح کنید. با دستور زیر ویرایشگر systemd باز می‌شود:
sudo systemctl edit example.serviceمحتوای نمونه فقط در صورتی معتبر است که حساب و گروه appsvc از قبل با getent تأیید شده باشند:
[Service]
User=appsvc
Group=appsvcتغییر User= می‌تواند دسترسی سرویس به فایل‌ها، Socketها و مسیرهای داده را تغییر دهد. پیش از Restart، مالکیت و مجوز مسیرهای موردنیاز برنامه را بررسی کنید؛ برای رفع خطای ۲۱۷ به‌صورت کورکورانه chmod 777 نزنید.
۲. حساب ثابت واقعاً حذف شده است
اگر مستندات برنامه صریحاً به یک حساب سیستمی ثابت نیاز دارند، پس از اطمینان از اینکه DynamicUser=no است و نام با حساب شبکه‌ای تداخل ندارد، می‌توانید آن حساب را با روش استاندارد توزیع ایجاد کنید. مثال زیر برای سیستم‌های دارای ابزار useradd است و فقط با نام صحیح و پس از بررسی اجرا می‌شود:
sudo useradd --system --user-group --no-create-home --shell /usr/sbin/nologin appsvc
getent passwd appsvc
getent group appsvcاگر گروه باید از قبل موجود باشد یا سرویس به UID/GID مشخصی نیاز دارد، این مثال را اجرا نکنید؛ ابتدا UID/GID مورد انتظار را از پشتیبان، مستندات برنامه یا پیکربندی قبلی بازیابی کنید. ایجاد حساب با UID متفاوت می‌تواند دسترسی به فایل‌های موجود را خراب کند.
۳. DynamicUser یا PrivateUsers درگیر است
در حالت DynamicUser=yes حساب می‌تواند هنگام اجرای Unit ساخته شود و با توقف آن از بین برود. PrivateUsers=yes نیز به User Namespace وابسته است. اگر Journal از شکست User Namespace یا محدودیت‌های امنیتی Kernel/Container خبر می‌دهد، محدودیت‌های میزبان، نسخه systemd و سیاست‌های کانتینر را بررسی کنید. خاموش‌کردن این گزینه‌ها یا برداشتن Sandboxing بدون ارزیابی امنیتی راه‌حل پیش‌فرض نیست.
گام پنجم: بررسی صحت Unit و تأیید رفع مشکل
unit_path=$(systemctl show example.service -p FragmentPath --value)
sudo systemd-analyze verify "$unit_path"
sudo systemctl daemon-reload
sudo systemctl reset-failed example.service
sudo systemctl restart example.service
systemctl is-active example.service
sudo systemctl status example.service --no-pager -l
sudo journalctl -u example.service -b -n 30 --no-pagerخروجی مطلوب systemctl is-active برای یک سرویس ماندگار معمولاً active است و دیگر نباید رویداد جدید 217/USER ثبت شود. برای سرویس‌های Type=oneshot، وضعیت inactive (dead) پس از اجرای موفق می‌تواند طبیعی باشد؛ در این حالت Result=success و لاگ اجرای واقعی را بررسی کنید. systemd-analyze verify همه مشکلات runtime یا NSS را تشخیص نمی‌دهد.
اگر سرویس روی VPS اجرا می‌شود، چه چیزهایی به زیرساخت مربوط‌اند؟
در VPS خودمدیریت، امکان بررسی Unit، NSS، لاگ‌های بوت و دسترسی مدیریتی برای تشخیص خطای ۲۱۷ اهمیت دارد. هنگام انتخاب یا جابه‌جایی زیرساخت می‌توانید پلن‌های سرور مجازی وان‌سرور را از نظر منابع و نوع دسترسی موردنیاز مقایسه کنید؛ اما تغییر یا خرید VPS به‌تنهایی حساب اشتباه User=، اختلال NSS یا محدودیت User Namespace سرور فعلی را اصلاح نمی‌کند. پیش از هر مهاجرت، تنظیمات و مالکیت فایل‌های سرویس باید بررسی شوند.
Rollback: اگر تغییر Unit نتیجه نداد
اگر فقط با systemctl edit مقدار User/Group را عوض کرده‌اید، همان Drop-in را دوباره باز کنید و فقط تغییرهای همین نوبت را به مقدار قبلی برگردانید. از systemctl revert بدون بررسی استفاده نکنید، چون می‌تواند Drop-inهای دیگر را نیز حذف کند. پس از بازگردانی:
sudo systemctl daemon-reload
sudo systemctl restart example.service
sudo systemctl status example.service --no-pager -lاگر حساب جدید ساخته‌اید، آن را صرفاً به دلیل حل‌نشدن مشکل حذف نکنید؛ ابتدا بررسی کنید مالک فایل‌ها یا وابستگی سرویس دیگری نشده باشد. برای آشنایی با ترتیب Unitها و مدیریت وضعیت سرویس، مطلب آشنایی با مدیریت سرویس‌ها در systemd را ببینید.
جمع‌بندی تشخیص
برای 217/USER، ابتدا خروجی واقعی Journal را ملاک قرار دهید؛ سپس User= و Group=، دسترس‌پذیری هویت در NSS و در نهایت DynamicUser/PrivateUsers را بررسی کنید. فقط علت تأییدشده را اصلاح کنید و با Restart کنترل‌شده و لاگ جدید نتیجه را بسنجید. این مسیر از تغییر مجوزهای گسترده، اجرای سرویس با root و دستکاری بی‌دلیل Restart Policy ایمن‌تر است.