क्या मैं अभी अपडेटेड को अक्षम कर सकता हूं?

Question

है updatedbसब पर आवश्यक? मैं कभी भी उपयोग नहीं करता हूं locateऔर मेरे सर्वर में दर्जनों लाखों फाइलें हैं जो आमतौर पर लंबे समय तक चलने के लिए और MySQL और / या अन्य सॉफ़्टवेयर द्वारा आवश्यक I / O का उपभोग करने के लिए अद्यतन करता है।

क्या मैं इसे क्रॉन से हटा सकता हूं और काम करने की उम्मीद कर सकता हूं? (सब कुछ मैं सर्वर पर पाया सामान्य सॉफ्टवेयर से मतलब है: linux, cpanel, mysql, apache, php आदि)।

Answer 1

हां आप इसे क्रोन में अक्षम कर सकते हैं या प्रदान करने वाले पैकेज को हटा सकते हैं updatedb। Red Hat सिस्टम पर यदि आप इसे हटाने से पहले कुछ भी चाहते हैं तो यह निर्धारित करने के चरणों के बारे में जानेंगे।

1. पहले पता करें कि प्रोग्राम डिस्क पर कहाँ स्थित है।

   $ type updatedb
   updatedb is /usr/bin/updatedb
   

2. अगला पता करें कि पैकेज क्या प्रदान करता है updatedb।

   $ rpm -qf /usr/bin/updatedb
   mlocate-0.26-3.fc19.x86_64
   

3. देखें कि क्या कुछ चाहिए mlocate।

   $ rpm -q --whatrequires mlocate
   no package requires mlocate
   

4. कुछ भी नहीं इसकी आवश्यकता है ताकि आप पैकेज को हटा सकें।

   $ yum remove mlocate
   

Comments

rpmभी है --whatrecommends। मुझे लगता है कि फेडोरा ने पिछले कुछ वर्षों में इसे एक अवधारणा के रूप में देखना शुरू किया। (लंबे समय के बाद डेबियन / ubuntu पक्ष स्थापित करने के लिए "सिफारिश" निर्भरता के रूप में अच्छी तरह से "की आवश्यकता है" लोगों को डिफ़ॉल्ट)।

— sourcejedi

तो हटाने के बाद क्या मैं हटा सकता हूं /var/lib/mlocate?

— रामरतन गुप्ता

@RamratanGupta - हाँ

— SLM

Answer 2

आप कॉन्फ़िगरेशन फ़ाइल /var/wwwको संपादित करके निर्देशिकाओं की स्कैनिंग को अक्षम कर सकते हैं, जिसमें कई फाइलें ( उदाहरण के लिए) हैं /etc/updatedb.conf। यदि आप वास्तव में इसे अक्षम करना चाहते हैं, तो क्रोनजोब को हटा दें।

Answer 3

अपने पैकेज मैनेजर का उपयोग करके इसे निकालें, यदि कोई अन्य पैकेज इसका उपयोग करता है, तो आपको पता चल जाएगा, क्योंकि इसे इस पर निर्भर होना है (पैकेज निर्भरता)।

मेरे पास एक सर्वर है Nginx, php-fpmऔर mysql, और यह बिना खूबसूरती से काम करता है updatedb।

Comments

साथ ही, उपयुक्त में आप उपयोग कर सकते हैं aptitude remove, aptitude whyया aptitude search '?installed ?recommends(mlocate)'। ये सभी आवश्यकताओं के अतिरिक्त, निर्भरता की सिफारिश करेंगे। apt अब डिफ़ॉल्ट रूप से अनुशंसित पैकेज स्थापित करता है, इसलिए जब उन्हें आवश्यक नहीं माना जाता है, तो वे कुछ बहुत उपयोगी उप-फ़ंक्शन प्रदान करने के लिए अच्छी तरह से भरोसा कर सकते हैं।

— sourcejedi

Answer 4

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

एक और मामला जिसमें यह प्रतीत होता है कि सिस्टम मेमोरी आवंटन उपयोगकर्ता के खिलाफ काम कर रहा है, वह परिदृश्य है जब एक 'अनजाने स्टैकिंग वर्चुअल सिस्टम सिस्टम'। और यह समस्या का घमंड है। एक 'आभासी बीमार तर्क बम' तो बोलने के लिए।

यह बहुत बार होता है एक अतिरिक्त 4 सिस्टम पर fat32 में स्वरूपित USB ड्राइव पर, जो तब zfs सिस्टम में स्थानांतरित हो जाते हैं जो कि csh शेल के साथ मैन लॉगिन शेल के रूप में अनुचित रूप से सेट होते हैं। यह डिस्क और फॉरमैट पर ड्राइव को "रीड-फाइल ओनली यूएसबी फाइल सिस्टम" प्रॉब्लम का वर्चुअल रिक्रिएशन बनाता है और ड्राइव को फैट 32 से vFat में बदल देता है, जो बदले में एक बैड ब्लॉक सेक्टर बनाता है, और इसके लिए एक डायरेक्टरी को अर्क (वस्तुतः मूव) करता है। मूल निर्देशिका स्तर, जो अनंत लूप का कारण बनता है! निर्देशिका पदानुक्रम के मूल स्तर पर शारीरिक रूप से नहीं है। Csh कारणों का सिंटेक्स इसका कारण है। * नोट: ड्राइव केवल सभी सिस्टम पर पढ़ा जाता है लेकिन एक zfs c-shell लॉगिन सिस्टम है।

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

अब यदि आपके पास दो या अधिक भौतिक प्रोसेसर हैं (उदाहरण के लिए दोहरे कोर या अधिक), और ddr3 रैम, तो आपका जुर्माना। जब तक आपका भारी ग्राफिक्स नहीं चल रहा है, उस स्थिति में यदि वह पॉवर लोड आपकी समस्याओं का कारण बन रहा है, तो अपडेटबेड आपकी सूची में अंतिम होगा। यदि आप किसी कारणवश सिस्टम में अपनी हरकतों को छिपाने की कोशिश कर रहे हैं, तो इसके अलावा अपडेटेड को अक्षम करने के बजाय इसके बारे में जाने के अन्य तरीके हैं, और वास्तव में अपडेटब आपके कार्यों को ठोस कर देगा कि आपके सिस्टम के लिए अब तक कुछ भी नहीं हुआ है।

द्विआधारी फ़ाइल / usr / बिन / अपडेटब के आकार के आधार पर काफी और ओएस के साथ सिग्नल / सिस्टम संचार की वास्तुकला पर विचार करते हुए और वह बैश 10 गुना आकार है जो पारस्परिक रूप से जुड़े शेल डैश या ऐस्क्रोनस कॉल के रूप में जुड़ा हुआ है। सिस्टम पर बहुत सस्ती है।

यदि आप शेल में क्रमिक स्क्रिप्ट्स में लॉग इन हैं, जो आपने लिखी है, और आप एक प्रशासक हैं (उदाहरण के लिए sudo), तो निम्न कमांड चला रहे हैं:

~$ sudo bash
:~# ./script.sh

तब आप शायद अपनी स्क्रिप्ट के भीतर एक स्थानीय चर बनाना चाहते हैं (अपडेट की जरूरत है सिस्टम निजीकृत, AKA रूट / sudo / व्हील), जैसे:

#! /bin/sh
# Create local variables
UPD="updatedb"

echo "Beginning Execution of sequence "

जिस मामले में अनुक्रम अन्य शेल स्क्रिप्ट्स से STDOUT / STDIN का उपयोग कर रहा है जो आपने लिखी हैं और अपनी मुख्य स्क्रिप्ट के साथ चर के रूप में निष्पादित कर रहे हैं या कहें कि आपके पास एक व्यक्तिगत या व्यवसाय व्यवस्थापक पैकेज सेट है जहाँ आप अपलोड / डाउनलोड / cdb से पोर्ट करते हैं usb या जो कुछ भी, वह बहुत बड़ा है और उनके लिए व्यक्तिगत स्थापना स्क्रिप्ट हैं, आप चाहते हैं KEEP अद्यतन। जब टर्मिनल शेल खुला होता है, तो यह आपका मुख्य एप्लिकेशन इंस्टेंस है। अन्य अनुप्रयोग एसिंक्रोनस रूप से चल / कर सकते हैं लेकिन अपडेटेड समग्र प्रणाली / कंप्यूटिंग मांग के मामले में कम से कम महंगा है। कई बार, विशेष रूप से एलएक्सडीएम डेस्क एनवायरो और लेक्सटरम (यह बात सुपर फास्ट) पर है, लेकिन पूरी तरह से; मेरी स्क्रिप्ट्स में अपडेटेड जोड़ने के साथ, सिस्टम ने मुझे त्रुटियां दी हैं कि फाइलें मौजूद नहीं हैं या कुछ खराब हो गया है। और क्या पसंद है!

शेल सिस्टम की तुलना में तेज है कि यह मुझे गारंटी देता है कि आप!

जिस स्थिति में आप अपडेटेड वैरिएबल को पिछले अनुक्रम को मेमोरी में लॉक करने के लिए कहेंगे, जैसा कि दिखाया गया है

echo "Updating local database "

$UPD

echo "Exiting script two "

exit

क्या आप देख रहे हैं कि इम क्या कह रहा है? यदि आप यह पूछते हैं क्योंकि आप निष्पादन गति परीक्षण चला रहे हैं, तो एंड्रयू टेनबाम स्टाइल की तुलना में यह अधिक है। अन्य बुद्धिमान अपने लाभ के लिए उपकरण का उपयोग करें।

Comments

अपडेटेड के साथ समस्या सीपीयू या मेमोरी नहीं है, लेकिन आईओ बैंडविड्थ है। मेरे मामले में (एक महान सीपीयू और बहुत सारी मेमोरी के साथ एक सिस्टम को अलग करने के लिए) यह 5 एमबी / एस पर घंटों के लिए मेरी हार्ड ड्राइव को स्पिन कर रहा है, एक-एक करके, बाकी सब को धीमा कर देता है जो उस ड्राइव पर निर्भर करता है। और जब मुझे पता चलता है कि मैं वास्तव में क्या देख रहा हूं, तो वे नई-ईश फाइलें हैं, इसलिए locateयह उपयोगी नहीं है क्योंकि मुझे यकीन नहीं है कि यह अनुक्रमित है। जब फाइलें बड़ी हो जाती हैं, तो मैं fzfखोजता हूं और एक फजी खोज करता हूं ।

— डेविड फे

Answer 5

कम से कम ArchLinux में, ऐसा प्रतीत होता है man-db.timerऔर updatedb.timerडिफ़ॉल्ट रूप से सक्षम हैं (जैसे: निम्नलिखित फाइलें मौजूद हैं), लेकिन वहाँ no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. [...](से आउटपुट systemctl enable {man-,update}db.timer) है।

ये फाइल सिस्टम में मौजूद प्रतीकात्मक लिंक हैं:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
/usr/lib/systemd/system/multi-user.target.wants/updatedb.timer

बस उन्हें हटाने की बात होनी चाहिए।
हालांकि, उन्हें क्रमशः प्रत्येक पैकेज / री-इंस्टॉलेशन / अपग्रेड man-db, mlocateपैकेज में फिर से बनाया जाएगा ।

ArchLinux के लिए, उन्हें हटाने के लिए pacman के लिए एक संभावित समाधान है हुक।
हालाँकि, यह उन्हें प्रत्येक ऐसे ईवेंट पर हटा देगा, भले ही आप उन्हें अपग्रेड में सक्षम करना चाहते हों।
आप उस स्थिति में, टाइमर को सक्षम करते समय हुक को अक्षम कर सकते हैं।
लेकिन, टाइमर को सक्षम करना केवल पैकेज के पुनः / स्थापना / उन्नयन पर प्रभावी होगा, क्योंकि डिफ़ॉल्ट .timerयूनिट फ़ाइलों में सीधे सीधे systemctl enableटाइमर के लिए कोई कॉन्फ़िगर अनुभाग नहीं है । टाइमर को सक्षम करने के लिए
एक मैनुअल ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timerया ln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timerकमांड की आवश्यकता होगी, और उन्हें अक्षम करने के लिए लिंक / एस को हटा दिया जाएगा।

आप कस्टम इकाइयों को ओवरराइड कर सकते हैं /etc/systemd/system/{man-,update}db.timer , अनुमति देने के WantedBy=multi-user.targetलिए [Install]अनुभाग में प्रदान करते हैं systemtl enable|disable, लेकिन लिंक /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerअभी भी पुनः / इंस्टॉलेशन / अपग्रेड पर बनाए जाएंगे, प्रभावी रूप से पुन: सक्षम कर रहे हैं .timer।

आप systemctl mask man-db.timer updatedb.timerटाइमर को चलाने के लिए भी दौड़ सकते हैं ।
यहां तक ​​कि अगर यह अभी भी systemctl start man-db.service updatedb.serviceइसी सेवाओं को शुरू करने के लिए मैन्युअल रूप से चलाने के लिए संभव होगा, तो आप जो भी कारण उपयोगकर्ता स्वयं को ऐसा करने के लिए स्वयं को चाहने / पाने की आवश्यकता के लिए मैन्युअल रूप से टाइमर शुरू करने में सक्षम नहीं होंगे।
यह वर्कअराउंड /etc/systemd/system/{man-,update}db.timerवांछित / ज़रूरत होने पर मौजूद कस्टम यूनिट फ़ाइलों को ओवरराइड करने की अनुमति नहीं देता है , क्योंकि सिस्टमड को /dev/nullनकाबपोश इकाई को सूचित करने के लिए उन्हें एक प्रतीकात्मक लिंक के साथ बदलने की आवश्यकता होती है ।

मास्किंग कम से कम घुसपैठ समाधान प्रतीत होता है।
मैं /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerप्रत्येक अपग्रेड के बाद मैन्युअल रूप से हटाना पसंद करता हूं , और मैन्युअल रूप से सक्षम / अक्षम करने के लिए /etc/systemd/system/{man-,update}db.timerएक [Install]सेक्शन वाले ओवरराइडिंग यूनिट फ़ाइलों को रखना पसंद करता हूं ।WantedBy=multi-user.targetsystemctl

दुर्भाग्य से, इसके आस-पास कोई सरल कार्य नहीं है, इस समय, कम से कम, मैं सोच सकता हूं।
मतलब यह है कि संकुल man-db, mlocateचाहता था कर रहे हैं / प्रणाली में स्थापित किए जाने के लिए की जरूरत: को दूर करने के लिए उन्हें एक वांछित / उपयोगी समाधान नहीं होगा।

इसे भी देखें: https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/