کسی بھی سسٹم مشین پر ٹرمینل کھولیں اور چلائیں:
systemd-analyze
یہ وہی ہے جو لیپ ٹاپ پر لکھا ہے جس پر میں یہ لکھ رہا ہوں:
Startup finished in 5.855s (firmware) + 8.469s (loader) + 3.106s (kernel)
+ 12.181s (userspace) = 29.613s
graphical.target reached after 12.175s in userspace
ان چاروں کو ایک ساتھ شامل کرنے سے 29.611 ملتا ہے، آخری سطر پر چھپی ہوئی 29.613 نہیں۔ خلا حقیقی ہے اور غلطی نہیں ہے۔ systemd-analyze پہلے سے طے شدہ مائیکرو سیکنڈز کو شامل کرتے وقت، ہم ڈسپلے کے لیے ہر قدم کو چھوٹا کرتے ہیں، اس لیے راؤنڈنگ چند ملی سیکنڈز کو چھپا دیتی ہے۔ یہ ایک چھوٹی سی چیز ہے، اور ایسے کیڑے تلاش کرنے میں آپ کا وقت بچائے گا جو وہاں نہیں ہیں۔
چار نمبر اور زیادہ تر لوگوں کے ذہنی ماڈل ان میں سے ایک کو بیان کرتے ہیں۔ دانا نے 3 سیکنڈ کا وقت لیا۔ پچھلے بوٹ لوڈر میں ساڑھے 8 گھنٹے لگے، اور پچھلے فرم ویئر میں تقریباً 6 گھنٹے لگے۔ اس مشین کے بوٹ کے چودہ سیکنڈ لینکس کے چلنے سے پہلے واقع ہوئے، اور میں نے اس کا ایک اچھا حصہ بغیر توجہ کیے اٹھا لیا۔
اس مضمون میں، ہم پورے اصل بوٹ کے عمل کے ذریعے لینکس بوٹ کے عمل کی پیروی کرتے ہیں، فرم ویئر پروسیسنگ کنٹرول سے لے کر بوٹ لوڈر تک آن اسکرین لاگ ان پرامپٹ تک۔ یہاں ہر چیز براہ راست چلائی جا سکتی ہے۔ بہت کم کو جڑ کی ضرورت ہوتی ہے۔
انڈیکس
آپ کو کیا ضرورت ہے
Ubuntu, Debian, Fedora, Arch، اور کوئی بھی لینکس سسٹم چلانے والا systemd، جو زیادہ تر چیزوں کا احاطہ کرتا ہے جو لوگ 2026 میں انسٹال کریں گے۔ ٹرمینل۔ بس۔
میں جس مشین کی پیمائش کر رہا ہوں وہ Ubuntu 22.04.5 LTS چلانے والی کرنل 5.15.0-190-generic ہے۔ میں UEFI موڈ میں NVMe ڈسک پر ایک ext4 روٹ فائل سسٹم کے ساتھ بوٹ کرتا ہوں اور PID 1 کے طور پر systemd 249۔ آپ کی مشین بعض اوقات بہت مختلف ہو سکتی ہے، اور ہم آپ کو بتائیں گے کہ کیا توقع رکھی جائے۔
ایک کمانڈ کے لیے روٹ کی ضرورت ہوتی ہے اور ایک فائل بہت سے سسٹمز پر محدود ہوتی ہے۔ جب میں وہاں پہنچوں گا تو میں آپ دونوں کی اطلاع دوں گا۔
لینکس بوٹ کا عمل ایک کے بجائے چار ہینڈ آف ہے۔
لفظ "بوٹ” سے مراد ایک عمل ہے۔ لیکن ہم چاروں ایک دوسرے کے بارے میں بہت کم جانتے ہیں۔
فرم ویئر سب سے پہلے مدر بورڈ پر ایک چپ سے چلتا ہے، اور اس کا کام بوٹ ایبل چیز تلاش کرنا اور اسے شروع کرنا ہے۔
اس کے بعد یہ کنٹرول بوٹ لوڈر کے حوالے کر دیتا ہے اور رک جاتا ہے۔ بوٹ لوڈر کا کام دانا کو تلاش کرنا، اسے ابتدائی فائل سسٹم کے ساتھ میموری میں لوڈ کرنا، اور کرنل پر جانا ہے۔ پھر رک جاتا ہے۔
دانا ہارڈ ویئر کو لوڈ کرتا ہے، روٹ فائل سسٹم کو ماؤنٹ کرتا ہے، اور بالکل یوزر اسپیس کا عمل شروع کرتا ہے۔ اس کے بعد یہ چارج لینا بند کر دیتا ہے، لیکن اس کے بعد ہمیشہ کے لیے اس عمل کو جاری رکھتا ہے۔
پہلا عمل، PID 1، باقی سب کو شروع کرتا ہے۔

ہر ہینڈ آف ایک طرفہ ہے۔ فرم ویئر لینکس کے تحت مدد کا انتظار نہیں کر رہا ہے۔ بوٹ لوڈر میموری سے غائب ہو گیا ہے۔ براہ کرم ایک لمحہ انتظار کریں۔ یہ بتاتا ہے کہ چار نمبر کیوں ہیں۔ systemd-analyze وہ مختلف چیزوں سے ماپا جاتا ہے اور مختلف چیزوں کا مطلب ہوتا ہے۔
فرم ویئر اور جو لینکس کبھی نہیں دیکھتا ہے۔
فرم ویئر کے مطابق 5.855 سیکنڈ واحد نمبر ہے جسے لینکس خود نہیں ماپتا ہے، اور آپ اس نمبر کا صحیح ذریعہ پڑھ سکتے ہیں۔
cat /sys/firmware/acpi/fpdt/boot/bootloader_launch_ns
5855973785
5.855973785 سیکنڈ، یا 5.855 سیکنڈ۔ systemd-analyze ڈسپلے کے لیے اطلاع دی گئی اور کاٹ دی گئی۔ اسے حوالے کرنے سے پہلے، فرم ویئر اسے ایک ACPI ٹیبل پر لکھتا ہے جسے فرم ویئر پرفارمنس ڈیٹا ٹیبل کہتے ہیں، اور کرنل اس ڈائرکٹری کے تحت ٹیبل میں موجود فیلڈز کو ظاہر کرتا ہے۔ باقی میں بھائی بھرتا ہے۔
cat /sys/firmware/acpi/fpdt/boot/exitbootservice_end_ns
یہ سسٹم 14325507185، یا 14.325 سیکنڈ پڑھتا ہے، جو کہ ایک ساتھ جوڑے گئے دو مراحل سے مطابقت رکھتا ہے: فرم ویئر اور بوٹ لوڈر مشترکہ۔
یہ وہ حصہ ہے جو لوگوں کو چوکس کر دیتا ہے۔ گیٹ UEFI نہیں ہے، یہ ہے کہ آیا فرم ویئر FPDT شائع کرتا ہے۔ بہت سی UEFI مشینیں ایسا نہیں کرتی ہیں۔ خاص طور پر ورچوئل مشینیں نہیں۔ systemd-analyze یہ نہ تو فرم ویئر کے مرحلے اور نہ ہی لوڈر مرحلے کی اطلاع دیتا ہے۔ حساب دانا کے ذریعہ شروع کیا جاتا ہے۔ غیر UEFI ٹیبل کو چیک کریں۔
ls /sys/firmware/acpi/fpdt/boot/ 2>/dev/null || echo "no FPDT, so no firmware timing"
اگر کچھ بھی پرنٹ نہیں ہوتا ہے تو، فرم ویئر اس کی اطلاع نہیں دے رہا ہے اور لینکس کے اندر سے نمبر بازیافت کرنے کا کوئی طریقہ نہیں ہے۔
تقریباً 6 سیکنڈ بہت زیادہ وقت ہے اور لینکس کے اندر آپ بہت کچھ نہیں کر سکتے۔ یادداشت کی تربیت، ڈیوائس کی گنتی، اور جو کچھ بھی وینڈر اسے دینے سے پہلے چلانے کا فیصلہ کرتا ہے۔ تیز اسٹوریج والے لیپ ٹاپ پر، یہ اکثر واحد سب سے بڑا قدم ہوتا ہے، جو سروس کو بہتر بنانے کی کوششیں کرنے والوں کو حیران کر دیتا ہے۔
بوٹ لوڈر اور آپ کی پسند کے 5 سیکنڈ
یہاں ایسے نمبر ہیں جو بدلتے ہیں کہ پوری آؤٹ پٹ کو کیسے پڑھا جاتا ہے: لوڈر کے مرحلے میں 8.469 سیکنڈ لگے، جو کرنل کے لیے لگنے والے وقت سے تقریباً تین گنا زیادہ ہے۔ اس میں سے تقریباً کوئی بھی کام نہیں تھا۔
grep ^GRUB_TIMEOUT /etc/default/grub
اس مشین پر:
GRUB_TIMEOUT="5"
8.469 سیکنڈ میں سے 5 وہ وقت ہوتا ہے جب GRUB کاؤنٹ ڈاؤن ہوتا ہے اور ایک کی پریس کا انتظار کرتا ہے جو کبھی نہیں آتا ہے۔ یہ شاید ایک کنفیگریشن ہے جسے انسٹالر نے ایک بار منتخب کیا ہے اور اس کا دوبارہ کبھی جائزہ نہیں لیا جائے گا۔ اگر آپ سوچ رہے ہیں کہ اچھے ہارڈ ویئر کے باوجود آپ کا کمپیوٹر شروع ہونے میں سست کیوں محسوس ہوتا ہے، تو یہ اس پورے مضمون میں دیکھنے کے لیے پہلی جگہ اور سب سے سستا حل ہے۔
GRUB پہلے ہی جانتا ہے کہ انتظار کرتے وقت کیا کرنا ہے۔ آپ دی گئی ہدایات کو پڑھ سکتے ہیں۔
cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.15.0-190-generic root=UUID=b4d0343e-9df4-40a7-be97-dcd51bdbf553
ro splash intel_iommu=on vt.handoff=7
یہ ایک لائن بوٹ لوڈر اور کرنل کے درمیان مکمل معاہدہ ہے۔ BOOT_IMAGE کون سا دانا بھرا ہوا ہے۔ root=UUID=... فائل سسٹمز کا نام دے کر آپ ڈیوائس کے ناموں کے بجائے UUIDs کے طور پر ماؤنٹ کرتے ہیں، وہ ڈسک کے دوبارہ نمبروں میں محفوظ رہتے ہیں۔ ro یہ کہتا ہے کہ ابتدائی طور پر اسے صرف پڑھنے کے لیے ماؤنٹ کریں۔ splash متن کو سکرول کرنے کے بجائے گرافیکل بوٹ اسکرین کی درخواست کریں۔ intel_iommu=on IOMMU کو فعال کریں اور vt.handoff=7 اوبنٹو ورچوئل ٹرمینل کو پلک جھپکائے بغیر گرافکس اسٹیک پر منتقل کرتا ہے۔
GRUB دو فائلوں کو میموری میں لوڈ کرتا ہے: کرنل اور ایک ابتدائی فائل سسٹم امیج، جس کے بارے میں ہم جلد ہی بات کریں گے۔ یہ پھر دانا میں چھلانگ لگاتا ہے اور اب موجود نہیں رہتا ہے۔
دانا کا مرحلہ: چلتی مشین تک 3 سیکنڈ
لینکس اب چل رہا ہے۔ دانا خود کو کھولتا ہے، میموری کا انتظام ترتیب دیتا ہے، سی پی یو کو لوڈ کرتا ہے، ڈرائیوروں کو شروع کرتا ہے، اور روٹ فائل سسٹم کو تلاش کرتا ہے۔
دیکھیں کہ ٹائم اسٹیمپ کے ساتھ کیا ہوتا ہے جس وقت سے کرنل شروع کیا گیا تھا۔
journalctl -k -b -o short-monotonic | head
[ 0.000000] devils-dell kernel: microcode: microcode updated early to revision 0x100
[ 0.000000] devils-dell kernel: Linux version 5.15.0-190-generic
[ 0.000000] devils-dell kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-190-generic
[ 0.000000] devils-dell kernel: KERNEL supported cpus:
0 وہ ہوتا ہے جب کرنل چلنا شروع ہوتا ہے، نہ کہ جب پاور بٹن دبایا جاتا تھا۔ اس مقام سے پہلے کی ہر چیز، یعنی فرم ویئر اور بوٹ لوڈر کے 14 سیکنڈ، اس گھڑی سے باہر ہے۔ یہ پہلی چیز ہے جسے آپ کو کرنل بوٹ ٹائم اسٹیمپ کے بارے میں سمجھنے کی ضرورت ہے، اور کیوں: dmesg آؤٹ پٹ کچھ سسٹمز کو اصل سے کہیں زیادہ تیز دکھاتا ہے۔
آپ پہنچ سکتے ہیں dmesg مجھے وہاں مسترد کر دیا گیا۔
dmesg: read kernel buffer failed: Operation not permitted
یہ جان بوجھ کر ہے اور اس کی تصدیق اس طرح کی جا سکتی ہے:
sysctl kernel.dmesg_restrict
اوبنٹو سیٹ kernel.dmesg_restrict = 1یہ کرنل رِنگ بفر کو روٹ تک محدود کر دیتا ہے کیونکہ یہ کرنل ایڈریس کو لیک کرتا ہے جو حملہ آوروں کے لیے مفید ہیں۔ استعمال کریں journalctl -k اس کے بجائے، یہ جریدے کے ذریعے وہی پیغامات پڑھتا ہے اور ایک عام صارف کی طرح کام کرتا ہے۔
مزید معلومات کے لیے /proc/cmdline یہ بتاتا ہے کہ لوگ کیا دیکھتے ہیں اور شاذ و نادر ہی تفتیش کرتے ہیں۔ کرنل کو روٹ فائل سسٹم کو ماؤنٹ کرنے کے لیے کہا جاتا ہے۔ roیہ صرف پڑھنے کے لیے ہے، لیکن اب آپ جو سسٹم استعمال کر رہے ہیں وہ اسے ڈسک پر واضح طور پر لکھتا ہے۔ چیک کریں کہ یہ آج کیسا لگتا ہے۔
findmnt -n -o SOURCE,FSTYPE,OPTIONS /
/dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro
اب یہ پڑھنا لکھنا ہے، تو کچھ بدل گیا ہے۔ روٹ فائل سسٹم کو پہلے صرف پڑھنے کے لیے نصب کیا جاتا ہے تاکہ فائل سسٹم چیک محفوظ طریقے سے چل سکے۔ کیونکہ فائل سسٹم کو چیک کرنا جب کوئی عمل لکھ رہا ہوتا ہے تو یہ ایک چھوٹی سی پریشانی کو بڑے مسئلے میں بدلنے کا نسخہ ہے۔
اگر یہ چیک پاس ہو جاتا ہے تو، یوزر اسپیس اسی فائل سسٹم کو دوبارہ پڑھتا ہے اور اپنی جگہ پر errors=remount-ro اگر آپ اختیارات کو دیکھیں تو آپ دیکھیں گے کہ مخالف وعدے ہیں۔ اگر دانا بعد میں فائل سسٹم کی خرابی سے ٹکراتا ہے، تو یہ کسی ایسی چیز پر لکھنے کے بجائے صرف پڑھنے کے لیے واپس آجاتا ہے جس پر اب اسے بھروسہ نہیں ہے۔
اب عین وہی لمحہ تلاش کریں جب دانا نے تنہا رہنا چھوڑ دیا تھا۔
journalctl -b -o short-monotonic | grep -m1 'systemd[1]'
[ 3.152109] devils-dell systemd[1]: Inserted module 'autofs4'
3.15 سیکنڈ کے بعد، PID 1 نے اپنی پہلی لائن ریکارڈ کی۔ یہ 3.106 سیکنڈ کے مساوی ہے۔ systemd-analyze آپ دانا کو پراپرٹی دیتے ہیں اور یہ ایک ہینڈ آف ہے۔ یہاں سے، دانا اپنے طور پر کچھ نہیں کرتا ہے۔ سسٹم کالز کا جواب دینا اور اس کے بعد کیے گئے تمام فیصلے صارف کی جگہ سے تعلق رکھتے ہیں۔
کیا initramfs اور مرغی اور انڈے کا مسئلہ حل ہو جاتا ہے۔
ان 3 سیکنڈز میں ایک قدم چھپا ہوا ہے، اور یہ وہ حصہ ہے جو لینکس کو بوٹ کرتے وقت لوگوں کو سب سے زیادہ الجھا دیتا ہے۔
دانا کو روٹ فائل سسٹم کو ماؤنٹ کرنا چاہیے۔ اس کے لیے سٹوریج کنٹرولر اور فائل سسٹم کے لیے ڈرائیورز کے ساتھ ساتھ RAID سرنی کو جمع کرنے، ایک خفیہ کردہ والیوم کھولنے، یا LVM کو فعال کرنے کے لیے کوڈ کی ضرورت ہوتی ہے۔ وہ ڈرائیور ایک ماڈیول میں رہتا ہے۔ ماڈیول روٹ فائل سسٹم میں واقع ہے۔ دانا ابھی تک نہیں لگایا جا سکتا۔
فرار ایک چھوٹا فائل سسٹم ہے جسے بوٹ لوڈر کرنل کے ساتھ میموری میں لوڈ کرتا ہے۔ اس پر ایک نظر ڈالیں:
ls -l /boot/initrd.img-$(uname -r)
lsinitramfs /boot/initrd.img-$(uname -r) | wc -l
lsinitramfs /boot/initrd.img-$(uname -r) | grep -c '.ko'
وہ راستے اور اوزار Debian اور Ubuntu کنونشنز ہیں۔ فیڈورا میں، تصویر اس طرح نظر آتی ہے: /boot/initramfs-$(uname -r).img اور ٹول ہے۔ lsinitrd. عام طور پر محراب میں /boot/initramfs-linux.imgایک ساتھ پڑھیں lsinitcpio.
اس مشین پر، تصویر 79,945,887 بائٹس (تقریبا 76 MB) ہے اور اس میں 2,318 فائلیں ہیں، جن میں سے 1,386 کرنل ماڈیول ہیں۔ یہ اصل میں کام کرتا ہے، جب تک کہ یہ ایک کم سے کم لینکس سسٹم ہے جو ایک مسئلہ کو حل کرنے کے لیے موجود ہے: اصل روٹ فائل سسٹم کو تلاش کرنا اور اسے ماؤنٹ کرنا۔
ایک بار کامیاب ہونے کے بعد، وہ کچھ غیر معمولی کرتے ہیں. یہ کبھی ختم نہیں ہوتا۔ اصلی راستے کو جگہ پر تبدیل کریں اور اپنے راستے میں آئے بغیر حقیقی راستہ چلائیں۔ /sbin/init نیا عمل درخت شروع کیے بغیر۔ PID 1 پرواز میں ID کو تبدیل کرتا ہے اور عمل ID کو برقرار رکھتا ہے۔
اگر آپ آرک یا کم سے کم فیڈورا انسٹالیشن استعمال کرتے ہیں، تو آپ کے initramfs اس سائز کا دسواں حصہ ہو سکتا ہے۔ اس کی وجہ یہ ہے کہ اوبنٹو عام ڈرائیور بناتا ہے جس میں ہارڈ ویئر کے ڈرائیور شامل ہوتے ہیں جو آپ کے پاس نہیں ہیں، تاکہ تمام سسٹمز پر ایک ہی تصویر بوٹ ہو۔ یہ پورٹیبلٹی اور سائز کے درمیان جان بوجھ کر تجارت ہے۔ lsinitramfs یہ آپ کو دکھائے گا کہ آپ کے پاس کیا ہے۔
PID 1، اور باقی 12 سیکنڈ کہاں جاتے ہیں؟
دانا 3.1 سیکنڈ میں مکمل ہوا۔ لاگ ان اسکرین صارف کی جگہ پر 12.175 سیکنڈ پر ظاہر ہوئی۔ تو بیچ میں کیا ہوا؟
systemctl get-default
systemctl list-unit-files --no-legend | wc -l
systemctl list-units --type=service --state=running --no-legend | wc -l
graphical.target
472
44
systemd کا ماڈل یہ ہے کہ آپ اپنے اہداف کو نام دیتے ہیں اور ان پر اسی ترتیب سے کام کرتے ہیں۔ مقصد یہاں ہے۔ graphical.targetخواہش مند multi-user.targetمیں ایک ورکنگ نیٹ ورک، فائل سسٹم، لاگنگ اور درجنوں دوسری چیزیں چاہتا ہوں۔
اس مشین میں 472 یونٹ فائلیں نصب ہیں اور 44 خدمات درحقیقت چل رہی ہیں۔ systemd ان سے انحصار کا گراف بناتا ہے اور متوازی طور پر ہر ممکن طریقے سے شروع کرتا ہے، صرف اس انتظار میں جہاں اصل انحصار موجود ہو۔
یہ ہم آہنگی بوٹ کے تجزیہ کو اس سے کہیں زیادہ مشکل بنا دیتی ہے۔ درجنوں چیزیں بیک وقت ہو رہی ہیں، اور تمام حصوں کا مجموعہ نہیں ہے۔
کیوں systemd-analyze blame بوٹ ٹائم کے بارے میں گمراہ کن
واضح درج ذیل کمانڈ غلط ہے اور جان بوجھ کر جال میں پھنسنے کے قابل ہے۔
systemd-analyze blame | head -5
3min 48.947s fstrim.service
44.548s plocate-updatedb.service
13.953s apt-daily.service
4.875s docker.service
4.106s NetworkManager-wait-online.service
یہ دیکھنے کے لیے پڑھیں کہ یہ کل سے کیسے موازنہ کرتا ہے۔ صارف کی جگہ میں 12.181 سیکنڈ لگے۔ اوپری اندراج 3 منٹ اور 49 منٹ دکھاتا ہے۔ دونوں نمبر درست ہیں، تضاد نقطہ ہے۔
blame جیسے ہی ہر آلہ شروع ہوتا ہے، سسٹم تمام آلات کے شروع ہونے میں لگنے والے وقت کی فہرست دیتا ہے۔ یہ آپ کو اس بارے میں کچھ نہیں بتاتا کہ آیا ڈیوائس لاگ ان اسکرین کے راستے میں ہے یا نہیں۔ سب سے اوپر تین چیک کریں:
systemctl show fstrim.service -p TriggeredBy -p WantedBy
systemctl list-timers fstrim.timer
TriggeredBy=fstrim.timer
WantedBy=
NEXT LEFT LAST PASSED
Mon 2026-09-14 00:59:36 IST 4 days left Mon 2026-09-07 00:33:35 IST 2 days ago
WantedBy یہ خالی ہے، اس لیے بوٹ پر کچھ نہیں اٹھایا جاتا۔ ٹائمر سے ٹرگر کیا گیا۔ یہ آخری بار دو دن پہلے چلا تھا اور چار دنوں میں دوبارہ چلے گا۔
plocate-updatedb.service اور apt-daily.service یہ ایک ہی شکل ہے، جو اس کے اپنے ٹائمر سے ٹرگر ہوتی ہے۔
سب سے اوپر 3 اشیاء ہیں blameلگ بھگ پانچ منٹ کے بوٹ ٹائم کا اس وقت پر کوئی اثر نہیں ہوا جو میں نے لاگ ان پرامپٹ کے انتظار میں گزارا۔
درحقیقت، بوٹ پاتھ میں پہلی چیز یہ ہے: docker.serviceیہ فہرست میں چوتھے نمبر پر ہے، 4.875 سیکنڈ میں۔
مخصوص کلاسوں کے بجائے عام کلاسز لینا بہتر ہے۔ ایک ایسا اقدام جو آپ کی دلچسپی کے سپر سیٹ کے بارے میں رپورٹ کرتا ہے آپ کو اس تناسب سے گمراہ کرے گا کہ اس سپر سیٹ کا کتنا حصہ غیر متعلقہ ہے۔ blame یہ ٹوٹا نہیں ہے۔ یہ ایک مختلف سوال کا جواب دیتا ہے جو لوگ پوچھ رہے ہیں۔
کریٹیکل چین ریڈنگ
وہ حکم جو آپ کے اصل سوال کا جواب دیتا ہے:
systemd-analyze critical-chain
graphical.target @12.175s
└─multi-user.target @12.175s
└─docker.service @7.297s +4.875s
└─network-online.target @7.295s
└─NetworkManager-wait-online.service @3.188s +4.106s
└─NetworkManager.service @3.151s +35ms
└─network-pre.target @3.150s
└─netfilter-persistent.service @1.377s +1.772s
└─local-fs.target @1.374s
کہ @ یہ اس وقت ہوتا ہے جب یونٹ چالو ہوتا ہے۔ کہ + اس میں کتنا وقت لگا۔ اب 12 سیکنڈ کا مطلب ہے۔ docker.service 4.875 پر اور NetworkManager-wait-online.service ان میں سے تقریباً 9 کے لیے 4.106 اکاؤنٹس ہیں اور اسے سیریلائز کیا گیا ہے کیونکہ ڈوکر شروع ہونے سے پہلے ایک ورکنگ نیٹ ورک چاہتا ہے۔
NetworkManager-wait-online یہ پہلی چیز ہے جسے آپ زیادہ تر ڈیسک ٹاپس پر دیکھتے ہیں۔ جیسا کہ نام سے پتہ چلتا ہے، یہ اس وقت تک بلاک ہوجاتا ہے جب تک کہ نیٹ ورک اصل میں نہ ہو، اور آپ کا وائی فائی سے منسلک لیپ ٹاپ چند سیکنڈ کے لیے کچھ نہیں کر سکتا۔ یہ موجود ہے تاکہ خدمات جن کے لیے نیٹ ورک کی ضرورت ہوتی ہے وہ اس وقت تک شروع نہیں ہوں گی جب تک کہ نیٹ ورک موجود نہ ہو۔ چاہے آپ کو اس طرح کی کوریج کی ضرورت ہے ایک حقیقی جواب کے ساتھ ایک حقیقی سوال ہے، اور یہ اس بات پر منحصر ہے کہ آپ کیا چلا رہے ہیں۔
اس آؤٹ پٹ کے بارے میں دو نوٹ۔ یہ تمام سست کی بجائے صرف ایک سلسلہ دکھاتا ہے، اس لیے وہ اکائیاں جو سست ہیں لیکن اہم راستے سے دور ہیں کبھی ظاہر نہیں ہوتیں۔ اور @ وقت کوئی سببی ترتیب نہیں ہے جسے اوپر سے نیچے تک پڑھا جا سکتا ہے۔ میرے آؤٹ پٹ میں ڈوکر نیٹ ورک ماؤنٹ ہے جس کا ٹائم اسٹیمپ 11 سیکنڈ کے ہدف کے نیچے ہے جو 650 ملی سیکنڈ میں مکمل ہوتا ہے۔ یہ ناممکن لگتا ہے جب تک کہ آپ کو یہ احساس نہ ہو کہ درخت واقعات کی ایک سیریز کے بجائے انحصار کناروں کو ظاہر کرتا ہے۔ پڑھیں + اقدار کی ساخت اور اخراجات کے لیے ترتیب کی رکاوٹوں کو جانیں، اور نیسٹنگ کو تاریخ کے مطابق نہ پڑھیں۔
لینکس کے بوٹ کے اوقات مختلف کیوں ہیں۔
مندرجہ بالا سبھی ایک سسٹم پر ایک بوٹ ہے، مخصوص نمبر طریقوں سے کم قیمتی ہیں۔ اپنے سے میرا موازنہ کرنے سے پہلے معلوم کریں کہ کون سے حصے حرکت کرتے ہیں اور کیوں۔
فرم ویئر کے اوقات کسی بھی چیز سے زیادہ مختلف ہوتے ہیں اور اس کا لینکس سے بہت کم تعلق ہے۔ اس لیپ ٹاپ کے 6 سیکنڈ کے مقابلے میں ایک ڈیسک ٹاپ جس میں ٹریننگ کے لیے بہت سی RAM اور درجن بھر یو ایس بی ڈیوائسز ہیں اس میں 15 سیکنڈ لگ سکتے ہیں۔ اگر آپ کے فرم ویئر میں فاسٹ بوٹ آپشن ہے، تو یہ آپشن آپ کے منسلک کردہ ہارڈ ویئر کو نہ پہچاننے کی قیمت پر شمار کے مرحلے کو چھوڑنے کے مترادف ہے۔
لوڈر کا وقت زیادہ تر وقت ختم ہوتا ہے، لہذا یہ زیادہ تر آپ پر منحصر ہے۔ کرنل کا وقت اس بات پر منحصر ہوگا کہ آپ کے پاس کتنا ہارڈ ویئر ہے اور آپ کو پیک کھولنے اور بازیافت کرنے کے لیے کتنے initramfs کی ضرورت ہے۔ یہی وجہ ہے کہ ڈسٹری بیوشن-جنرک initramfs جیسے Ubuntu کی لاگت خاص طور پر سسٹم کے لیے بنائے گئے میزبان کے لیے مخصوص initramfs سے زیادہ ہے۔ اگر آپ کا روٹ فائل سسٹم انکرپٹڈ ہے، جو کرنل ٹائم لگتا ہے وہ دراصل آپ کا پاس فریز ٹائپ کر رہا ہے۔
یہ وہ جگہ ہے جہاں آپ کی مشین میری سے سب سے زیادہ مختلف ہے کیونکہ صارف کی جگہ کے اوقات اس بات کی عکاسی کرتے ہیں کہ آپ نے کیا انسٹال کیا ہے، نہ کہ آپ کی ملکیت۔ ڈوکر کی قیمت لگ بھگ 5 سیکنڈ ہے اور اگر آپ اسے نہیں چلاتے ہیں تو اس کی کوئی قیمت نہیں ہے۔
کسی نتیجے پر پہنچنے سے پہلے اسے چند بار چلائیں۔ بوٹ کا وقت ایک ہی سسٹم پر چلنے کے درمیان مختلف ہوتا ہے، اور ایک ہی پڑھنے سے آپ کو آپ کی خواہش سے کم معلومات مل سکتی ہیں۔
لاگ ان اسکرین اور آپ کو ڈیلیور کر دیا گیا۔
آخری مراحل یہ ہیں:
systemctl status display-manager --no-pager | head -1
loginctl show-session $(loginctl | awk 'NR==2{print $1}') -p Type -p Class
● lightdm.service - Light Display Manager
Type=x11
Class=user
اس کمپیوٹر پر ڈسپلے مینیجر LightDM ہے، جو اس کے حصے کے طور پر شروع کیا گیا ہے: graphical.target. ورچوئل ٹرمینل میں سیشن کھولیں، مبارکباد دیں اور انتظار کریں۔
اس کے بعد، systemd نے پہلے ہی لاگ ان ہونے والے شخص کے لیے سیٹ اور سیشن سلاٹ بنا دیا ہے۔ جب آپ اپنا پاس ورڈ درج کرتے ہیں، تو ڈسپلے مینیجر PAM کے ذریعے آپ کی تصدیق کرتا ہے، systemd ایک سیشن تفویض کرتا ہے، اور ڈیسک ٹاپ ماحول آپ کے صارف کے عمل کے طور پر شروع ہوتا ہے۔
کہ vt.handoff=7 یہ وہ جگہ ہے جہاں آپ کرنل کمانڈ لائن سے نتائج حاصل کرتے ہیں: اسکرین کو خالی کیے بغیر یا دوبارہ ڈرائنگ کیے بغیر ایک ورچوئل ٹرمینل کو گرافکس اسٹیک پر منتقل کرتا ہے۔ یہ ایک ہموار بوٹ اور چمکتے ہوئے بوٹ کے درمیان فرق ہے۔
اس مقام سے، دانا وہی کرتا ہے جو ہمیشہ کرتا ہے: سسٹم کالز کا جواب دیں۔ اگر آپ جاننا چاہتے ہیں کہ آگے کیا ہوتا ہے، میں نے ان حدود کے بارے میں تفصیل سے لکھا ہے۔
نتیجہ
اب آپ اندازہ لگانے کے بجائے نمبروں کا استعمال کرتے ہوئے قدم بہ قدم اپنے بوٹ کو بیان کر سکتے ہیں۔ اس لیپ ٹاپ پر، 29.6 سیکنڈز کو فرم ویئر میں تقریباً 6 سیکنڈز میں تقسیم کیا گیا ہے، جس پر آپ کا کوئی کنٹرول نہیں ہے، بوٹ لوڈر میں 8.5 سیکنڈ، جو ایک الٹی گنتی ہے جسے آپ زیادہ تر ڈیلیٹ کر سکتے ہیں، 3 سیکنڈز کرنل میں، اور 12 سیکنڈ یوزر اسپیس میں، جس پر نیٹ ورک پر انتظار کرنے والی دو سروسز کا غلبہ ہے۔
زیادہ مفید طور پر، حقیقی اور قابل فہم پیمائش کے درمیان فرق کرنے کا ایک طریقہ موجود ہے۔ systemd-analyze blame مستند دیکھیں اور سوالات کے جوابات دیں جو کوئی نہیں پوچھ رہا ہے۔ تنقیدی زنجیریں صحیح سوالوں کا جواب دیتی ہیں، لیکن پھر بھی انہیں احتیاط کی ضرورت ہوتی ہے کیونکہ درخت تاریخ کی ترتیب کے بجائے انحصار کا نقشہ بناتے ہیں۔
یہاں کچھ ہدایات ہیں: سیٹ GRUB_TIMEOUT=1 اس کا استعمال کرتے ہوئے ترتیب کو دوبارہ بنائیں: sudo update-grub Debian اور Ubuntu پر یا sudo grub2-mkconfig -o /boot/grub2/grub.cfg فیڈورا میں، ریبوٹ کریں اور 5 سیکنڈ غائب ہوتے دیکھیں۔ چلائیں systemd-analyze plot > boot.svg ٹیکسٹ آؤٹ پٹ ضم ہونے کے ساتھ ساتھ ساتھ دیکھنے کے لیے اپنے براؤزر میں کھولیں۔ یا دیکھیں کہ ایسا نہیں ہے۔ NetworkManager-wait-online.service آپ اپنے کمپیوٹر پر 4 سیکنڈ کا وقت خرید رہے ہیں، جو زیادہ تر ڈیسک ٹاپس نہیں کرتے ہیں۔
ایپیلاگ
میں نے ان میں سے ایک کو دیکھنے کی وجہ یہ ہے کہ میں اینڈرائیڈ طرز کے اجازت نامے کا استعمال کرتے ہوئے ایک لینکس ڈسٹری بیوشن بنا رہا ہوں، جہاں پروگراموں کو صرف وہی اجازت ملتی ہے جو وہ اپنے مینی فیسٹ میں مانگتے ہیں، بجائے اس کے کہ صارف کے ساتھ ہونے والی ہر چیز کے۔ یہ بوٹ آرڈر کو سیکیورٹی سوال سے بدل دیتا ہے۔ آپ کے لاگ ان ہونے سے پہلے شروع ہونے والا کوئی بھی عمل بعد میں شروع ہونے والے کسی بھی عمل سے زیادہ مراعات کے ساتھ چلے گا، اور جب تک آپ ہر عمل کو نام نہیں دے سکتے اور یہ نہیں کہہ سکتے کہ یہ کیوں موجود ہے، اس پر بحث کرنے کا کوئی حقیقی طریقہ نہیں تھا کہ کون سا عمل اس کا مستحق ہے۔
آپ میری مزید تحریریں thechris.in پر دیکھ سکتے ہیں۔