د VPN خدمت په EXEC کې ناکامېږي: unit، بائنري او sudoers پرتله کړئ
په EXEC ګام کې ناکامي یعنې systemd بائنري پیل نشو کولی۔ د هر څه د بدلولو دمخه د unit لاره، نصب شوې لاره او د sudoers اجازه پرتله کړئ۔
پرون تونل کار کاوه، او نن سهار unit مړ دی، په ژورنال کې Failed at step EXEC spawning /usr/local/bin/vpnclient دی۔ اعتبارنامې، لارې او حساب هېڅکله په دې جمله کې نه راځي۔ systemd ExecStart په یوه لاره واوښت، له کرنل څخه یې غوښتنه وکړه چې هغه پرمخ بوځي، او کرنل رد کړه، ډېری وخت ځکه چې په هغې لاره کې هېڅ نشته یا فایل د چلولو وړ نه دی۔ تر هغو چې شنل شوې فرمان مخالف ثابت کړي، دا خرابي د فایل او argv ستونزه وګڼئ۔
ولې EXEC د تصدیق له پیل دمخه ناکامېږي
systemd ExecStart د شیل له لارې نه چلوي۔ دا fork کوي، له کرښې څخه د استدلالونو ویکتور جوړوي او پر لومړي عنصر execve غواړي۔ که هغه غوښتنه ناکامه شي، خدمت هېڅکله د VPN پیرودونکي خپل کوډ ته نه رسېږي، نو د پروفایل سمون یا د اعتبارنامو کتنه مرسته نه شي کولی۔
د حالت کوډ دا کورنۍ له عادي نړېدو جلا کوي۔ هغه unit چې په status=203/EXEC وځي هېڅکله پروسه نه ده پیل کړې؛ هغه unit چې پیل شي او بیا په status=1 ووځي، کېدای شي په تصدیق، DNS یا لارښوونه کې ناکام شوی وي۔ د پیرودونکي لاګ لوستلو دمخه کوډ ولولئ، ځکه په لومړي حالت کې د پیرودونکي لاګ به خالي وي۔
په ژورنال کې لاره هغه ده چې systemd کارولې، نه اړینه هغه چې تاسو سمولې۔ Drop-in فایلونه او د جنراتور وتنه کولای شي د عرضه کوونکي فایل تر پښو لاندې کړي، او زوړ daemon-reload زاړه کرښه په حافظه کې پرېږدي۔ نو لومړنی تشخیص دا دی چې systemd وپوښتئ چې فرمان څه ګڼي، نه دا چې هغه فایل پرانیزئ چې تاسو یې د بدلولو یاد ولرئ۔
درې ځایونه چې د بائنري لاره پکې لیکل کېږي
هغه VPN پیرودونکی چې د وېش پیکیج، د عرضه کوونکي سکریپټ او د خپرېدو tarball څخه نصب شوی وي، کېدای شي په درې بېلو مختګونو کې ځای پرځای شي۔ unit، د امتیاز قاعده او نصب کوونکي هر یو له دغو مختګونو څخه یو ثبت کړ، او خرابي هغه وخت ښکاري چې له درېیو دوه سره نه ځي۔
| Record | Common value | How to read it |
|---|---|---|
| Unit or drop-in | /usr/local/bin/vpnclient | systemctl cat vpnclient.service |
| Installed binary | /usr/bin/vpnclient | command -v vpnclient, then ls -l the result |
| Sudoers grant | /opt/vpnclient/bin/vpnclient | sudo grep -r vpnclient /etc/sudoers.d/ |
یوه ټاکلې ناسمي داسې ښکاري: د عرضه کوونکي سکریپټ /usr/local/bin ته نصبوي، tarball د /opt لاندې پرانیستل شو، او unit لا هم د پخواني پیکیج زوړ /usr/bin مسیر یادوي۔ له دغو فایلونو یوازې یو شته، او دا کله ناکله هغه فایل وي چې په ExecStart کې دی۔
له دې مخکې چې هر فایل بدل کړئ، پریکړه وکړئ چې کومه لاره کانوني ده۔ که بائنري د وېش پیکیج ملکیت وي، د پیکیج لاره کانوني ده او unit باید د هغې پیروي وکړي۔ که د عرضه کوونکي سکریپټ یې ملکیت وي، هماغه قاعده د عرضه کوونکي مختګ لپاره هم صدق کوي۔ د مختګونو ترمنځ د بائنري کاپي کول دوې کاپۍ جوړوي چې په بل اپګریډ کې سره جلا کېږي۔
کله چې په نښه کې فرمان د فایل نوم شي
دوهم ناکامۍ ډول د هماغه ژورنال کرښې شاته پټ دی۔ یو څوک دا په unit کې لیکي او تمه لري چې پیرودونکی به د بوت پر مهال ونیول شي:
ExecStart=/usr/bin/"vpnclient connect office"systemd ارزښت په کلمو ووېشي، نو لومړۍ کلمه /usr/bin/vpnclient connect office کېږي، او نښې د ډلې بندۍ نحو په توګه لرې کېږي۔ بیا کرنل داسې فایل لټوي چې نوم کې یې تشې وي، او داسې فایل نشته۔ که څه هم بائنري نصب دی، تېروتنه د ورک بائنري په څېر ده۔
منل شوې بڼه دا ده چې ریښتینی د چلولو وړ فایل او بیا جلا استدلالونه وي، لکه ExecStart=/usr/bin/vpnclient connect office۔ که کاري بهیر واقعاً نل یا زنځیر ته اړتیا لري، هغه په سکریپټ کې کېږدئ او سکریپټ ته زنګ ووهئ، ځکه ExecStart کې && نشته، نلونه نشته او glob پراختیا نشته۔
د فایل سیسټم نه، unit سم کړئ
هغه حل چې ښايي زړه ښه کړي، له تمه شوې لارې څخه ریښتیني بائنري ته سمبولیک لینک دی۔ دا تر هغو کار کوي چې پیکیج اپډیټ شي او لینک حذف شوی فایل ته اشاره وکړي، یا SELinux لیبل له هدف سره سمون نه خوري۔ غوره دا ده چې unit د drop-in له لارې سم کړئ، تر څو د عرضه کوونکي فایل لاس نه ورسېږي او اپګریډونه د وړاندوینې وړ پاتې شي۔
د امتیاز قاعده باید له هماغې لارې او هماغو فرعي فرمانونو سره سمه وي۔ د /usr/local/bin/vpnclient لپاره sudoers لیکنه /usr/bin/vpnclient ته اجازه نه ورکوي، او هغه لیکنه چې هر استدلال ته اجازه ورکوي، هر ځایي پروسې ته دا توان ورکوي چې تونل بیا تنظیم یا ودروي۔ هغه دوې کړنې ورکړئ چې unit ته اړینې دي، او که د خدمت ودريدل مخکې له مخکې انټرفېس بندوي، نړول ترې بهر وساتئ۔
دلته پرتله ګټه رسوي: unit، د پیکیجونو ډیټابیس او sudoers باید ټول یوه لاره ونوموي۔ کله چې داسې شي، د EXEC تېروتنه پرته له ریبوټ او پرته له دې چې بائنري په درېیم ځای کې کاپي شي ورکېږي۔
له ریسټارټ دمخه شنل شوی فرمان ثابت کړئ
sudo systemctl daemon-reload
sudo systemctl cat vpnclient.service
systemctl show -p ExecStart vpnclient.service
systemd-analyze verify /etc/systemd/system/vpnclient.service
sudo systemctl restart vpnclient.service
systemctl status vpnclient.service --no-pagersystemctl show هغه پرېکنده وتنه ده، ځکه هغه argv چاپوي چې systemd واقعاً شنلی و، له هر drop-in سره۔ systemd-analyze verify له ریسټارټ دمخه ورکه یا نه چلېدونکې لاره نیسي، او له ریسټارټ وروسته status فرمان وایي چې پروسه اوس شته که نه۔
که unit پیل شي او بیا ناکامه شي، تاسو د EXEC کورنۍ پرېښې ده او د پیرودونکي خپلې تېروتنې ادارې ته ننوتلې یاست۔ په ژورنال کې د پیرودونکي پیغام وپلټئ، نه بله execve ناکامي۔ د unit diff او د sudoers diff یو ځای د بدلون په ریکارډ کې وساتئ، تر څو بل اپګریډ ووېشل شوې لاره په غلې پټه بیرته را نه وړي۔