รีบูตเครื่อง Mac ด้วยแอปพลิเคชันที่ตรึงไว้

ฉันเพิ่งรู้ว่าฉันไม่รู้วิธีที่ OS X จัดการแอปพลิเคชัน

วันนี้ Google Chrome แข็งบน OS X Yosemite 10.10.2 หลังจากมันแข็งตัวฉันก็เลิกใช้โดยใช้ "ออกจากกองทัพ" ฉันยังส่งรายงานไปยัง Apple

Dock ยังคงแสดงว่าทำงานอยู่ แต่การคลิกที่ "ออกจากกองทัพ" ไม่มีผลกระทบใด ๆ ฉันรีสตาร์ททั้ง Finder และ Dock แต่ Chrome ยังคงแสดงว่า 'กำลังทำงาน' อย่างไรก็ตามไม่มีการแจ้งเตือนฉันเกี่ยวกับ 'Chrome' ที่แสดงอยู่ในการตรวจสอบกิจกรรมหรือในps auxเทอร์มินัล

ดังนั้นฉันตัดสินใจรีสตาร์ทเครื่องของฉันและมันน่าอาย: ป้อนคำอธิบายรูปภาพที่นี่

ดังนั้นฉันจึงรีบูตเพราะ Chrome ไม่ตอบสนอง แต่เครื่องของฉันปฏิเสธที่จะรีบูตเพราะฉันต้องออกจาก Google Chrome ก่อนซึ่งไม่ใช่กระบวนการที่กำลังทำงานอยู่ โชคดีที่ Apple ยังไม่ได้ถอดปุ่มเปิดปิดจากแล็ปท็อป

สิ่งนี้จะเกิดขึ้นเมื่อใด ไฟล์ "ล็อค" ใดที่ฉันจำเป็นต้องลบเพื่อแจ้งให้ OS X ทราบว่าแอปพลิเคชัน 'ที่กำลังทำงาน' ไม่ได้ทำงานจริง

PS นี่ไม่ใช่พฤติกรรมที่เหมือนกับ MS Windows 95 ใช่หรือไม่ น่าเสียดาย ...

macos google-chrome

— อันโตนิโอเซสโต
แหล่งที่มา

ในสถานการณ์นี้อีกวิธีหนึ่งในการบังคับให้ออกจาก Chrome (และกระบวนการแท็บที่เกี่ยวข้อง) คือการเปิด Terminal.app และเรียกใช้คำสั่งต่อไปนี้: killall 'Google Chrome'(ระวังจำเป็นต้องใช้เครื่องหมายคำพูดเดี่ยวเหล่านั้น) สิ่งนี้จะฆ่ากระบวนการเป้าหมายด้วยสัญญาณ TERM ไม่ว่าจะใช้งานได้เมื่อ "Force Quit" ล้มเหลวฉันไม่แน่ใจทั้งหมด (แต่killall ควรใช้งานได้ตลอด)

— Todd Ditchendorf

ขอบคุณ. แต่ข้อมูลนั้นอยู่ที่ไหนในระบบปฏิบัติการ ฉันหมายถึง: ไม่มีกระบวนการใน "ps aux" มีบางสิ่งเชื่อมต่อกับ Chrome อย่างชัดเจน คำถามของฉันไม่เพียงเกี่ยวกับวิธีการกู้คืนในสถานการณ์เหล่านั้น: ฉันอยากจะเข้าใจว่าระบบปฏิบัติการจัดการแอปที่เปิดตัวและฆ่าอย่างไร

— Antonio Sesto

นี่อาจเป็นสถานการณ์ที่รุนแรง ฉันเดาว่าการฆ่า ("Force Quit") Google Chrome ไม่ได้ฆ่ากระบวนการ "Google Chrome Helper" ทั้งหมดบางทีปัญหาเดิมคือหนึ่งในนั้นเป็นคนทำธุรกิจและถูกแยกตัวออกจากกระบวนการ GC หลัก หากเป็นจริงการแก้ปัญหาอาจเป็นได้ด้วยตนเองบังคับให้ออกจากกระบวนการ "ผู้ช่วย Google Chrome" ทั้งหมดที่เหลืออยู่

— DavAlPi

ใช่ แต่คุณจะฆ่าพวกเขาได้อย่างไรหากไม่มีการอ้างอิงถึง Google Chrome หรือกระบวนการผู้ช่วยจะถูกส่งคืนโดยpsหรือการตรวจสอบกิจกรรม เมื่อพิจารณาว่าระบบไฟล์ของ Apple แย่แค่ไหนคุณไม่คิดว่ามันจะเกี่ยวข้องกับไฟล์ที่ค้างอยู่ที่ไหนสักแห่ง?

— Antonio Sesto

ในโอกาสที่หายากมากสิ่งนี้เกิดขึ้นกับฉันในอดีตฉันเริ่มเล่นซอกับdtraceสคริปต์เพื่อรู้ว่าเกิดอะไรขึ้น opensnoopหนึ่งพร้อมที่จะใช้สคริปต์

ดังนั้นในครั้งต่อไปที่คุณพบปัญหานี้ให้ลองแก้ไขดังนี้:

$ sudo opensnoop -ve

หรือ จำกัด ผลลัพธ์ที่คุณคาดหวัง:

$ sudo opensnoop -ve | grep -i chrome

กระบวนการสั้นอาจจะไม่แสดงในของคุณออกเพื่อให้ตัวเลือกอื่นให้เราขอบเขตฟังก์ชั่นการติดตามกรอบที่สามารถใช้ได้ps dtraceส่วนใหญ่แล้วเวอร์ชั่น OSX ของคุณจะมีจุดเข้าใช้งานที่เรียบง่ายที่กำหนดไว้สำหรับเลเยอร์ VFS (เรียกว่า dump_vfs.d):

#!/usr/sbin/dtrace -s

#pragma D option quiet
#pragma D option switchrate=10hz

dtrace:::BEGIN {
    printf("%-12s %6s %6s %-12.12s %-12s %s\n", "TIME(ms)", "UID",
        "PID", "PROCESS", "CALL", "DIR/FILE");
}

fbt::VNOP_CREATE:entry,
fbt::VNOP_REMOVE:entry {
    this->path = ((struct vnode *)arg0)->v_name;
    this->name = ((struct componentname *)arg2)->cn_nameptr;
    printf("%-12d %6d %6d %-12.12s %-12s %s/%s\n",
        timestamp / 1000000, uid, pid, execname, probefunc,
        this->path != NULL ? stringof(this->path) : "<null>",
        stringof(this->name));
}

การเรียกมันคล้ายกับข้างบน:

$ sudo dtrace -s dump_vfs.d

สามารถใช้fs_usageคำสั่งปิดการทำงานที่มีฟังก์ชั่นได้โดยเฉพาะอย่างยิ่งหากคุณสงสัยว่ากระบวนการดังกล่าวแขวนอยู่ในลูปเหตุการณ์แม้ว่าจะยังเข้าถึงเลเยอร์ fs โดยใช้การเรียกระบบ

นี่อาจเป็นเรื่องที่เกินความเป็นจริงเพราะตัวเลือกที่ใช้งานได้จริงส่วนใหญ่น่าจะกดปุ่มเปิดปิด เนื่องจากคุณกล่าวว่าคุณส่งรายงานไปยัง Apple คุณอาจต้องการตรวจสอบอีกครั้งภายใต้ตำแหน่งที่ตั้งต่อไปนี้:

~/Library/Logs/DiagnosticReports/
/Library/Logs/DiagnosticReports/

สิ่งนี้จะให้คำแนะนำเพิ่มเติมแก่คุณว่าทำไมแอปพลิเคชันดังกล่าวจึงขัดข้องในลักษณะดังกล่าว

อยากรู้อยากเห็นของคุณเกี่ยวกับการจัดการสถานการณ์เช่นระบบปฏิบัติการที่มีความสามารถอาจจะดับบางส่วนจากการมองเข้าไปในแหล่ง XNU bsd/kern/kern_shutdown.cเคอร์เนลที่ เมื่อถึงจุดหนึ่งกระบวนการปิดระบบที่เริ่มต้นผ่าน Finder จะหมดเวลาซึ่งจะบันทึกความพยายามของ SIGTERM ที่ล้มเหลว (คัดลอกมาจากสำเนาภายในรุ่น 2782.1.97 ของแหล่งเคอร์เนลดาร์วิน):

    [...]
    for (p = allproc.lh_first; p; p = p->p_list.le_next) {
        if (p->p_shutdownstate == 1) {
            printf("%s[%d]: didn't act on SIGTERM\n", p->p_comm, p->p_pid);
            sd_log(ctx, "%s[%d]: didn't act on SIGTERM\n", p->p_comm, p->p_pid);
        }
    }
    [...]

สิ่งนี้บ่งชี้ว่าConsoleแอปพลิเคชันอาจแสดงรายการบันทึกที่เกี่ยวข้องให้คุณ เคอร์เนลจะเข้าสู่ช่วงรอ 100 ถึง 200 วินาทีทั้งนี้ขึ้นอยู่กับสถานการณ์ล็อกสดที่อาจเกิดขึ้นเกี่ยวกับไฟล์ที่อยู่ในพาร์ติชันที่เมาท์เครือข่ายซึ่งเพิ่งสูญเสียสัญญาณเลเยอร์ 1

ในฐานะที่เป็น sidenote: ฉันมีความสุขน้อยมากกับ Chrome ใน MBP ของฉันเพราะฉันเชื่อว่าการอัปเดตล่าสุดของไดรเวอร์หลัก nvidia ภายในOSX >= 10.9พร้อมกับฟังก์ชั่นการจัดการพลังงานที่สูงขึ้นและตอนนี้ appnap รวมกับความก้าวหน้าล่าสุดในการจัดการปลั๊กอิน เบราว์เซอร์กล่าวว่าก่อให้เกิดความเสียหายซ้ำ ๆ ยิ่งไปกว่านั้น Chrome ในปี 2014 สำหรับฉันนั้นเป็นเบราว์เซอร์ที่แรงที่สุดในโลก

อาจมีสถานการณ์อีกครึ่งโหลว่าทำไมคุณถึงได้รับการต้อนรับด้วย GUI ข้อเสนอแนะที่ไม่มีการกระตุ้น ไม่มีสิ่งใดมาแม้แต่ระยะไกลใกล้กับปัญหาที่คุณเรียกสั้น ๆ โดยการพูดถึง Win95 :)

เพิ่งกดปุ่มเพาเวอร์แล้ว!

— Moreaki
แหล่งที่มา