ตกลงฉันมีข้อสรุปที่คล้ายกันกับดาร์เรนแม้ว่ากลไกการทำโปรไฟล์ที่แตกต่างกันเล็กน้อย (การล็อกอินช้า NB ยังสามารถเกิดขึ้นได้ในโยเซมิตี)
นี่คือวิธีที่จะบอกสิ่งที่ทำงานจริงเมื่อคุณเริ่มหน้าต่างเข้าสู่ระบบใหม่โดยใช้คำสั่ง profiler ตัวอย่าง OS X
ค้นหาคำสั่งที่ลงชื่อเข้าใช้แบบปกติเรียกใช้งาน
$ ps -ef | grep login
คุณจะเห็นสิ่งที่ชอบ login -pfl username /bin/bash -c exec -la bash /bin/bash
สร้างชื่อไฟล์สคริปต์profile_login.sh
ด้วยเนื้อหาต่อไปนี้โดยการเพิ่ม
-c ""
ที่ส่วนท้ายของคำสั่งที่ค้นพบเพื่อขอให้ทุบตีกลับมาทันทีด้วยเนื้อหาเช่นนี้:
login -pfl username /bin/bash -c exec -la bash /bin/bash -c "" &
sudo sample $! -mayDie # sample the above command
ทำให้ปฏิบัติการได้
$ chmod u+x profile_login.sh
และเรียกใช้โดยใช้ sudo ( sample
คำสั่งต้องการมัน)
$ sudo ./profile_login.sh
ตกลงเพื่อไปข้างหน้าและเรียกใช้ เช่นโดยการรันpurge
คำสั่งก่อน ในกล่องของฉันฉันได้กราฟผลลัพธ์ขนาดใหญ่ มองหา "สาขาที่มีหมายเลขมากที่สุด" (โดยทั่วไปอยู่ด้านบน) ฉันเห็นผู้กระทำผิดที่ใหญ่ที่สุดสองคนดังต่อไปนี้:
หนึ่งจากสิ่งที่เรียกว่าpam_start
ซึ่งดูเหมือนจะเปิดภาพ PAM auth lib
+ ! 1068 pam_start (in libpam.2.dylib) + 132 [0x7fff97295ab0]
+ ! : 1066 openpam_dynamic (in libpam.2.dylib) + 120 [0x7fff97293d14]
+ ! : | + ! 1042 coresymbolication_load_image(CSCppDyldSharedMemoryPage*, ImageLoader const*, unsigned long long) (in dyld) + 143 [0x7fff66725411]
+ ! : | + ! : 1042 mach_msg_trap (in dyld) + 10 [0x7fff6674a472]
และบางครั้งก็มีผู้กระทำความผิดอีกคนตามมา getlastlogxbyname
+ ! 583 getlastlogxbyname (in libsystem_c.dylib) + 212 [0x7fff92b3ef7a]
+ ! : 566 asl_file_open_read (in libsystem_asl.dylib) + 143 [0x7fff8c27030d]
+ ! : | 566 __open_nocancel (in libsystem_kernel.dylib) + 10 [0x7fff97b39012] + ! : | 566 __open_nocancel (in libsystem_kernel.dylib) + 10 [0x7fff97b39012]
โดยพื้นฐานแล้วมีผู้กระทำผิดสองคน หนึ่งคือpam
(ระบบการรับรองความถูกต้องบางประเภท) และอีกสิ่งหนึ่งคือasl
"ตรวจสอบการเข้าสู่ระบบล่าสุดของคุณ" เห็นได้ชัดว่าเพียงแค่การลบ/private/var/log/asl/*.asl
ไฟล์ของคุณไม่เพียงพอ การโหลดแพมนั้นมีราคาแพงกว่าในเครื่องของฉันมากกว่า [SSD] อย่าลังเลที่จะเรียกใช้สคริปต์ข้างต้นและดูว่าระบบของคุณเหมือนกันหรือไม่ น่าสนใจซอร์สโค้ดสำหรับการเรียกเมธอดเหล่านี้ดูเหมือนจะพร้อมใช้งานออนไลน์เช่นopenpam_dynamic
ถ้าฉันทำตามคำตอบของ Darren และแทนที่ "shells open with" ไปเป็นอย่างอื่นที่ไม่ใช่ / bin / bash ฉันจะเห็นบรรทัดต่อไปนี้ที่ใช้เพื่อเริ่มแท็บ terminal ใหม่:
$ ps -ef | grep login
... login -pfql packrd /bin/bash -c exec -la bash /usr/bin/bash
ดังนั้นหากตอนนี้ฉันใช้sample
เคล็ดลับเดียวกันกับคำสั่งเข้าสู่ระบบใหม่
login -pfql username /bin/bash -c exec -la bash /usr/bin/bash -c "" &
sudo sample $! -mayDie
กองซ้อนขนาดเล็กกว่าถูกสร้างขึ้นผู้กระทำผิดที่ใหญ่ที่สุดคือ:
+ 8 pam_end (in libpam.2.dylib) + 190 [0x7fff97294ebb]
+ ! 6 coresymbolication_unload_image(CSCppDyldSharedMemoryPage*, ImageLoader const*) (in dyld) + 143 [0x7fff6e0f634f]
ฉันคิดว่าเป็นเพราะพารามิเตอร์การเข้าสู่ระบบ "-q" กำลังถูกใช้งาน เห็นได้ชัดว่าพารามิเตอร์นี้ข้ามทั้งการโหลดโมดูล pam และค้นหาเวลาเข้าสู่ระบบล่าสุด (ผู้กระทำผิดทั้งสอง) ตามเอกสารของlogin
คำสั่งการสัมผัส~/.hushlogin
ไฟล์ควรทำสิ่งเดียวกัน แต่ดูเหมือนจะไม่ทำงานอีกต่อไป (อย่างน้อยสำหรับฉันที่ใช้ 10.10]
ดังนั้นโดยสรุปการลบ /private/var/log/asl/*.asl นั้นไม่เพียงพอ (ในการทดลองของฉันมันมีสัดส่วนเพียง 1/3 ของการชะลอตัวจริงที่สุดแม้ว่าคุณจะมีไฟล์จำนวนมาก สำหรับเปอร์เซ็นต์ที่มากขึ้นฉันแน่ใจ)
อย่างไรก็ตามหากใช้สคริปต์ที่คล้ายกันคุณควรจะสามารถบอกได้ว่าอะไรเป็นสาเหตุที่ทำให้เครื่องคอมพิวเตอร์ของคุณต้องชะงักและดูว่าการแก้ไขด้านบนมีผลกับคุณหรือไม่ รู้สึกอิสระที่จะแสดงความคิดเห็นที่นี่
UPDATE: ดูเหมือนว่าcoresymbolication_load_image
ยังคงสามารถใช้เวลาเป็นจำนวนมากแม้login -pfql
จะมีการเรียกใช้ (สันนิษฐานว่าโมดูลการตรวจสอบ pam บางส่วนหรืออื่น ๆ จะต้อง "โทรออก" ไปยังเซิร์ฟเวอร์เข้าสู่ระบบกลางหรือบางคี่จึงต้องรอการตอบสนองจากบุคคลที่สาม ) ดังนั้นวิธีแก้ปัญหาจริงเท่านั้นที่ฉันพบคือใช้ iTerm2 และเปลี่ยนการตั้งค่า -> โปรไฟล์ -> ทั่วไป -> คำสั่ง/bin/bash
แทน
.bash_profile
(ตรวจสอบ~/.profile
โดยวิธี) นอกจากนี้: โปรดทราบว่าคุณสามารถเริ่มพิมพ์ในขณะที่ bash กำลังโหลดและโดยปกติสิ่งที่คุณพิมพ์จะถูกคัดลอกไปยังพรอมต์คำสั่งเมื่อพร้อม