Claude سے sysadmin کے 6 روزمرہ کام

سسٹم ایڈمنز کے لیے Claude: پہلے مشورہ، بعد میں عمل درآمد

Claude سسٹم ایڈمنز کے لیے reviewer کے طور پر بہترین کام کرتا ہے۔ آپ log کا اقتباس، configuration file، کوئی نامعلوم command، یا error string فراہم کرتے ہیں، اور بدلے میں ایسی وضاحت حاصل کرتے ہیں جسے box پر کوئی تبدیلی کرنے سے پہلے جانچا جا سکتا ہے۔ غلط جواب اس وقت تک کوئی نقصان نہیں دیتا جب تک آپ اسے run نہ کریں، اس لیے model کو اس حد کے مشاورتی جانب رکھنا ہی مکمل safety model ہے۔

کرائے کے Linux VPS (virtual private server) پر ہر ہفتے 6 کام سامنے آتے ہیں۔ ذیل میں ہر کام کے لیے ایک مؤثر prompt pattern، جواب کی تصدیق کرنے والی command، اور متوقع failure mode دیا گیا ہے۔ ان میں سے کسی کام کے لیے model کو آپ کے server تک access درکار نہیں۔

Production box پر ترتیب اہم ہے: پہلے وضاحت پڑھیں، خود check run کریں، پھر فیصلہ کریں۔ Scratch VM پر autonomy قابل قبول ہے۔ آپ کے customers کو service دینے والے box پر review زیادہ محفوظ ہے، کیونکہ model اس state کو نہیں دیکھ سکتا جس کے بارے میں وہ اندازہ لگا رہا ہے۔

جو چیزیں کبھی paste نہ کریں

Prompt میں موجود ہر چیز آپ کے server سے باہر چلی جاتی ہے۔ درج ذیل چار اقسام کی معلومات server پر ہی رہنی چاہییں:

• Private keys: ~/.ssh/id_ed25519، /etc/ssh/ssh_host_*_key، اور /etc/letsencrypt/live/ کے تحت موجود کوئی بھی TLS (transport layer security) key۔
• Credential files: .env، ~/.aws/credentials، /root/.docker/config.json، اور کسی بھی file یا log line میں موجود database passwords۔
• Account data: /etc/shadow اور /etc/gshadow۔ کسی بھی sysadmin سوال کا جواب دینے کے لیے password hash درکار نہیں ہوتا۔
• آپ کے users سے متعلق کوئی بھی چیز: email addresses، order rows، اور ایسے request logs جن میں session cookies یا PII (personally identifiable information) شامل ہو۔

Public keys کو paste کرنا محفوظ ہے۔ Private keys محفوظ نہیں ہوتیں، اور بظاہر دونوں files ایک جیسی لگ سکتی ہیں، اس لیے copy کرنے سے پہلے پہلی line پڑھیں: جس file کی پہلی line میں BEGIN OPENSSH PRIVATE KEY شامل ہو، اسے کبھی prompt میں شامل نہ کریں۔ اپنے SSH key material کو درست طور پر الگ رکھنا اس مقصد کے لیے دس منٹ صرف کرنے کے قابل ہے۔

Paste کرنے سے پہلے redaction کریں۔ 200 lines میں ایک token خود تلاش کرنے پر بھروسا نہ کریں:

sudo journalctl -u myapp -n 200 --no-pager | sed -E 's/(token|secret|password|api[_-]?key)[=:][^[:space:]]+/\1=REDACTED/gI'

Docker سے متعلق ایک خاص خطرہ موجود ہے۔ docker compose config آپ کی .env values کو اپنے output میں شامل کر دیتا ہے، اس لیے یہ output secret ہوتا ہے، چاہے disk پر موجود file secret نہ ہو۔ docker compose config -q استعمال کریں؛ یہ validation کرتا ہے اور کچھ بھی print نہیں کرتا۔ Agent کو کیا کچھ دیکھنے کی اجازت ہے، اس کی وسیع تر policy کے لیے AI agents سے secrets باہر رکھنا environment سے متعلق پہلوؤں کی وضاحت کرتا ہے۔

کام 1: یہ سروس کیوں ناکام ہوئی؟

اس جواب کے لیے پہلے یہ دو کمانڈز چلائیں:

systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service -b -n 100 --no-pager -o short-iso

دونوں کمانڈز کا نتیجہ اس سیاق کے ساتھ فراہم کریں جس کا ماڈل خود اندازہ نہیں لگا سکتا: distribution اور version، آخری بار آپ نے کیا تبدیل کیا، کیا یہ سروس پہلے کبھی درست طور پر چل چکی ہے، اور یہ کتنی دیر پہلے خراب ہوئی۔ پہلے mechanism معلوم کرنے کو کہیں۔

Ubuntu 24.04۔ myapp.service اس وقت تک درست چل رہا تھا جب تک میں نے ایک گھنٹہ پہلے unit میں ترمیم نہیں کی۔ یہ systemctl status اور journal کی آخری 100 سطریں ہیں۔ پہلی حقیقی error کون سی ہے، اور اس کا مطلب کیا ہے؟ فی الحال کوئی fix نہ دیں۔

اس prompt میں "فی الحال کوئی fix نہ دیں" کا مقصد اہم ہے۔ Logs میں پہلی failure اکثر اس کے نتیجے میں ہونے والی retries کے نیچے دب جاتی ہے، اس لیے fix مانگنے پر ماڈل عموماً آخری نظر آنے والی سطر کی وضاحت کرتا ہے۔ متعلقہ سطر عموماً اس شور سے بیس سطریں اوپر ہوتی ہے۔

نتیجے میں Main PID: 1841 (code=exited, status=203/EXEC) جیسی سطر مل سکتی ہے۔ Exit status 203/EXEC کا مطلب ہے کہ kernel ExecStart میں درج file کو execute نہیں کر سکا: یا تو path موجود نہیں، یا file موجود ہے لیکن executable نہیں ہے۔ #! میں ایسے interpreter کا نام درج ہو جو installed نہ ہو، تو یہی status پیدا ہوتا ہے۔ ان تمام صورتوں کی ls -l اور head -1 سے جانچ کی جا سکتی ہے۔

ناکامی کی صورت: فرضی وجہ۔ اگر آپ بہت کم متن فراہم کریں گے تو ماڈل خلا کو کسی عمومی وجہ سے پُر کر دے گا، مثلاً "port پہلے سے استعمال میں ہے"۔ اس کا حل یہ سوال دوبارہ پوچھنا ہے: "میں نے جو متن فراہم کیا ہے، اس میں کون سی سطر اس دعوے کی تائید کرتی ہے؟" جس وجہ کی طرف متن میں کوئی سطر اشارہ نہ کرے، وہ صرف ایک اندازہ ہے۔

Job 2: systemd unit یا cron entry کا مسودہ تیار کریں

اسے وہ معلومات دیں جو unit file کو درکار ہوتی ہیں: مکمل command، وہ user جس کے طور پر یہ چلتی ہے، working directory، آیا اسے network کے دستیاب ہونے تک انتظار کرنا چاہیے، اور non-zero exit پر کیا کارروائی ہونی چاہیے۔ کسی چیز کو enable کرنے سے پہلے واپس ملنے والے نتیجے کی تصدیق کریں۔

sudo systemd-analyze verify /etc/systemd/system/myapp.service
sudo systemctl daemon-reload
sudo systemctl start myapp.service
systemctl status myapp.service --no-pager

systemd-analyze verify فائل کو اسی طرح parse کرتا ہے جیسے systemd کرتا ہے، اس لیے وہ ایسی غلطیاں بھی پکڑ لیتا ہے جن پر انسانی نظر نہیں جاتی۔ غلط املا والا directive /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring. دکھاتا ہے۔ موجود نہ ہونے والا binary Command /usr/local/bin/myapp is not executable: No such file or directory دکھاتا ہے۔ دونوں daemon-reload کے دوران خاموش رہتے ہیں۔ اسی لیے unit درست طور پر load ہو سکتی ہے، لیکن چلتے ہی fail ہو جاتی ہے۔

مسودہ تیار کرتے وقت دو غلطیاں بار بار سامنے آتی ہیں۔ پہلی After=network.target ہے، جس کا مطلب صرف یہ ہے کہ network stack configured ہے؛ اس کا مطلب یہ نہیں کہ address پہلے ہی موجود ہے۔ جو service کسی مخصوص IP پر bind ہوتی ہے، وہ boot کے وقت bind: Cannot assign requested address کے ساتھ fail ہو جاتی ہے۔ اس کا حل Wants=network-online.target کو After=network-online.target کے ساتھ استعمال کرنا ہے۔ دوسری غلطی daemonise ہونے والے program کے لیے Type=simple استعمال کرنا ہے۔ systemd پہلے process کو service سمجھتا ہے، parent فوراً exit ہو جاتا ہے، اور unit dead قرار پاتی ہے، جبکہ اصل process غیر منظم طور پر چلتا رہتا ہے۔

Schedule کے لیے اسے پڑھنے کے بجائے check کریں:

systemd-analyze calendar 'Mon *-*-* 04:00:00'

یہ normalised form اور expression کے اگلی بار execute ہونے کا وقت دکھاتا ہے۔ اس سے اس کے مطلب پر ہونے والی بحث ختم ہو جاتی ہے۔ اگر آپ timer اور crontab کے درمیان انتخاب کر رہے ہیں تو VPS پر systemd services اور timers میں دونوں کے فرق کی وضاحت موجود ہے۔

Cron میں ایک ایسی خرابی کا امکان ہوتا ہے جس کے بارے میں کوئی model تب تک خبردار نہیں کرے گا جب تک آپ پوچھیں نہیں۔ Cron jobs کو minimal environment کے ساتھ چلاتا ہے۔ اس لیے PATH تقریباً /usr/bin:/bin ہوتا ہے، اور آپ کا shell profile کبھی read نہیں کیا جاتا۔ جو job آپ terminal میں paste کرنے پر کام کرتی ہے، وہ cron کے تحت /bin/sh: 1: docker: not found کے ساتھ fail ہو سکتی ہے، کیونکہ وہ binary /usr/local/bin میں موجود ہے۔ crontab میں absolute paths استعمال کریں۔

کام 3: Nginx یا Compose فائل کو live کرنے سے پہلے اس کا جائزہ لیں

اس کام کا فائدہ سب سے زیادہ ہے۔ فائل paste کریں، بتائیں کہ اسے کیا کرنا چاہیے، اور line by line وضاحت طلب کریں کہ یہ حقیقت میں کیا کرتی ہے۔

اس vhost کو example.com کو HTTPS کے ذریعے serve کرنا چاہیے اور /api کو port 8080 پر موجود local service تک proxy کرنا چاہیے۔ اسے دوبارہ پڑھ کر بتائیں اور ایسی ہر چیز کی نشاندہی کریں جو اس وضاحت سے مطابقت نہیں رکھتی۔

پھر وہ tool چلائیں جو grammar کو سمجھتا ہے:

sudo nginx -t
docker compose config -q

nginx -t، nginx: configuration file /etc/nginx/nginx.conf test is successful دکھاتا ہے، یا file اور line کا نام بتاتا ہے، جیسا کہ nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12 میں ہے۔ docker compose config -q اس وقت کچھ نہیں دکھاتا جب file درست طور پر parse ہو جائے، جبکہ indentation میں غلطی ہونے پر yaml: line 7: did not find expected key جیسا واضح error دکھاتا ہے۔

کوئی بھی tool ارادے کی جانچ نہیں کرتا۔ nginx -t سے کامیاب ہونے والی config پھر بھی غلط port تک proxy کر سکتی ہے، یا 0.0.0.0 پر listen کر سکتی ہے، حالانکہ آپ کا مقصد 127.0.0.1 تھا۔ یہی وہ خلا ہے جہاں model مفید ثابت ہوتا ہے، اور یہی وہ مقام بھی ہے جہاں یہ ناکام ہوتا ہے: جب اسے ایک directive درست کرنے کو کہا جائے تو یہ اکثر پوری file دوبارہ لکھ دیتا ہے اور آپ کی دو directives خاموشی سے غائب ہو جاتی ہیں۔ تبدیل شدہ lines اور ہر تبدیلی کی وجہ طلب کریں، پھر خود edit کریں۔

تصدیق کریں کہ آپ نے حقیقت میں کیا expose کیا ہے:

sudo ss -tulpn

sudo کے بغیر آپ listening sockets دیکھ سکتے ہیں، لیکن ان کے مالک processes نہیں دیکھ سکتے۔ اگر اس output سے آپ کو حیرت ہو تو ports کیا ہیں اور Linux انہیں کیسے bind کرتا ہے مختصر وضاحت ہے۔

کام 4: ناواقف command چلانے سے پہلے اس کی وضاحت کریں

command paste کریں اور اس کے بارے میں چار سوال پوچھیں: ہر flag کیا کرتا ہے، یہ کیا لکھتا ہے، کیا حذف کرتا ہے، اور اسے دو بار چلانے پر کیا ہوتا ہے۔ آخری سوال باقی سوالات کی نسبت زیادہ نقصان کا پتہ لگاتا ہے۔

find /var/log -name '*.gz' -mtime +7 -delete کو دیکھیں۔ اچھا جواب آپ کو بتاتا ہے کہ -mtime +7 مکمل 24 گھنٹے کے ادوار گنتا ہے اور باقی fraction کو نظرانداز کرتا ہے، اس لیے یہ کم از کم آٹھ دن پرانی files سے match کرتا ہے، سات دن پرانی files سے نہیں۔ یہ بھی بتاتا ہے کہ find اپنی expression کو بائیں سے دائیں evaluate کرتا ہے، اس لیے -delete کو -name سے پہلے رکھنے پر starting path کے اندر موجود ہر چیز حذف ہو جاتی ہے۔ یہ دوسری بات find کے man page میں warning کے طور پر درج ہے، اور اس کی وجہ سے لوگوں نے اپنی /var/log گنوائی ہیں۔

یا rsync -a --delete /srv/app/ /backup/app/ کو دیکھیں۔ source کے آخر میں موجود slash کا مطلب ہے: "اس directory کے contents"۔ اسے ہٹا دیں تو آپ کو /backup/app/app/ ملتا ہے۔ --delete شامل کرنے پر destination میں موجود وہ ہر چیز حذف ہو جاتی ہے جو source میں موجود نہیں، جو mirror کے لیے درست ہے لیکن source path غلط ہونے پر تباہ کن ہے۔

model کے بجائے tool سے تصدیق کریں:

rsync -a --delete --dry-run /srv/app/ /backup/app/ | head -20
find /var/log -name '*.gz' -mtime +7

find کو -delete کے بغیر چلائیں، تو نقصان کے بجائے list حاصل ہوگی۔

ناکامی کی صورت: flag کا غلط تصور۔ تیس سالہ documentation والے tools کے بارے میں model عموماً قابلِ اعتماد ہوتا ہے، لیکن vendor CLIs (command line interfaces) اور حالیہ subcommands کے معاملے میں کم قابلِ اعتماد ہوتا ہے۔ وہاں یہ ایسا flag بنا دیتا ہے جو پڑھنے میں بالکل درست لگتا ہے، مگر موجود نہیں ہوتا۔ --help اسے ایک second میں ثابت کر دیتا ہے۔ Quoting دوسری کمزور جگہ ہے۔ اس لیے جب کوئی command $(...) expression کو wrap کرتی ہو تو اس بات کا طریقہ پڑھیں کہ command چلنے سے پہلے command substitution کیسے expand ہوتی ہے، صرف explanation پر بھروسا نہ کریں۔

Job 5: اپنی shell history کو runbook میں تبدیل کریں

آپ نے ابھی کسی چیز کو کام کرنے کے قابل بنانے میں دو گھنٹے صرف کیے ہیں۔ یہ معلومات آپ کے scrollback میں موجود ہیں، اور اگلے ماہ ختم ہو جائیں گی۔

history 200 > /tmp/session.txt

اس file کو پڑھیں اور کہیں بھی بھیجنے سے پہلے password، token یا customer identifier رکھنے والی ہر line حذف کریں۔ Linux box پر secret تلاش کرنے کے لیے shell history قابلِ اعتماد ترین جگہوں میں سے ایک ہے، کیونکہ ہر شخص کم از کم ایک بار کوئی secret inline درج کرتا ہے۔ اپنے ~/.bashrc میں HISTCONTROL=ignorespace set کریں، پھر leading space کے ساتھ درج کیا گیا command history میں بالکل نہیں لکھا جائے گا۔

قابلِ استعمال runbook تیار کرنے والا prompt صرف steps نہیں بلکہ checks بھی طلب کرتا ہے:

یہ ایک shell session ہے جس میں ایک fresh Debian 13 box کو کام کرنے والے Postgres install میں تبدیل کیا گیا۔ اسے numbered runbook کی صورت میں لکھیں۔ ہر step میں ایک command ہو۔ ہر step کے بعد وہ command دیں جو ثابت کرے کہ step کامیاب رہا، اور بیان کریں کہ healthy output کیسا دکھائی دیتا ہے۔ ہر ایسے step کو نشان زد کریں جو میرے مخصوص host پر منحصر تھا۔

Failure mode: ایک صاف ستھری داستان۔ آپ کے session میں ایک step ایسا تھا جو درست کرنے سے پہلے آپ سے دو بار غلط ہوا، اور model اسی step کو ہموار کر دیتا ہے، کیونکہ اس کے بغیر transcript زیادہ صاف دکھائی دیتا ہے۔ runbook کا اپنی history سے موازنہ کریں اور correction واپس شامل کریں۔ یہ قابلِ یقین verification commands بھی خود بنا دیتا ہے، اس لیے file محفوظ کرنے سے پہلے اس کے لکھے ہوئے ہر check کو چلائیں۔ اگر runbook first boot کا احاطہ کرتا ہے تو اسے نئے VPS کے پہلے دس منٹ کے ساتھ ملا کر پڑھیں، تاکہ آپ حل شدہ مسئلے کا اس سے بھی بدتر ورژن تحریر نہ کر دیں۔

کام 6: error message کو fix میں تبدیل کریں

عین error string، وہ command جس نے یہ error پیدا کیا، اور error ظاہر ہونے سے پہلے کی گئی واحد تبدیلی paste کریں۔ ممکنہ وجوہات کو ترجیحی ترتیب میں بیان کرنے اور ہر وجہ کے لیے فرق واضح کرنے والی ایک command دینے کو کہیں۔ اس سے جواب قابلِ آزمائش بن جاتا ہے۔

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)۔ ممکنہ وجوہات کو ترجیحی ترتیب میں بیان کریں اور ہر وجہ کے لیے ایک ایسی command دیں جو اسے ثابت یا خارج کر دے۔

اس error کا mechanism واضح ہے: ایک اور process پہلے ہی port 80 پر قابض ہے، اور sudo ss -tulpn | grep ':80 ' اس process کا نام ظاہر کرتا ہے۔ اکثر یہ failed reload کے بعد موجود رہ جانے والا دوسرا nginx master ہوتا ہے، یا dependency کے طور پر شامل کیا گیا Apache ہوتا ہے جو اپنے package کے ذریعے start ہو جاتا ہے۔

Failure mode: ایسا fix جو وجہ کو چھپا کر کام کرے۔ chmod 777، --privileged، SELinux کو disable کرنا، اور service کو root کے طور پر چلانا، سب error کو غائب کر دیتے ہیں۔ جب تک model یہ واضح نہ کر دے کہ محدود permission کیوں ناکام ہوئی، permissions کو وسیع کرنے والے کسی fix کو قبول نہ کریں۔ یہی وضاحت اصل جواب ہے۔ Workaround صرف error کو خاموش کرتا ہے۔

یہ قابلِ اعتماد طور پر کہاں غلطی کرتا ہے

• یہ آپ کے server کو دیکھ نہیں سکتا۔ ہر جواب آپ کے فراہم کردہ متن پر منحصر ہوتا ہے، اور یہ نہیں بتائے گا کہ اقتباس بہت مختصر تھا۔
• یہ versions کے معاملے میں بھٹک جاتا ہے۔ مختلف distributions اور releases میں package names اور default flags بدلتے رہتے ہیں، جبکہ model ان سب کی بنیاد پر ایک عمومی جواب بناتا ہے۔
• غلط ہونے کے باوجود یہ رواں انداز میں جواب دیتا ہے۔ فرضی mechanism بالکل درست mechanism جیسا پڑھائی دے سکتا ہے۔ اسی لیے اوپر بیان کی گئی ہر وجہ کے ساتھ ایسا command دیا گیا ہے جو اسے test کرتا ہے۔
• طویل sessions میں یہ سلسلہ بھول جاتا ہے۔ دو گھنٹے کی گفتگو کے آغاز میں موجود facts آخر میں دیے گئے جوابات پر اثرانداز ہونا بند کر دیتے ہیں۔

یہ آخری مسئلہ model کے بجائے عملی کام کا مسئلہ ہے، اور طویل Claude Code session میں context کا انتظام اس کا عملی حل ہے: مختصر sessions رکھیں اور ہر session میں ایک ہی task کریں۔

سرور پر agent چلانا

اوپر دی گئی تمام ہدایات copy اور paste کرنے تک محدود ہیں، اس لیے model آپ کی machine کو کبھی براہِ راست نہیں چھوتا۔ جب یہ خود server پر چل کر files پڑھنے اور commands execute کرنے لگے تو risk کی نوعیت بدل جاتی ہے: اب ایک غلط command کسی service کو بند کر سکتی ہے۔ اسے root کے بجائے اپنا unprivileged user دیں، اس کے طریقۂ کار کو سمجھنے تک اسے production box سے الگ رکھیں، اور پہلے snapshot لے لیں۔ VPS پر Claude Code کو محفوظ طریقے سے چلانا sandboxing اور permission model کی وضاحت کرتا ہے۔ tmux کے اندر Claude Code چلانا مسئلے کے دوسرے حصے کو حل کرتا ہے، کیونکہ SSH (secure shell) session منقطع ہونے پر foreground agent اپنا کام مکمل ہونے سے پہلے رک جاتا ہے۔ اس account کو اسی طرح بنائیں جیسے آپ کوئی service account بناتے ہیں؛ VPS پر least privilege users میں اس کی تفصیل موجود ہے۔

FAQ

کیا Claude میرے server logs براہِ راست پڑھ سکتا ہے؟

خود سے نہیں۔ Chat interface صرف وہ متن دیکھتا ہے جو آپ اس میں paste کرتے ہیں۔ Server پر command line tool کے طور پر چلنے والا Claude Code، اسے شروع کرنے والے user کی permissions کے مطابق files پڑھ اور commands چلا سکتا ہے۔ یہ زیادہ بڑا trust decision ہے۔ عام support سوال کے لیے redacted 100 line excerpt paste کرنا کسی agent کو shell access دینے سے زیادہ تیز اور محفوظ ہے۔

مجھے server سے کیا چیز کبھی paste نہیں کرنی چاہیے؟

Private keys، .env files اور دیگر credential stores، /etc/shadow، اور آپ کے users سے متعلق کوئی بھی data۔ Log excerpts prompt تک پہنچنے سے پہلے tokens کو redact کریں۔ ایک کم واضح صورت یہ ہے کہ docker compose config کے output میں آپ کی .env values interpolate ہو جاتی ہیں۔ اس لیے docker compose config -q استعمال کریں، جو file کی توثیق کرتا ہے اور کچھ بھی print نہیں کرتا۔

کیا production VPS پر Claude کو commands چلانے دینا محفوظ ہے؟

اسے ایسے نئے admin کی طرح سمجھیں جسے کوئی context معلوم نہیں: پڑھنے کے لیے مناسب، writing کے لیے review ضروری ہے۔ Production پر explanation طلب کریں اور command خود چلائیں۔ اگر آپ واقعی agent سے execution کرانا چاہتے ہیں تو اسے blanket sudo کے بغیر dedicated unprivileged account دیں، اور آغاز staging box سے کریں، جہاں غلطی کی صورت میں outage کے بجائے rebuild کرنا پڑے۔

Claude ایسا flag کیوں تجویز کرتا ہے جو موجود ہی نہیں ہوتا؟

کیونکہ یہ ممکنہ متن predict کرتا ہے، اور plausible flag حقیقی flag جیسا ہی دکھائی دیتا ہے۔ یہ مسئلہ vendor CLIs اور نئے subcommands میں زیادہ ہوتا ہے، جہاں model کے پیچھے موجود documentation محدود یا بعد میں تبدیل ہو چکی ہوتی ہے۔ --help اور man فیصلہ کن معیار ہیں، اور جو بھی command data delete یا overwrite کرتی ہو، اسے پہلے dry run میں چلانا چاہیے۔

میں enable کرنے سے پہلے systemd unit کو کیسے check کروں؟

sudo systemd-analyze verify /etc/systemd/system/myapp.service چلائیں۔ یہ systemd کے اپنے parser سے file parse کرتا ہے، unknown directives کو ان کے line numbers کے ساتھ report کرتا ہے، اور ایسے ExecStart binary کی نشاندہی کرتا ہے جو missing ہو یا executable نہ ہو۔ پھر daemon-reload اور start چلائیں، اور systemctl status پڑھیں، اس سے پہلے کہ آپ اسے enable کریں، کیونکہ جو unit cleanly load ہو جائے وہ پہلی بار چلنے پر پھر بھی fail ہو سکتی ہے۔