umount: อุปกรณ์ไม่ว่าง ทำไม?


171

เมื่อทำงานumount /pathฉันจะได้รับ:

umount: /path: device is busy.

ระบบไฟล์มีขนาดใหญ่มากดังนั้นจึงlsof +D /pathไม่ใช่ตัวเลือกที่เหมือนจริง

lsof /path, lsof +f -- /pathและfuser /pathทั้งหมดกลับไม่มีอะไร fuser -v /pathให้:

                  USER        PID ACCESS COMMAND
/path:            root     kernel mount /path

ซึ่งเป็นเรื่องปกติสำหรับระบบไฟล์ที่เมาท์ที่ไม่ได้ใช้ทั้งหมด

umount -lและumount -fไม่ดีพอสำหรับสถานการณ์ของฉัน

ฉันจะทราบได้อย่างไรว่าเคอร์เนลคิดว่าระบบไฟล์นี้ไม่ว่าง


11
ไดเร็กทอรีปัจจุบันของเชลล์ของคุณอยู่บนเส้นทางเมานต์หรือไม่?
LawrenceC

ไม่ฟิวเซอร์จะบอกเช่นนั้น
Ole Tange

12
คุณต้องการจริงๆfuser -vm /path...
Derobert

5
สำหรับ umount --forceจะพยายามให้ถอนการเชื่อมต่อยากขึ้นและ-vหรือ-vvvแม้แต่จะเพิ่มมากขึ้นว่าปัญหาของการเมานท์คืออะไร ดังนั้นลอง:umount -vvv --force /babdmount
gaoithe

คำตอบ:


139

ดูเหมือนว่าสาเหตุของปัญหาของฉันคือการnfs-kernel-serverส่งออกไดเรกทอรี nfs-kernel-serverอาจจะไปอยู่เบื้องหลังการเปิดไฟล์ปกติจึงไม่อยู่ในรายการโดยและlsoffuser

เมื่อฉันหยุดnfs-kernel-serverฉันสามารถumountไดเรกทอรี

ฉันได้สร้างหน้าพร้อมตัวอย่างของโซลูชั่นทั้งหมดที่นี่: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html


54
ขอบคุณที่ตอบคำถามของคุณเองแทนที่จะทิ้งไว้เมื่อใช้วิธีแก้ไขปัญหาของคุณ คำตอบของคุณช่วยฉันจัดเรียงการแชร์ NFS ที่ส่งออกในทำนองเดียวกัน
Jeff Welling

7
ปัญหาเดียวกันนี้อาจเกิดขึ้นได้หากคุณตั้งค่าอุปกรณ์ลูปแบ็คในระบบไฟล์ - ตัวอย่างเช่นหาก / dev / loop0 ได้รับการสนับสนุนโดยไฟล์ใน / พา ธ
BCran

1
ผมต้องsudo service samba stopแรกคำตอบของคุณจริงๆช่วยออก!
malat

1
โพสต์นี้ทำให้ฉันนึกว่าฉันมีบริการ nfs ที่ทำงานหลังจากหลายชั่วโมงของการพยายามคิด ใน RHEL6 / CentOS6 ให้ใช้sudo service nfs stopและคุณอาจ (ไม่) ต้องทำเช่นนั้นsudo exportfs -uเพื่อยกเลิกการส่งออก อย่าลืมแล้วsudo exportfs -rและsudo service nfs startอีกครั้งการส่งออกและเริ่มบริการ
code_dredd

1
ในกรณีของฉันไม่จำเป็นต้องหยุดเซิร์ฟเวอร์ nfs เพียงexportfs -uไดเรกทอรีที่สงสัย
Law29

42

เพื่อเพิ่มความคิดเห็นของBruceCranข้างต้นสาเหตุของการสำแดงของปัญหานี้ตอนนี้ก็คือการติดลูปแบ็คเก่า ฉันได้ตรวจสอบผลลัพธ์ของ/ , และ, ตรวจสอบว่า nfs-kernel-server เก่าบางอันทำงานอยู่, ปิดโควต้า, พยายาม (แต่ล้มเหลว) a และทั้งหมด แต่ลาออกจากตัวเองเพื่อละทิ้งสถานะการออนไลน์ 924 วันก่อนตรวจสอบผลลัพธ์สุดท้าย ของและค้นหาลูปวนวนที่กำหนดค่า แต่ไม่ได้ถูกเมานต์สองตัว:fuser -vm <mountpoint>lsof +D <mountpoint>mountcat /proc/mountsumount -f <mountpoint>losetup

parsley:/mnt# cat /proc/mounts 
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0

แล้วก็

parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy

parsley:/mnt# losetup -a    
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)

parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#

ฟอรั่มโพสต์ Gentooยังแสดง swapfiles เป็นผู้กระทำผิดที่อาจเกิดขึ้น แม้ว่าการแลกเปลี่ยนไฟล์เป็นไปได้ยากในช่วงนี้ แต่ก็ไม่สามารถตรวจสอบผลลัพธ์cat /proc/swapsได้ ฉันไม่แน่ใจว่าโควต้าสามารถป้องกันการยกเลิกการต่อเชื่อมได้หรือไม่ - ฉันกำลังจับฟาง


12
เวลาในการทำงาน 924 วันหมายความว่าคุณต้องอัปเดตเคอร์เนลแพตช์ของคุณ :-)
w00t

+1 สำหรับการพูดถึงไฟล์สวอปจะบล็อกการเลิกเมานท์และค่อนข้างจะตรวจจับไม่ได้หากคุณไม่ได้ตรวจสอบโดยตรง
P.Péter

22

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

lsof | grep '/path'

1
lsof / path มองผ่านเส้นทางเท่านั้น
Ole Tange

7
ผมไม่ได้พูดผมพูดlsof /path lsof | grep '/path'ข้อแตกต่างคือ lsof ที่ไม่มีอาร์กิวเมนต์จะแสดงไฟล์ที่เปิดอยู่ทั้งหมดโดยใช้ตารางแคชบางประเภทและ grep สามารถค้นหาได้อย่างรวดเร็ว สิ่งที่คุณลองด้วย lsof ทำให้สามารถสแกนผ่านระบบไฟล์ซึ่งใช้เวลานาน
Caleb

1
อย่างที่ฉันพูด: lsof /pathดูเส้นทางเท่านั้น มันไม่ได้ดูไฟล์ทุกไฟล์ มันมักจะเร็วกว่าlsof | grep /path(ในการทดสอบตามหลักวิทยาศาสตร์ของฉันมันเร็วกว่า YMMV 20 เท่า) เนื่องจากมันไม่ได้ดูไฟล์ที่เปิดอยู่ทั้งหมด แต่มีเพียงไฟล์สำหรับเส้นทางนั้น
Ole Tange

ฉันไม่แน่ใจว่าความแตกต่างทางเทคนิคคืออะไร แต่ในขณะที่ตรวจสอบการเมานต์ NFS ค้างlsof /pathให้ทำอะไรเลยในขณะที่lsof | grep /pathแสดงให้ฉันเห็นกระบวนการที่กำลังถือไฟล์เปิดอยู่
dpw

20

สำหรับฉันกระบวนการที่กระทำผิดนั้นเป็น daemon ที่ทำงานใน chroot เพราะมันอยู่ใน chroot lsofและfuserจะไม่พบมัน

หากคุณสงสัยว่าคุณมีบางอย่างเหลืออยู่ใน chroot คุณsudo ls -l /proc/*/root | grep chrootจะพบผู้ร้าย (แทนที่ "chroot" ด้วยเส้นทางไปยัง chroot)


1
ดีและใน FreeBSD ฉันทำสิ่งนี้: sudo ls -l /proc/*/status | grep HOSTที่ HOST เป็นชื่อโฮสต์ของคุก
JGurtz

1
ในระบบของฉัน (Mint Qiana) lsof /mountpointและfuser /mountpointทั้งสองพบกระบวนการแม้ว่า chrooted
Ole Tange

9

เปิดไฟล์

กระบวนการที่เปิดไฟล์เป็นตัวการผิดปกติ แสดงพวกเขา:

lsof +f -- <mountpoint or device>

มีข้อได้เปรียบในการใช้ /dev/<device>มากกว่า/mountpoint: จุดเมานท์จะหายไปหลังจากumount -lหรืออาจซ่อนโดยการเมาท์แบบซ้อนทับ

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

รายการไฟล์บน<mountpoint>(ดูข้อแม้ด้านบน):

fuser -vmM <mountpoint>

ฆ่าเฉพาะกระบวนการที่เปิดไฟล์เพื่อการเขียนเท่านั้น:

fuser -vmMkiw <mountpoint>

หลังจากติดตั้งใหม่แบบอ่านอย่างเดียว ( mount -o remount,ro <mountpoint>) แล้วจะปลอดภัย (r) เพื่อฆ่ากระบวนการที่เหลือทั้งหมด:

fuser -vmMk <mountpoint>

mountpoints

ผู้ร้ายสามารถเป็นเคอร์เนลได้ ระบบไฟล์อื่นที่เมาท์บนระบบไฟล์ที่คุณพยายามumountจะทำให้เกิดความเศร้าโศก ตรวจสอบกับ:

mount | grep <mountpoint>/

สำหรับการเมานต์ย้อนกลับตรวจสอบผลลัพธ์ของ:

losetup -la

inodes นิรนาม (Linux)

inodes นิรนามสามารถสร้างได้โดย:

  • ไฟล์ชั่วคราว ( openพร้อมO_TMPFILE)
  • inotifyนาฬิกา
  • [eventfd]
  • [eventpoll]
  • [timerfd]

เหล่านี้เป็นชนิดที่เข้าใจยากที่สุดของโปเกมอนและปรากฏในlsof's TYPEคอลัมน์เป็นa_inode(ซึ่งไม่มีเอกสารใน lsofหน้าคน )

พวกเขาจะไม่ปรากฏในlsof +f -- /dev/<device>ดังนั้นคุณจะต้อง:

lsof | grep a_inode

สำหรับกระบวนการฆ่าที่มีinode ที่ไม่ระบุชื่อดู: แสดงรายการ inotify watches (ชื่อพา ธ , PID) ในปัจจุบัน


5

เพื่อให้ฟิวเซอร์รายงานเกี่ยวกับ PIDs ที่เมานต์เปิดค้างไว้คุณต้องใช้ -m

fuser -m /path

2
จริง แต่ไม่เกี่ยวข้อง: lsof /pathให้รายการเดียวกันของ PIDs fuser -m /pathเป็น
Gilles

fuser -M /pathจะตรวจสอบว่า/pathเมานต์หรือไม่
user3804598

5

เรามีระบบกรรมสิทธิ์ที่ระบบไฟล์รูทเป็นแบบอ่านอย่างเดียว บางครั้งเมื่อต้องคัดลอกไฟล์จะมีการอ่านซ้ำเขียน:

mount -oremount,rw /

จากนั้นจึงติดตั้งใหม่

mount -oremount,ro /

อย่างไรก็ตามในครั้งนี้mountให้mount: / is busyข้อผิดพลาด มันเกิดจากกระบวนการที่ถือ descriptor เปิดให้กับไฟล์ที่ถูกแทนที่ด้วยคำสั่งบางอย่างซึ่งถูกดำเนินการเมื่อระบบไฟล์อ่าน - เขียน บรรทัดสำคัญจากlsof -- /เอาต์พุตเกิดขึ้นเป็น (มีการเปลี่ยนแปลงชื่อ):

replicate  1719 admin DEL REG 8,5  204394 /opt/gns/lib/replicate/modules/md_es.so

สังเกตเห็นDELในการส่งออก เพียงแค่เริ่มกระบวนการที่ค้างไว้บนไฟล์ที่ถูกลบเพื่อแก้ไขปัญหา


3
ดังนั้นสรุปคือกระบวนการที่มีการเปิดไฟล์ที่ถูกลบ อินพุตที่ดี
Ole Tange

4

lsofและfuserไม่ได้ให้อะไรฉันเลย

หลังจากกระบวนการเปลี่ยนชื่อไดเรกทอรีที่เป็นไปได้ทั้งหมดเป็น. old และรีบูตระบบทุกครั้งหลังจากที่ฉันทำการเปลี่ยนแปลงฉันพบไดเรกทอรีหนึ่งโดยเฉพาะ (เกี่ยวข้องกับ postfix) ที่รับผิดชอบ

มันกลับกลายเป็นว่าฉันได้ทำครั้งเดียว symlink จาก/var/spool/postfixไป/disk2/pers/mail/postfix/varspoolเพื่อลดดิสก์เขียนบนระบบแฟ้มรากใน sdcard-based (Sheeva ปลั๊ก)

ด้วย symlink นี้แม้หลังจากการหยุดpostfixและdovecotการบริการ (ทั้งps auxรวมทั้งnetstat -tuanpไม่ได้แสดงอะไรที่เกี่ยวข้อง) unmount /disk2/persฉันไม่สามารถที่จะ

เมื่อฉันลบ symlink และอัปเดตpostfixและกำหนดค่าdovecotไฟล์ให้ชี้ไปที่ dirs ใหม่บน/disk2/pers/ฉันสามารถหยุดบริการและunmountไดเรกทอรีได้สำเร็จ

ครั้งต่อไปฉันจะดูผลลัพธ์ของ:

ls -lR /var | grep ^l | grep disk2

คำสั่งด้านบนจะแสดงรายการลิงก์สัญลักษณ์ทั้งหมดซ้ำในแผนผังไดเรกทอรี (ที่นี่เริ่มต้นที่/var) และกรองชื่อเหล่านั้นที่ชี้ไปยังจุดต่อเป้าหมายเฉพาะ (ที่นี่ disk2)


3

ฉันมีปัญหานี้และปรากฎว่ามีเซสชันหน้าจอที่ใช้งานอยู่ในพื้นหลังที่ฉันไม่ทราบ ฉันเชื่อมต่อกับเซสชั่นหน้าจอที่ใช้งานอื่น ๆ และเปลือกของมันไม่ได้นั่งอยู่ในไดเรกทอรีที่ติดตั้งอยู่ การฆ่าเซสชันการเชลล์อื่นเหล่านั้นแก้ไขปัญหาให้ฉัน

แค่คิดว่าฉันจะแบ่งปันความละเอียดของฉัน


1

วันนี้ปัญหาเป็นซ็อกเก็ตเปิด (เฉพาะtmux):

mount /mnt/disk
export TMPDIR=/mnt/disk
tmux
<<detatch>>
umount /mnt/disk
umount: /mnt/disk: device is busy.
lsof | grep /mnt/disk
tmux      20885             root    6u     unix 0xffff880022346300        0t0    3215201 /mnt/disk/tmux-0/default

1

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


1

นี่เป็นวิธีแก้ปัญหามากกว่าคำตอบ แต่ฉันโพสต์ไว้ในกรณีที่อาจช่วยใครซักคน

ในกรณีของฉันฉันกำลังพยายามแก้ไข LVM เนื่องจากฉันต้องการทำให้พาร์ติชัน / var ใหญ่ขึ้นดังนั้นฉันจึงจำเป็นต้องเพิ่มจำนวนพาร์ติชัน ฉันลองทุกความเห็นและตอบในโพสต์นี้ (ขอบคุณทุกคนและโดยเฉพาะอย่างยิ่ง @ ole-tange สำหรับการรวบรวมพวกเขา) และยังคงได้รับข้อผิดพลาด "อุปกรณ์ไม่ว่าง"

ฉันพยายามฆ่ากระบวนการส่วนใหญ่ตามลำดับที่ระบุใน runlevel 0 ด้วยเช่นกันในกรณีที่ใบสั่งนั้นเกี่ยวข้องในกรณีของฉัน แต่นั่นก็ไม่ได้ช่วยอะไรเช่นกัน ดังนั้นสิ่งที่ฉันทำคือการสร้าง runlevel แบบกำหนดเอง (รวมเอา chkconfig ไปยังคำสั่ง chkconfig --level ใหม่) ซึ่งจะคล้ายกับ 1 (โหมดผู้ใช้คนเดียว) แต่มีความสามารถเครือข่าย (กับ ssh network และ xinet)

ขณะที่ฉันใช้ redhat, runlevel 4 ถูกทำเครื่องหมายว่า "ไม่ได้ใช้ / ผู้ใช้กำหนด" ดังนั้นฉันจึงใช้อันนั้นและเรียกใช้ init 4 ในกรณีของฉันสิ่งนี้ก็โอเคเพราะฉันต้องการรีบูตเซิร์ฟเวอร์ในกรณีใด ๆ แต่อาจเป็นกรณีนั้น ของใครก็ตามที่ปรับแต่งดิสก์

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.