रिबूट के बिना udv नियमों को फिर से लोड कैसे करें?

Question

एक udv नियमों को कैसे पुनः लोड करना चाहिए, ताकि नव निर्मित एक कार्य कर सके?

मैं आर्क लिनक्स चला रहा हूं, और मेरे पास udevstartयहां कमांड नहीं है ।

यह भी जाँच की /etc/rc.d, वहाँ कोई udev सेवा नहीं है।

Comments

कृपया ध्यान दें कि udv के अधिक हाल के संस्करणों ने इनोटिफ़ाइड समर्थन को गिरा दिया है, इसलिए परिवर्तन पर नियमों को फिर से लोड करना इन दिनों अधिक बार आवश्यक है।

— कॉलिन गुथरी

क्या है udev? का प्रबंधक है /dev?

— सैंडबर्ग

@ सैंडबर्ग हां यह लिनक्स सिस्टम पर प्लग-एन-प्ले को संभालता है।

— आरोन डी। मरास्को

Answer 1

# udevadm control --reload-rules && udevadm trigger

Comments

क्या आपको udevtriggerबाद में आवश्यकता है?

— नेल्स

@ नील वास्तव में, आपको इसके udevtriggerबजाय (या udevadm triggerअधिकांश वितरणों पर) की आवश्यकता हो सकती है ( जो, या डिवाइस को प्लग आउट करके उसे वापस कर सकते हैं)। --reload-rulesलगभग हमेशा बेकार है क्योंकि यह स्वचालित रूप से होता है।

— गाइल्स

udevadm triggerमेरे लिए CentOS 6 पर चाल चली।

— astrostl

udevtriggerया udevadm triggerमेरे लिए काम नहीं किया। मैंने पाया कि कुछ उपकरण उसी के लिए मॉड्यूल को उतारने और लोड करने के बाद काम करेंगे (यह मानते हुए कि यह लोड करने योग्य मॉड्यूल है)। मुझे जो पता चला है वह जरूरी नहीं कि सिस्टम को रिबूट करना है। एक नेटवर्क डिवाइस के लिए उदाहरण के लिए, मैं करता हूँ rmmod ixgbe, rmmod tg3, rmmod e1000तो modprobe ixgbe, modprobe tg3, modprobe e1000नेटवर्क चालक के प्रकार पर निर्भर।

— उत्साह

डेबियन जेसी (8.0) पर मेरे लिए काम किए गए उत्तरों में से किसी भी चीज का उल्लेख नहीं किया गया। जो चीज काम करती है, ip link set $oldname name $newnameउसका उल्लेख यहां किया गया है । मेरे मामले में, मुझे एक इफिस नाम दिया गया था जिसका नाम lanएक ब्रिड्ड इफेस (केवीएम के लिए) था, और इसलिए मूल - अब अंतर्निहित - इफेक को अपना पुराना नाम eth1वापस प्राप्त करना था। तो चाल थी: 1) नीचे iface लाओ; 2) फिक्स नेटवर्क कॉन्फ़िगर अप; 3) अद्यतन udev नामकरण नियम फ़ाइल; 4) का उपयोग करके iface का नाम बदलें ip link...; 5) पुल को ऊपर ले आओ।

— कोस्टिक्स

Answer 2

Udev का उपयोग करता inotify , नियम निर्देशिका में परिवर्तन के लिए देखने के लिए दोनों पुस्तकालय में और स्थानीय विन्यास पेड़ (आमतौर पर स्थित में तंत्र /lib/udev/rules.dऔर /etc/udev/rules.d)। जब आप एक नियम फ़ाइल बदलते हैं तो अधिकांश समय आपको कुछ भी करने की आवश्यकता नहीं होती है।

आपको केवल udev डेमॉन को स्पष्ट रूप से सूचित करने की आवश्यकता है यदि आप कुछ असामान्य कर रहे हैं, उदाहरण के लिए यदि आपके पास एक नियम है जिसमें अन्य निर्देशिका में फाइलें शामिल हैं। तो फिर तुम डेमॉन से उनकी विन्यास फिर से लोड करने के लिए सामान्य सम्मेलन का उपयोग कर सकते हैं: एक भेजने SIGHUP ( pkill -HUP udevd)। या आप udevadmकमांड का उपयोग कर सकते हैं udevadm control --reload-rules:।

हालाँकि, सावधान रहें कि udv के विभिन्न संस्करणों में ऐतिहासिक रूप से नियमों को स्वचालित रूप से लोड करने के लिए अलग-अलग ट्रिगर थे। इसलिए यदि संदेह है, तो कॉल करें udevadm control --reload-rules: यह वैसे भी कोई नुकसान नहीं करेगा।

Udv नियम केवल तभी लागू होते हैं जब कोई उपकरण जोड़ा जाता है। यदि आप पहले से कनेक्ट किए गए डिवाइस पर नियमों को फिर से लागू करना चाहते हैं, तो आपको udevadm triggerडिवाइस (एस) से मिलान करने के लिए सही विकल्पों के साथ कॉल करके यह स्पष्ट रूप से करने की आवश्यकता है, जिसका कॉन्फ़िगरेशन बदल गया है, जैसे udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'।

Comments

क्या नियम के बदलावों को देखने के लिए सिस्टमदेव यूजिट का इस्तेमाल करता है?

— क्रेग मैकक्वीन

inotifyतंत्र हमेशा एक udev नियम फ़ाइल का एक परिवर्तन को पकड़ने नहीं है। उदाहरण के लिए जब मैं cat > 10-name.rulesसामग्री को पेस्ट करके नियम फ़ाइल को बदलने के लिए उपयोग करता हूं, तो मुझे मैन्युअल रूप से उपयोग करके नियमों को फिर से लोड करना होगा udevadm। रस्पियन स्ट्रेच पर परीक्षण किया गया।

— डैनियल के।

@DanielK। क्या यह हाल ही में बदल गया है? IIRC मैंने एक systemd udev और एक non-systemd udev दोनों की जाँच की जब मैंने यह उत्तर पोस्ट किया, और दोनों ने inotify का उपयोग किया, इसलिए --reload-rulesकेवल असामान्य मामलों में ही इसकी आवश्यकता थी।

— गिल्स

@ गिल्स: शायद ऊपर मेरा उदाहरण (शेल पुनर्निर्देशन का उपयोग करते हुए एक मौजूदा नियम फ़ाइल को अधिलेखित करना) को "असामान्य मामला" माना जा सकता है। जब मैंने एक संपादक के माध्यम से इस फाइल को संशोधित किया, जैसे, vi, inotifyतंत्र ने काम किया।

— डैनियल के।

@DanielK। आह, यह जानना अच्छा है। यह कोई असामान्य मामला नहीं है: कुछ संपादक पुनर्लेखन (विम और एमएसीएस के साथ फ़ाइल को सहेजेंगे, यह निर्भर करता है कि वे कैसे कॉन्फ़िगर किए गए हैं)। अजीब है कि udev केवल एक मामले को संभालता है - यह मेरे लिए एक बग जैसा दिखता है, क्योंकि मैं अलग तरीके से इलाज करने के लिए एक कारण के बारे में नहीं सोच सकता।

— गिल्स

Answer 3

मैं इसे जोड़ रहा हूं क्योंकि किसी दिन मुझे इसकी आवश्यकता होगी ... फिर से।

कभी-कभी आपको ईथरनेट डिवाइस नंबर और मैक एड्रेस का गलत मेल मिलता है। कभी-कभी यह वास्तव में महत्वपूर्ण होता है, जैसे कि वीएम में चलने पर और प्रत्येक डिवाइस को एक अलग वीएलएएन को सौंपा जाता है।

1. नेटवर्क इंटरफेस को नीचे लाएं, फिर
2. संशोधित /etc/udev/rules.d/70-persistent-net.rules(या इसके समकक्ष)
3. के साथ फिर से लोड udevadm control --reload-rules
4. के साथ फिर से ट्रिगर udevadm trigger --attr-match=subsystem=net
5. नेटवर्क इंटरफेस ऊपर ले आओ।

मैं हैरान था कि यह कितना अच्छा काम कर रहा है।

Comments

रेड हैट पर:service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start

— अलेक्जेंडर टॉर्टलिंग

डेबियन परीक्षण पर 'udvadm ट्रिगर --attr-match = सबसिस्टम = नेट' काम नहीं करता है। मुझे USB ईथरनेट कार्ड को अनप्लग और प्लग करना था, तभी udev ने नया नियम शुरू किया।

— ट्रिस्मेगिस्टोस

मैं शर्त लगाने के लिए तैयार हूँ, Trismegistos, कि अनप्लग / प्लग क्लेटन ड्यूक के उत्तर के अनुसार नेटवर्क ड्राइवर को हटाने और पुनः लोड करने के लिए समान है।

— माइक एस

Answer 4

मुझे यकीन नहीं है कि अगर यह लागू होता है, और यह निश्चित रूप से एक पुरानी पोस्ट है, लेकिन यह udev जानकारी के लिए मेरी वेब खोज को बहुत अधिक आया है तो मैंने सोचा कि मैं कुछ ज्ञान साझा कर सकता हूं।

आप विशिष्ट उपकरणों के लिए मैन्युअल रूप से udev नियम ट्रिगर कर सकते हैं। यह केवल रेडहैट-संबंधित डिस्ट्रोस (सेंटोस फेडोरा आदि) आदि पर लागू होता है।

एक बार जब आप अपनी नियम फ़ाइल ( /etc/udev/rules.d/whateveryoucalledyourrules) में प्रासंगिक परिवर्तन कर लेते हैं, तो आप changeडिवाइस के uevent को प्रतिध्वनित कर सकते हैं ।

echo change > /sys/block/devname/partname1/uevent

यह केवल इस उपकरण के लिए एक udev नियम पढ़ने को बाध्य करेगा। मेरी राय में बहुत बेहतर, और अधिक लक्षित।

Answer 5

मेरे लिए, नीचे दिए गए कमांड अनुक्रम ने काम किया है क्योंकि यह वांछित है।

मैंने संख्या /etc/udev/rules.d/70-persistent-net.rulesको बदलने ethऔर रिबूट किए बिना उन्हें फिर से लोड करने के लिए संशोधन किए हैं।

/etc/init.d/networking stop
/etc/init.d/udev stop
udevadm control --reload-rules
/etc/init.d/udev start
/etc/init.d/networking start

इसका पालन करते हुए, यह मशीन को रिबूट किए बिना रन टाइम में सफलतापूर्वक लोड किया गया था।

इस पर किसी भी सुझाव या सिफारिशों का स्वागत है, जैसा कि मैन पेजों को पढ़कर मैंने अपने दम पर इसे खोजा है।

Answer 6

मैं यहाँ सही उत्तर जोड़ रहा हूँ क्योंकि यह मुझे @enthyericgeek की टिप्पणी में नोटिस करने में थोड़ा समय लगा। आपको बस इतना करना चाहिए (यह मानते हुए कि आप सर्वर के कंसोल पर हैं - स्पष्ट रूप से यह करना बुरा है यदि आप ssh'd हैं::

1. उपयोग किए जा रहे इंटरफ़ेस मॉड्यूल की सूची प्राप्त करें:

cat /etc/udev/rules.d/70-persistent-net.rules | grep "PCI device" | perl -pe 's/.*\((\w+)\).*/$1/g'| uniq

मेरे मामले में, यह है igb, इसलिए यह सिर्फ प्रिंट करता है।

2. प्रकार sudo rmmod igb( igbचरण 1 से प्राप्त अपने कार्ड ड्राइवर के साथ बदलें)

अगला, /etc/udev/rules.d/70-persistent-net.rulesआवश्यकतानुसार संपादित करें , फिर मॉड्यूल का उपयोग करके फिर से लोड करें modprobe igb, फिर से आपकी जगह ले igb।

Comments

यह, ओथियस के उत्तर के साथ संयुक्त था, गुप्त सॉस था जिसने मुझे मशीन के रिबूट के बिना मेरे मेलानॉक्स नेटवर्क कार्ड के विन्यास को ठीक करने में सक्षम किया था। मेरा मानना ​​है कि ड्राइवर की लोडिंग और udvadm की रीडिंग लगातार-net.rules फ़ाइल मोटे तौर पर इस सिस्टम के समान होती है जब यह बूट होता है।

— माइक एस

Answer 7

कई नेटवर्क के मामले में

cat /etc/udev/rules.d/70-persistent-net.rules | grep "PCI device" | awk '{print $NF}'|sed -e 's/(//g' -e 's/)//g'| uniq > /tmp/listnet
rm -rf /etc/udev/rules.d/70-persistent-net.rules 
for i in $(cat /tmp/listnet); do rmmod $i; modprobe $i;done
service network restart
rm -rf /tmp/listnet