Node.js: ข้อผิดพลาด ENOSPC คืออะไรและจะแก้ไขได้อย่างไร

349

ฉันมีปัญหากับ Node.js และการอัปโหลดไฟล์ไปยังเซิร์ฟเวอร์ สำหรับการอัปโหลดไฟล์ไปยังเซิร์ฟเวอร์ฉันใช้ปลั๊กอินนี้ เมื่อเริ่มอัพโหลดไฟล์ไปยังเซิร์ฟเวอร์กระบวนการ Node.js ขัดข้องและแสดงข้อผิดพลาด:

ข้อผิดพลาด: ENOSPC

รหัสเซิร์ฟเวอร์ไม่ทำงาน

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.9G  4.1G  3.5G  55% /
udev            288M  8.0K  288M   1% /dev
tmpfs           119M  168K  118M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            296M     0  296M   0% /run/shm
/dev/xvdf       9.9G  3.0G  6.5G  32% /vol
overflow        1.0M  1.0M     0 100% /tmp

node.js

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

1

"ENOSPC" หมายความว่าไม่มีที่ว่างในไดรฟ์คุณจะบันทึกไฟล์ของคุณไว้ที่ไหน หรืออาจจะ / tmp เต็ม?

— Jacob A.

ฉันบันทึกไฟล์ใน / dev / xvda1 ฉันสามารถสร้าง rm -rf / tmp / * ได้ไหม

— Giffo

1

ใช่ แต่ฉันไม่คิดว่า 1mb เพียงพอสำหรับการอัปโหลดไฟล์ดังนั้นเปลี่ยน tmp-dir เป็นตำแหน่งอื่นเช่นในคำตอบจาก Blu Angel

— Jacob A.

3

ดูเหมือนว่ากรณีการใช้งานของคุณอาจแตกต่างกัน แต่นี่เป็นวิธีแก้ปัญหาที่ยอดเยี่ยมสำหรับคำถาม SO อื่น

— Isaac Gregson

สำหรับทุกคนที่สะดุดข้ามนี้ตรวจสอบคำตอบนี้เช่นกัน ใช้เสียงฮึดฮัดและอึกสามารถใช้นาฬิกาจำนวนมากดังนั้นคำตอบนี้รายละเอียดวิธีการเพิ่มที่

— เซย์เรีย

1273

เรียกใช้คำสั่งด้านล่างเพื่อหลีกเลี่ยง ENOSPC:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

สำหรับ Arch Linux เพิ่มบรรทัดนี้ไปที่/etc/sysctl.d/99-sysctl.conf:

fs.inotify.max_user_watches=524288

จากนั้นดำเนินการ:

sysctl --system

สิ่งนี้จะคงอยู่ตลอดการเรียบเครื่อง รายละเอียดทางเทคนิคที่มา

— พระกฤษณะ
แหล่งที่มา

25

นี่คือสิ่งที่มันทำ github.com/guard/listen/wiki/…

— Agus Syahputra

2

มันไม่ใช่ตัวเลขสุ่ม นาฬิกา inotify ที่ใช้แต่ละอันจะใช้เวลา 540 ไบต์ (ระบบ 32- บิต) หรือ 1 kB (สองครั้ง - บน 64- บิต) นี่มาจากหน่วยความจำเคอร์เนลซึ่งไม่สามารถเปิดใช้งานได้ ดังนั้นสมมติว่าคุณตั้งค่าสูงสุดไว้ที่ 524288 และทั้งหมดถูกใช้ (ไม่น่าจะเป็นไปได้) คุณจะใช้ประมาณ หน่วยความจำเคอร์เนล 32- บิต / 64- บิต 256MB / 512MB

— Murali Krishna

ในทางทฤษฎีไม่มีค่าสูงสุดตราบใดที่คุณมี RAM เพียงพอ ในทางปฏิบัติ 524288 ได้รับการแนะนำอย่างเป็นทางการจากแอพและผู้คนตั้งค่าเป็น 2 ล้านด้วยการใช้หน่วยความจำที่มาพร้อมกัน

— Murali Krishna

สิ่งนี้ช่วยฉันในการแก้ปัญหาและลิงค์นี้github.com/guard/listen/wiki/…มีรายละเอียดทั้งหมด ขอบคุณ

— amitsin6h

มีใครอีกบ้างที่คิดว่าแปลกที่ข้อผิดพลาดที่เกิดขึ้นนั้นง่ายENOSPCหรือไม่? ทำไมไม่มีคำอธิบายหลังจากเอ้าท์พุทเป็นENOSPC - no space on driveอย่างไร แน่นอนว่ารหัสข้อผิดพลาดทำให้รู้สึกเมื่อคุณรู้ว่ามันหมายถึงอะไร ( E rror NO SP Cจ) แต่ทำไมไม่เพียงแค่ให้ผู้ใช้ทราบว่าข้อมูลขึ้นด้านหน้า?

— Shadoninja

73

ENOSPC หมายความว่าไม่มีที่ว่างบนไดรฟ์

อาจ/tmpจะเต็มหรือไม่ คุณสามารถกำหนดค่าnpmให้ใช้โฟลเดอร์ temp อื่นโดยการตั้งค่าnpm config set tmp /path/to/some/other/dirหรืออาจลบทุกอย่างออกจาก/tmpโฟลเดอร์

ที่มา: npm 1.1.21 ไม่สามารถเขียนได้ ENOSPCใน repo ของ npm ใน github

หมายเหตุฉันแก้ไขปัญหาของฉันตามวิธีที่อธิบายไว้ในแหล่งที่มาด้านบน อย่างไรก็ตามดูคำตอบของ Murali Krishnaด้านล่างซึ่งครอบคลุมมากกว่านี้

— บลู
แหล่งที่มา

ฉันทำความสะอาดโฟลเดอร์ / tmp และเปลี่ยนโฟลเดอร์ npm temp แต่มีปัญหาเดียวกัน npm config get tmpshow / vol / deploy / tmp

— Giffo

คุณสามารถแสดงให้คุณเห็นอีกครั้ง? เอาท์พุทที่คุณได้รับหลังจากการเปลี่ยนแปลง dir

— Blu

events.js:71 throw arguments[1]; // Unhandled 'error' event Error: ENOSPC, write

— Giffo

1

คุณมีผู้ฟังข้อผิดพลาดหรือไม่? ถ้าไม่เขียนมากกว่าหนึ่งตัวจากนั้นตรวจสอบผลลัพธ์ที่ได้

— Blu

72

ผิดข้อผิดพลาดนี้เกิดขึ้นบ่อยครั้งในพื้นที่ทำงานของนักพัฒนาซอฟต์แวร์เมื่อดูไฟล์ (ผ่านเสียงฮึดฮัด / อึก) สิ่งนี้เกี่ยวข้องกับขีด จำกัด unix ของจำนวนไฟล์ที่กระบวนการสามารถดูได้ (native watch) คำตอบอื่น ๆ (echo fs.inotify.max_user_watches = 524288) เป็นวิธีแก้ปัญหาในกรณีเหล่านั้น

— Cancerbero

26

ไม่สามารถรับเครดิตได้ แต่@grenadeชี้ให้เห็นว่าnpm dedupeจะแก้ไขสาเหตุ (ไฟล์มากเกินไป) และไม่ใช่อาการ

แหล่งที่มา: ข้อผิดพลาดนาฬิกาฮึดฮัด - รอ ... ความผิดพลาดร้ายแรง: นาฬิกา ENOSPC

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

20

วิธีง่ายๆในการแก้ปัญหาของฉันคือ:

npm cache clear

npmหรือกระบวนการที่ควบคุมโดยดูไฟล์มากเกินไป การอัพเดต max_user_watches บนโหนดบิลด์สามารถแก้ไขได้ตลอดไป สำหรับ debian ให้ใส่สิ่งต่อไปนี้บนเทอร์มินัล:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

หากคุณต้องการทราบวิธีเพิ่มจำนวน inotify ผู้เฝ้าดูเพียงคลิกที่ลิงค์

— Danrley Willyan
แหล่งที่มา

2

ฉันมีปัญหากับการforever,แก้ไขเมื่อฉันสร้างไฟล์.foreverignoreและเพิ่มลงในโฟลเดอร์node_modules.

— Vilintritenmert

7

การรีบูตเครื่องช่วยแก้ปัญหาสำหรับฉัน ฉันพยายามเช็ดครั้งแรก/tmp/แต่โหนดยังคงบ่นอยู่

— Bjorn Reppen
แหล่งที่มา

ปัญหากลับมาหลังจากรีบูตเครื่อง ทำdedupeช่วย

— Parnab Sanyal

4

บน Linux นี่เป็นข้อ จำกัด เกี่ยวกับจำนวนการเฝ้าดูไฟล์

เซิร์ฟเวอร์การพัฒนาใช้inotifyเพื่อใช้การโหลดซ้ำร้อน inotify API ช่วยให้เซิร์ฟเวอร์การพัฒนาสามารถดูไฟล์และรับการแจ้งเตือนเมื่อมีการเปลี่ยนแปลง

ค่า จำกัด การดูไฟล์เริ่มต้นจะแตกต่างกันไปตามการแจกจ่าย (8192 บน Fedora) ความต้องการของเซิร์ฟเวอร์การพัฒนามักเกินขีด จำกัด นี้

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

วิธีดูขีด จำกัด ปัจจุบันของคุณ:

sysctl fs.inotify.max_user_watches

หากต้องการตั้งค่าขีด จำกัด ใหม่ชั่วคราว:

# this limit will revert after reset
sudo sysctl fs.inotify.max_user_watches=524288
sudo sysctl -p
# now restart the server and see if it works

หากต้องการตั้งค่าขีด จำกัด ถาวร:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

— วูดโรว์บาร์โลว์
แหล่งที่มา

3

บน Ubuntu 18.04 ฉันลองใช้เคล็ดลับที่ฉันใช้เพื่อเปิดใช้งานการดูไฟล์โดย ionic / node และทำงานได้ที่นี่ สิ่งนี้อาจเป็นประโยชน์สำหรับผู้ที่ไม่มีสิทธิ์เข้าถึงไฟล์ระบบ

CHOKIDAR_USEPOLLING=1 npm start

— Manolo de la Vega
แหล่งที่มา

2

ฉันแก้ไขปัญหาที่ฆ่ากระบวนการติดตามติดตามทั้งหมด (คุณสามารถลองถ้าคุณใช้ GDM ไม่ใช่กรณีของคุณถ้าสคริปต์กำลังทำงานบนเซิร์ฟเวอร์)

tracker-control -r

การตั้งค่าของฉัน: Arch ด้วย GNOME 3

— Denys Vitali
แหล่งที่มา

1

ลืมที่จะระบุว่าใช่ฉันอยู่ในสถานการณ์เดียวกัน: Arch + GNOME

— Denys Vitali

2

หากคุณ/tmpติดอยู่ในลินุกซ์ระบบแฟ้มที่ติดตั้งเป็นล้น (มักจะมีขนาดที่ 1MB) นี้น่าจะเกิดจากคุณไม่ได้ระบุ/tmpเป็นพาร์ติชันของตัวเองและระบบแฟ้มรากของคุณเต็มไปขึ้นและ/tmpได้รับการนั่งประจำที่เป็นทางเลือก

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

sudo umount overflow

— Pradeep Kumar
แหล่งที่มา

2

หากคุณพบข้อผิดพลาดนี้ระหว่างการพยายามเรียกใช้ember serverคำสั่งกรุณาrm -rf tmpไดเรกทอรี จากนั้นเรียกใช้ember sอีกครั้ง มันช่วยฉัน

— Daniel Kmak
แหล่งที่มา

2

ฉันมีข้อผิดพลาดเดียวกัน ในขณะที่ฉันเรียกใช้แอป Reactjs สิ่งที่ฉันทำคือเพียงลบโฟลเดอร์ node_modules และพิมพ์และติดตั้ง node_modules อีกครั้ง สิ่งนี้จะลบข้อผิดพลาด

— Ghayyas Mubashir
แหล่งที่มา

มันใช้งานได้จริงทำไมมันลดลง - มันเป็นคำถาม แต่มันแก้ปัญหาได้ดังนั้นคุณต้องการอะไรอีกบ้าง

— AlexNikonov

1

ไม่ทราบอาจเป็นคนที่มีปัญหาส่วนตัวกับฉัน ฮ่าฮ่าฮ่า

— Ghayyas Mubashir

1

สำหรับฉันฉันถึงจำนวนไฟล์สูงสุดที่ผู้ใช้สามารถเป็นเจ้าของได้

ตรวจสอบหมายเลขของคุณด้วยquota -sและดูว่าหมายเลขใต้ไฟล์นั้นไม่ใกล้โควต้ามากเกินไป

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

1

ฟังดูแปลกมาก แต่ใช่ระบบจะรีบูทหรือkillall nodeแก้ไขปัญหาให้ฉัน

— Aram Paronikyan
แหล่งที่มา

-15

ในกรณีของฉันบน linux, sudoing แก้ไขปัญหาได้

ตัวอย่าง:

sudo gulp dev

— เซบาสเตียนชาร์เทียร์
แหล่งที่มา

5

สิ่งนี้เป็นอันตราย! เป็นไปได้ว่าจะประสบความสำเร็จเนื่องจากเปอร์เซ็นต์ของพื้นที่ดิสก์ที่สำรองไว้สำหรับรูทซึ่งไม่ได้แก้ไขปัญหาหลัก - ไม่มีพื้นที่ว่างในฐานะผู้ใช้ที่ไม่มีสิทธิ์ (ที่ตำแหน่งเป้าหมาย)

— Liam Dawson

การใช้ sudo เป็นวิธีที่ดีในการทำให้สิ่งต่าง ๆ เกิดขึ้น แต่คนส่วนใหญ่ละเลยที่จะเข้าใจทุกสิ่งที่เกิดขึ้นเมื่อใช้ sudo โดยเฉพาะอย่างยิ่งกับโมดูล npm และ npm การใช้ sudo สามารถส่งผลให้เกิดการดำเนินการโดย root ซึ่งผู้ใช้ไม่ต้องการให้ดำเนินการโดย root เช่นการสร้างไฟล์หรือการใช้พอร์ตที่ได้รับการป้องกัน โดยพื้นฐานแล้วคำแนะนำ "use sudo" จะตกลงบนใบหน้า (อาจเป็นหลังจากที่สะดุดและจ้องมองไปที่ดวงอาทิตย์สักครู่) โดยที่ nvm / npm / node เกี่ยวข้อง

— bschlueter