நேற்று சுரங்கப்பாதை வேலை செய்தது, இன்று காலையில் unit இறந்துவிட்டது, journal இல் Failed at step EXEC spawning /usr/local/bin/vpnclient உள்ளது. சான்றுகள், வழித்தடங்கள் மற்றும் கணக்கு அந்த வாக்கியத்தில் ஒருபோதும் வராது. systemd ExecStart ஐ ஒரு பாதையாகத் தீர்த்தது, அதை இயக்க கர்னலிடம் கேட்டது, கர்னல் மறுத்தது, பெரும்பாலும் அந்தப் பாதையில் எதுவும் இல்லாததால் அல்லது கோப்பு இயக்கக்கூடியதாக இல்லாததால். பகுப்பாய்வு செய்யப்பட்ட கட்டளை எதிர்மறையை நிரூபிக்கும் வரை இந்தக் குறையைக் கோப்பு மற்றும் argv பிரச்சினையாகக் கருதுங்கள்.

அங்கீகாரம் தொடங்குவதற்கு முன் EXEC ஏன் தோல்வியடைகிறது

systemd ExecStart ஐ ஒரு ஷெல் வழியாக இயக்குவதில்லை. அது fork செய்கிறது, வரியிலிருந்து வாத வெக்டரை உருவாக்குகிறது, முதல் உறுப்பின் மீது execve ஐ அழைக்கிறது. அந்த அழைப்பு தோல்வியடைந்தால், சேவை ஒருபோதும் VPN வாடிக்கையாளரின் சொந்த குறியீட்டை அடையாது, எனவே சுயவிவரத் திருத்தம் அல்லது சான்று சரிபார்ப்பு உதவ முடியாது.

நிலைக் குறியீடு இந்தக் குடும்பத்தை சாதாரண விபத்துகளிலிருந்து பிரிக்கிறது. status=203/EXEC உடன் வெளியேறும் unit ஒருபோதும் ஒரு செயல்முறையைத் தொடங்கவில்லை; தொடங்கி பின்னர் status=1 உடன் வெளியேறும் unit அங்கீகாரம், DNS அல்லது வழித்தடத்தில் தோல்வியடைந்திருக்கலாம். வாடிக்கையாளர் பதிவைப் படிப்பதற்கு முன் குறியீட்டைப் படியுங்கள், ஏனெனில் முதல் நிலையில் வாடிக்கையாளர் பதிவு காலியாக இருக்கும்.

journal இல் உள்ள பாதை systemd பயன்படுத்திய பாதை, நீங்கள் திருத்திய பாதையாக இருக்க வேண்டியதில்லை. Drop-in கோப்புகளும் ஜெனரேட்டர் வெளியீடும் விற்பனையாளரின் கோப்பை மேலெழுதலாம், பழைய daemon-reload பழைய வரியை நினைவகத்தில் வைத்திருக்கும். எனவே முதல் கண்டறிதல் என்பது நீங்கள் நினைவில் வைத்திருக்கும் மாற்றிய கோப்பைத் திறப்பதல்ல, systemd இடம் அது கட்டளையை என்னவென்று கருதுகிறது என்று கேட்பதாகும்.

பைனரியின் பாதை எழுதப்படும் மூன்று இடங்கள்

விநியோகத் தொகுப்பு, விற்பனையாளர் ஸ்கிரிப்ட் மற்றும் வெளியீட்டு tarball ஆகியவற்றிலிருந்து நிறுவப்பட்ட VPN வாடிக்கையாளர் மூன்று வெவ்வேறு முன்னொட்டுகளில் வந்து சேரலாம். unit, சிறப்புரிமை விதி மற்றும் நிறுவி ஒவ்வொன்றும் அந்த முன்னொட்டுகளில் ஒன்றைப் பதிவு செய்தன, மூன்றில் இரண்டு பொருந்தாதபோது குறை தோன்றுகிறது.

RecordCommon valueHow to read it
Unit or drop-in/usr/local/bin/vpnclientsystemctl cat vpnclient.service
Installed binary/usr/bin/vpnclientcommand -v vpnclient, then ls -l the result
Sudoers grant/opt/vpnclient/bin/vpnclientsudo grep -r vpnclient /etc/sudoers.d/

ஒரு குறிப்பிட்ட முரண்பாடு இப்படித் தெரிகிறது: விற்பனையாளர் ஸ்கிரிப்ட் /usr/local/bin இல் நிறுவுகிறது, tarball /opt கீழ் திறக்கப்பட்டது, unit இன்னும் முந்தைய தொகுப்பின் பழைய /usr/bin பாதையைக் குறிப்பிடுகிறது. அந்தக் கோப்புகளில் ஒன்று மட்டுமே உள்ளது, அது அரிதாகவே ExecStart இல் உள்ள கோப்பாக இருக்கும்.

எந்தக் கோப்பையும் மாற்றுவதற்கு முன் எந்தப் பாதை நியதி என்று தீர்மானியுங்கள். பைனரி விநியோகத் தொகுப்புக்குச் சொந்தமானது என்றால், தொகுப்பின் பாதை நியதி, unit அதைப் பின்பற்ற வேண்டும். விற்பனையாளர் ஸ்கிரிப்ட்டுக்குச் சொந்தமானது என்றால், அதே விதி விற்பனையாளர் முன்னொட்டுக்குப் பொருந்தும். முன்னொட்டுகளுக்கிடையே பைனரியை நகலெடுப்பது அடுத்த மேம்படுத்தலில் பிரியும் இரண்டு நகல்களை உருவாக்கும்.

மேற்கோளில் உள்ள கட்டளை கோப்புப் பெயராகும்போது

இரண்டாவது தோல்வி முறை அதே journal வரிக்குப் பின்னால் மறைந்துள்ளது. யாரோ இதை 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-pager

systemctl show தீர்க்கமான வெளியீடு, ஏனெனில் systemd உண்மையில் பகுப்பாய்வு செய்த argv ஐ, எந்த drop-in உட்பட அச்சிடுகிறது. systemd-analyze verify நீங்கள் மறுதொடக்கம் செய்வதற்கு முன் காணாமற்போன அல்லது இயக்க முடியாத பாதையைப் பிடிக்கிறது, மறுதொடக்கத்திற்குப் பின் status கட்டளை செயல்முறை இப்போது உள்ளதா என்று சொல்கிறது.

unit தொடங்கி பின்னர் தோல்வியடைந்தால், நீங்கள் EXEC குடும்பத்தை விட்டு வாடிக்கையாளரின் சொந்த பிழை கையாளுதலுக்குள் நுழைந்துள்ளீர்கள். journal இல் வாடிக்கையாளரின் செய்தியைத் தேடுங்கள், மற்றொரு execve தோல்வியை அல்ல. unit diff மற்றும் sudoers diff ஐ மாற்றப் பதிவில் ஒன்றாக வையுங்கள், அடுத்த மேம்படுத்தல் பிளவுபட்ட பாதையை அமைதியாக மீண்டும் கொண்டு வராதபடி.

தொடர்புடைய கட்டுரைகள்