ऑटोफोंस निष्क्रिय होने के बाद डिस्कनेक्ट नहीं होता है

Question

मेरे पास कई लिनक्स सर्वरों पर स्थापित ऑटोफॉल्स हैं जो उपयोगकर्ताओं / होम निर्देशिकाओं के लिए केंद्रीय एनएफएस सर्वर से जुड़ रहे हैं। लॉगिन पर निर्देशिकाओं को बढ़ते समय यह बहुत अच्छा काम करता है, लेकिन माउंट कभी भी मध्यांतर में नहीं लगता है। मैंने जाँच की है / / sysconfig / autofs और डिफ़ॉल्ट वास्तव में 300 पर सेट है, इसलिए ये 5 मिनट के बाद समाप्त हो जाना चाहिए।

ऑटोफ़ोटो को पुनः आरंभ करना सभी निर्देशिकाओं को umount करता है, इसलिए मुझे पता है कि यह सक्षम है।

मैंने निर्देशिकाओं पर बेतरतीब ढंग से lsof का उपयोग करने का प्रयास किया है, लेकिन कोई भी फाइल किसी भी समय खुली नहीं दिखाई देती है।

मैंने एक यादृच्छिक निर्देशिका भी शुरू की है जो मुझे पता है कि सक्रिय नहीं है, लेकिन ये कभी भी अपने आप को umount नहीं करते हैं। इनमें से कुछ बॉक्स में 10+ उपयोगकर्ता हैं जिन्होंने एक बार लॉग इन किया है, और माउंट कभी नहीं छोड़ते हैं।

मैं सिर्फ यह पता लगाने की कोशिश कर रहा हूं कि यह पता लगाने का एक बेहतर तरीका क्यों है। मैं किसी भी लॉग में कुछ विशिष्ट नहीं देखता।

किसी भी सुझाव की सराहना की है। धन्यवाद!

अपडेट करें

मैं ऑटोफॉक्स के लिए डिबगिंग में बदल गया, लेकिन यह सामान्य से कुछ भी प्रकट नहीं करता है। ये लॉग / होम / user1 शुरू में घुड़सवार होने के 6 मिनट बाद और 6 मिनट की निष्क्रियता के बाद उत्पन्न हुए थे। 5 मिनट के डिफॉल्ट के अनुसार, यह अनमाउंट होना चाहिए था। मैंने कभी नहीं देखा कि एक लॉग के माध्यम से आने का संकेत दिया गया था, यहां तक ​​कि umount के लिए भी प्रयास किया गया था।

Jan 11 12:52:00 linux automount[26505]: st_expire: state 1 path /home
Jan 11 12:52:00 linux automount[26505]: expire_proc: exp_proc = 3055176592 path /home
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user1
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user2
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user3
Jan 11 12:52:00 linux automount[26505]: 3 remaining in /home
Jan 11 12:52:00 linux automount[26505]: expire_cleanup: got thid 3055176592 path /home stat 7
Jan 11 12:52:00 linux automount[26505]: expire_cleanup: sigchld: exp 3055176592 finished, switching from 2 to 1
Jan 11 12:52:00 linux automount[26505]: st_ready: st_ready(): state = 2 path /home

अद्यतन 2 इस बारे में Red Hat समर्थन से बात करने के बाद, यह समाधान समाप्त हो गया कि घर निर्देशिकाओं के लिए टाइमआउट मान को छोटा कर दिया जाए। मैंने ऐसा किया है और अच्छा दिखता है। जाहिरा तौर पर कुछ हर 2 से 3 मिनट में आरोह बिंदु को पार कर रहा है और इसके कारण यह बना रहता है।

समाधान उस मैपिंग के लिए /etc/auto.master फ़ाइल में टाइमआउट मान जोड़ने के लिए था:

 /home     /etc/auto_home --timeout=120

Comments

यह निर्धारित करने के लिए कि आप क्या उपयोग कर रहे हैं? मैं मानता हूं df, लेकिन सिर्फ स्पष्ट करना चाहता हूं।

— बंजर

हां, मैं माउंटेड स्पेस की जांच करने के लिए df का उपयोग कर रहा हूं। मैं बस निर्देशिका के लिए सीडी के रूप में उन्हें माउंट करने के लिए रूट।

— स्टीवएचएन

Answer 1

समय-समय पर परिवर्तनशील ऑटोफॉक्स के अलावा एक चेकिंग अंतराल है:

# cat /var/log/messages
Jan 11 21:45:35 client automount[24804]: mounted offset on /net/server/share with timeout 300, freq 75 seconds

यह TIMEOUT / 4 के बराबर है। हर बार / 4 सेकंड ऑटोफोटो कर्नेल से पूछता है कि पिछली बार निर्देशिका कब एक्सेस की गई थी। तो आपके वातावरण में 375 सेकंड की निष्क्रियता के बाद आपके पास निर्देशिका है।

अधिक विस्तृत लॉग आप जोड़ना चाहिए प्राप्त करने के लिए LOGGING="debug"करने के लिए/etc/sysconfig/autofs

Comments

समझा। स्पष्टीकरण के लिए धन्यवाद। उपरोक्त लॉग 6 मिनट की निष्क्रियता के बाद अच्छी तरह से जारी रहे, और 375 सेकंड से अधिक हो गए। मुझे लगता है कि कुछ इन निर्देशिकाओं तक पहुँचने के लिए है, या उमर का प्रयास किया जाएगा। मुझे लगता है कि मेरा असली उद्देश्य यह पता लगाना है कि इस निर्देशिका का उपयोग क्या है, अगर कुछ भी हो। यही एकमात्र कारण हो सकता है कि मैं सोच सकता हूं कि यह बहुत अधिक नहीं होगा।

— स्टीवएचएनएच

Answer 2

मुझे भी ऐसी ही समस्या का समाधान करना पड़ा था। मैंने अपने 10 साल पुराने RHEL 4.7 ProLiant सर्वर को क्रिसमस के ब्रेक पर CentOS 6 के साथ फिर से इंस्टॉल किया। मेरे पास 2 नए समर्थक थे जिन्हें मैं हाल ही में (अप्रैल में) CentOS 7 स्थापित करने में सक्षम था।

मैंने CentOS 6 सर्वर /etc/auto.masterपर एक पंक्ति का उपयोग करके CentOS 6 सर्वर से होम निर्देशिकाओं को स्वचालित रूप से कॉन्फ़िगर किया है:

/home   /etc/auto.home

फिर मैंने /etc/auto.homeशुरू में एक लाइन के साथ CentOS 7 सर्वर पर एक नई फ़ाइल बनाई :

*      sam:/home/&

घर निर्देशिका हालांकि unmount नहीं होगा। मैंने यह भी पाया कि घर निर्देशिकाओं में कुछ फ़ाइल मालिक समय-समय पर उनके खिलाफ एक विशाल यूआईडी और जीआईडी ​​नंबर के साथ समाप्त हो जाते हैं। यह कुछ मिनटों के बाद बदल जाएगा।

मैं लॉगिंग स्तर को 'डीबग' में सेट करता हूं /etc/autofs.confऔर साथ देखना शुरू करता हूं journalctl -fu autofs.service। मैंने लगभग समान संदेश देखे जैसा कि ऊपर दिखाया गया है, जिसमें कोई सुराग नहीं था।

जैसा कि मैं अभी तक एनएफएस 4 को समझ नहीं पाया था, और मुझे पता था कि हमारा सेंटोस 6 सर्वर डिफ़ॉल्ट रूप से एनएफएस 4 के रूप में अपने शेयर निर्यात कर रहा था, मैंने nfsvers=3इस /etc/auto.homeतरह से फाइल में जोड़ने की कोशिश की :

training      -nfsvers=3,noac,soft,intr  sam:/home/training

मैं निर्देशिका को माउंट करने की कोशिश करने के बारे में अजीब संदेश भी देख रहा था /home/lib, इसलिए अलग-अलग लाइनों पर व्यक्तिगत होम निर्देशिकाओं को जोड़ा। (संभवतः इस बिंदु पर प्रत्यक्ष आरोह की कोशिश करनी चाहिए थी, या सिस्टमड ऑटोमोटिव की कोशिश की थी।)

अब मुझे इस तरह के संदेश दिखाई देने लगे:

Apr 27 09:32:28 betty automount[13501]: expire_proc_indirect: expire /home/fred
Apr 27 09:32:28 betty automount[13501]: handle_packet: type = 4
Apr 27 09:32:28 betty automount[13501]: handle_packet_expire_indirect: token 21, name fred
Apr 27 09:32:28 betty automount[13501]: expiring path /home/fred
Apr 27 09:32:28 betty automount[13501]: umount_multi: path /home/fred incl 1
Apr 27 09:32:28 betty automount[13501]: umount_subtree_mounts: unmounting dir = /home/fred
Apr 27 09:32:28 betty automount[13501]: spawn_umount: mtab link detected, passing -n to mount
Apr 27 09:32:29 betty automount[13501]: rm_unwanted_fn: removing directory /home/fred
Apr 27 09:32:29 betty automount[13501]: expired /home/fred
Apr 27 09:32:29 betty automount[13501]: dev_ioctl_send_ready: token = 21
Apr 27 09:32:29 betty automount[13501]: handle_packet: type = 4
Apr 27 09:32:29 betty automount[13501]: handle_packet_expire_indirect: token 22, name barney
Apr 27 09:32:29 betty automount[13501]: expiring path /home/barney
Apr 27 09:32:29 betty automount[13501]: umount_multi: path /home/barney incl 1
Apr 27 09:32:29 betty automount[13501]: umount_subtree_mounts: unmounting dir = /home/barney
Apr 27 09:32:29 betty automount[13501]: spawn_umount: mtab link detected, passing -n to mount
Apr 27 09:32:29 betty automount[13501]: rm_unwanted_fn: removing directory /home/barney
Apr 27 09:32:29 betty automount[13501]: expired /home/barney
Apr 27 09:32:29 betty automount[13501]: dev_ioctl_send_ready: token = 22
Apr 27 09:32:29 betty automount[13501]: expire_proc_indirect: expire /home/barney
Apr 27 09:32:29 betty automount[13501]: expire_proc_indirect: expire /home/wilma
Apr 27 09:32:29 betty automount[13501]: 1 remaining in /home

होम निर्देशिकाओं को अब 10 मिनट के बाद अनमाउंट करना शुरू कर दिया जैसे उन्हें चाहिए - इसलिए यह मेरे मामले में गलत एनएफएस 4 के साथ एक समस्या थी।

महत्वपूर्ण: नक्शे को फिर से तैयार करने के बाद, बस करने systemctl daemon-reloadया systemctl reload autofsकोई प्रभाव नहीं पड़ता है। मुझे करना थाsystemctl restart autofs

Answer 3

किसी भी अन्य समान मुद्दों का अनुभव करने के लिए आधुनिक डेस्कटॉप पर जीयूआई प्रक्रियाएं हैं जो ड्राइव को लगातार स्कैन करती हैं। विशेष रूप से केयूडी पर गनोम और डॉल्फिन पर नॉटिलस के साथ-साथ बालू जैसे फ़ाइल अनुक्रमण अनुप्रयोगों के साथ। ये सभी लक्षण पैदा करने में सक्षम हैं।

मेरे लिए (KDE चल रहा है) ऑटोमाउंट डीबग लॉगिंग से एकमात्र सुराग "1 शेष" था उदाहरण के लिए:

    Feb 13 00:00:44 fig automount[19026]: expire_proc: exp_proc = 139620739028736 path /mnt/vchanger
    Feb 13 00:00:44 fig automount[19026]: expire_proc_indirect: expire /mnt/vchanger/fb207cd6-6931-4af4-8293-c82ee0d2394c
    Feb 13 00:00:44 fig automount[19026]: 1 remaining in /mnt/vchanger

यह वास्तव में स्रोत की पहचान नहीं करता है। इसके अलावा lsof, fuser और audctctl (ऑडिट) में से किसी ने भी कोई जानकारी नहीं दी।

अंततः उन्मूलन की प्रक्रिया से मैंने निर्धारित किया कि 2 आवेदन थे:

• KSysGuard (KDE सिस्टम मॉनिटर)
• डॉल्फिन (फ़ाइल प्रबंधक)

डॉल्फिन के साथ इस मामले में उसके पेड़ के दृश्य में आपत्तिजनक माउंटेड डिस्क को "छिपाकर" तय किया जा सकता है।

KSysGuard दिखाई नहीं देता है, लेकिन तब इसका असामान्य होना इसे लंबे समय तक चलने के लिए जब तक आप कुछ डिबगिंग नहीं करते। उम्मीद है कि ऑटोमोटिव माउंट प्वाइंट को स्कैन करने से रोकने के लिए अन्य अनुप्रयोगों को अनुमति देने में अधिक विन्यास हो सकता है।

Comments

FYI करें, यदि आप अपनी पोस्ट को संपादित करने से पहले लॉगिन करते हैं, तो आपको इसे बाद में अनुमोदित करने की आवश्यकता नहीं होगी (या अन्य लोगों को इसे अनुमोदित करने के लिए घंटों इंतजार करना होगा)।

— जी-मैन का कहना है कि 'मोनिका बहाल'

Answer 4

मैंने आज घंटों डिबग और इसी तरह की समस्या के लिए कोशिश की। यहां मुझे वही मिला है और मैंने इसे कैसे काम किया है।]

सेटअप: मैं nfs सर्वर "srv1: / srv / घरों" से ग्राहकों के घर / dnt / mnt / nfs / घरों पर ग्राहकों से युक्त ऑटो माउंट dir करना चाहता था। NFS सर्वर NFS4 निर्यात करता है। autofs संस्करण 5.1.3

मैंने हर क्लाइंट को इस तरह कॉन्फ़िगर किया था:

/etc/auto.mount: निम्नलिखित युक्त फ़ाइल:

... 
/mnt/nfs /etc/auto.home
...

/etc/auto.home:

homes  -rw,soft,intr,rsize=8192,wsize=8192 srv1:/srv/homes

आखिरकार यह एक अप्रत्यक्ष मानचित्र का प्रतिनिधित्व करता है। ऑटो माउंट एक आकर्षण की तरह काम करता है। मुझे एनएफएस वॉल्यूम ठीक से माउंटेड और काम कर रहा है। लेकिन ... यह कभी भी ऑटो नहीं मिलता है। हालांकि स्वतः भरण फ़ाइल कहते हैं:

और mount600 सेकंड का टाइमआउट दिखाता है:

#1# /etc/auto.home on /mnt/nfs type autofs (rw,relatime,fd=18,pgrp=5054,timeout=300,minproto=5,maxproto=5,indirect) 
srv1:/srv/homes on /mnt/nfs/homes type nfs4 (rw,relatime,vers=4.2,rsize=8192,wsize=8192,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y)

मैं बिल्कुल वैसा ही दिखाई दे रहा था जैसे (डिबग लॉग लेवल ऐक्टिवेट) ऑटोफेक लॉग से जर्नलपेलमन के रूप में

automount[53593]: st_expire: state 1 path /mnt/nfs
automount[53593]: expire_proc: exp_proc = 139645987374848 path /mnt/nfs
automount[53593]: expire_proc_indirect: expire /mnt/nfs/homes
automount[53593]: 1 remaining in /mnt/nfs
automount[53593]: expire_cleanup: got thid 139645987374848 path /mnt/nfs stat 3
automount[53593]: expire_cleanup: sigchld: exp 139645987374848 finished, switching from 2 to 1
automount[53593]: st_ready: st_ready(): state = 2 path /mnt/nfs

उस समय मैंने ऑटोफोंस को छोड़ दिया और सिस्टमड के साथ ऑटोमाउंट कॉन्फिग को दोहराने का फैसला किया। वास्तव में मैंने इसे चलाया और इस समय सब कुछ बहुत अच्छा काम किया - ऑटो माउंट, पूर्वनिर्धारित निष्क्रिय अवधि के बाद ऑटो अनमाउंट। बिलकुल उत्तम। लेकिन सिस्टमड ... थोड़ा सा अनाड़ी (मुझ पर गोली मत चलाना, मैं वास्तव में इसे पसंद करता हूं)। तब मैंने देखा कि कैसे सिस्टम ऑटो बढ़ते को संभालता है:

#2# systemd-1 on /mnt/nfs/homes type autofs (rw,relatime,fd=35,pgrp=1,timeout=20,minproto=5,maxproto=5,direct)
srv1:/srv/homes on /mnt/nfs/homes type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y)

# 1 # और # 2 # के बीच अंतर यह है कि बाद वाला प्रत्यक्ष मानचित्र है, जबकि # 1 # अप्रत्यक्ष है। इसलिए मैंने तुरंत किसी अन्य क्लाइंट पर ऑटोफ़ॉक्स को फिर से कॉन्फ़िगर करने और उस जैसा सीधा मानचित्र बनाने का निर्णय लिया:

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

/mnt/nfs/homes  -rw,soft,intr,rsize=8192,wsize=8192 srv1:/srv/homes

और इससे अंततः समस्या हल हो गई है। ऑटो माउंट और ऑटो उमाउंट दोनों ने ठीक काम किया। umount /etc/autofs.conf में पूर्वनिर्धारित निष्क्रिय समय के बाद सफलतापूर्वक चलाया गया था

NFS सर्वर पर बिल्कुल कोई संशोधन की आवश्यकता नहीं थी।