Hiç updatedbgerekli mi? Hiçbir zaman kullanmıyorum locateve sunucularımda uzun süre çalışacak ve MySQL ve / veya diğer yazılımların ihtiyaç duyduğu G / Ç'leri tüketen genellikle güncellenmiş olan milyonlarca dosya bulunmakta.
Sadece crondan çıkarabilir ve her şeyin çalışmasını bekleyebilir miyim? (her şeyden önce sunucuda bulunan normal yazılımları kastediyorum: linux, cpanel, mysql, apache, php vs.).
Yanıtlar:
Evet, onu cronlarda devre dışı bırakabilir veya sağlanan paketi çıkarabilirsiniz updatedb. Red Hat sisteminde, çıkarılmadan önce bir şey gerektirip gerekmediğinin belirlenmesi adımlarını uygulayacaksınız.
İlk önce programın diskte nerede olduğunu bulun.
$ type updatedb
updatedb is /usr/bin/updatedb
Daha sonra paketin ne sağladığını öğrenin updatedb.
$ rpm -qf /usr/bin/updatedb
mlocate-0.26-3.fc19.x86_64
Bakalım bir şey lazım mı mlocate?
$ rpm -q --whatrequires mlocate
no package requires mlocate
Hiçbir şey gerektirmez, böylece paketi çıkarabilirsiniz.
$ yum remove mlocate
/var/lib/mlocatemiyim?
Paket yöneticinizi kullanarak kaldırın, eğer başka bir paket kullanıyorsa, bilmeniz gerekir, çünkü ona bağlı olmak zorundadır (paket bağımlılığı).
Ben bir sunucu var Nginx, php-fpmve mysql, ve bunlar olmadan güzel çalışıyor updatedb.
aptitude remove, aptitude whyya aptitude search '?installed ?recommends(mlocate)'. Bunların hepsi gösterilecek, taleplere ek olarak bağımlılıklar önerir. apt şimdi varsayılan olarak önerilen paketleri kurar, bu yüzden gerekli görülmese de, çok yararlı bazı alt işlevler sağlamak için güvenilir olabilirler.
Bunu söyleyerek uzuvların dışına çıkmayacağım, ama problemlerinize yol açması muhtemeldir. Muhtemelen istemediğiniz başka bir şey, 'beğeninize' göre yapılandırmamış olduğunuz bir yedekleme uygulaması veya profil / sistem grubu yapınızla ilgili bazı güvenlik sorunlarınız olabilir.
Sistem belleği tahsisinin kullanıcıya karşı çalıştığı göründüğü bir başka durum, bir 'sanal dosya sistemlerini istemediğini bilen' senaryosudur. Ve bu bir sorun yaratıcısı. Konuşmak için 'sanal bir mantık dışı bomba'.
Bir ext4 sistemde fat32'de biçimlendirilmiş USB sürücülerinde sık sık gerçekleşir ve bunlar daha sonra man giriş kabuğu olarak csh kabuğuyla yanlış ayarlanan zfs sistemlerine aktarılır. Diskte "Salt okunur USB dosya sistemi" sorununun sanal özyinelemesini oluşturur ve sürücüyü fat32'den vFat'a biçimlendirir / bağlar; sonsuz döngüye neden olan üst dizinler seviyesi! Dizin fiziksel olarak ebeveynin hiyerarşi düzeyinde değildir. Csh nedenlerinin sözdizimi bunun nedenidir. * NOT: Sürücü sadece tüm sistemlerde okunur, ancak bir zfs c-shell giriş sistemi bulunur.
Updatedb'yi tamamen devre dışı bırakmak, bellek ayırma ve 'geri alma etkisi' ile ilgili olarak mantıksal olmayan bir mantık yaratabilir. İstediğiniz zaman bir geri dönüş gerçekleştirdiyseniz, iki saatlik komut satırında ne demek istediğimi anlarsınız. komut dosyası Fubar-ed'dir, çünkü iş işleminizi belleğe ayırmadınız.
Şimdi iki veya daha fazla fiziksel işlemciniz varsa (örneğin, çift çekirdekli veya daha fazla) ve ddr3 ram, o zaman sorun değil. Ağır grafikler çalıştırmadığınız sürece, bu durumda bu güç yükü sorunlarınıza neden oluyorsa, updatedb listenizde en son sırada yer alır. Herhangi bir nedenden ötürü hareketlerinizi sisteme gizlemeye çalışıyorsanız, o zaman updatedb'yi devre dışı bırakmak yerine bunun için başka yollar da var ve aslında updatedb, sisteminize kılık değiştiren 'hiçbir şey olmadığı' eylemlerinizi sağlamlaştıracak.
Oldukça açıkçası / usr / bin / updatedb ikili dosyasının boyutuna dayanarak ve işletim sistemi ile sinyal / sistem iletişiminin mimarisini göz önüne alarak ve Bash'in 10 kat daha büyük olduğu zaman karşılıklı olarak bağlanmış kabuk çizgi veya kül asenkron çağrı sistemde çok ucuz.
Yazdığınız sıralı komut dosyalarını çalıştıran kabuğa giriş yaptıysanız ve bir yöneticiyseniz (örneğin sudo), aşağıdaki komutu çalıştırabilirsiniz:
~$ sudo bash
:~# ./script.sh
O zaman muhtemelen betiğinizde yerel bir değişken oluşturmak istersiniz (updatedb sistem yetkilerine ihtiyaç duyar, AKA root / sudo / wheel), örneğin:
#! /bin/sh
# Create local variables
UPD="updatedb"
echo "Beginning Execution of sequence "
Bu durumda, dizisi, yazdığınız ve ana betiğinizde değişken olarak çalıştığınız diğer kabuk betiklerinden STDOUT / STDIN kullanıyor veya cdrom'dan yüklediğiniz / indirdiğiniz / bağlantı noktanızı kurduğunuz kişisel veya işletme yönetici paketiniz olduğunu söylüyor. usb ya da her neyse, bu son derece büyük ve onlar için kişisel yükleme komut dosyalarına sahipseniz, updatedb TUTMAK İSTERSİNİZ. Terminal kabuğu açık olduğunda, ana uygulama örneğiniz budur. Diğer uygulamalar asenkron olarak çalışabilir / çalışabilir ancak updatedb, genel sistem / bilgi işlem talebi açısından en ucuz olanlardan biridir. Çoğu zaman, özellikle Lxdm Desk Enviro ve Lxterm'da (bu şey süper hızlıdır), ancak yalnızca; scriptlerime updatedb eklenmesiyle, sistem bana dosyaların bulunmadığı ya da berbat bir şey olduğu yönündeki hataları gösterdi. Ve ben neye benziyorum!
Kabuk yönettiği sistemden daha hızlıdır size garanti ederim!
Bu durumda, önceki sırayı gösterilen şekilde belleğe kilitlemek için updatedb değişkenini çağırırsınız.
echo "Updating local database "
$UPD
echo "Exiting script two "
exit
Ne dediğimi anladın mı? Bunu sorarsanız, çünkü yürütme hızı testleri yapıyorsunuz, yani Andrew Tanenbaum tarzı. Diğer akıllıca aleti kendi yararınıza kullanın.
locateişe yaramaz çünkü dizine alındığından emin olamıyorum. Dosyalar daha eskiyken gidip fzfbulanık bir arama yapıyorum .
En azından ArchLinux’da, varsayılan olarak etkin man-db.timerve görünür updatedb.timer(yani: aşağıdaki dosyalar var), ancak var 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. [...](çıktı systemctl enable {man-,update}db.timer).
Bunlar dosya sisteminde mevcut olan sembolik bağlardır:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
/usr/lib/systemd/system/multi-user.target.wants/updatedb.timer
Onları basitçe kaldırma meselesi olmalı.
Ancak, bunlar arasında yükseltmek / her re / yükleme sırasında yeniden olurdu man-db, mlocatesırasıyla paketler.
ArchLinux için olası bir geçici çözüm, pacman'ın bunları kaldırması için bir kancaya sahip olmaktır.
Ancak, yükseltme sırasında etkinleştirilmesini istemeseniz bile bu tür olaylarda bunları kaldırır.
Bu durumda, zamanlayıcının etkin olmasını istediğinizde kancayı devre dışı bırakabilirsiniz.
Ancak, zamanlayıcıyı etkinleştirmek yalnızca paketin yeniden kurulmasında / yükseltilmesinde etkili olacaktır, çünkü varsayılan .timerbirim dosyalarında doğrudan systemctl enablezamanlayıcılara yapılandırılmış bölüm yoktur . Zamanlayıcı / ları etkinleştirmek ve bunları devre dışı bırakmak için bağlantı / ları kaldırmak için
bir el kitabı ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timerveya ln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timerkomut gerekir.
Özel birimleri geçersiz kılabilirsiniz /etc/systemd/system/{man-,update}db.timer, izin WantedBy=multi-user.targetverilecek [Install]bölüm sağlanır systemtl enable|disable, ancak bağlantılar /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timeryeniden etkinleştirme / yeniden etkinleştirme, .timers'yi etkin bir şekilde yeniden etkinleştirme için oluşturulabilir .
systemctl mask man-db.timer updatedb.timerZamanlayıcıları maskelemek için de koşabilirsiniz . Karşılık gelen hizmetleri başlatmak
için manuel olarak çalıştırmanız hala mümkün olsa bile systemctl start man-db.service updatedb.service, kullanıcının istediği / yapması gereken nedenini bulması ne olursa olsun, zamanlayıcıları manuel olarak başlatamazsınız.
Bu geçici çözüm, /etc/systemd/system/{man-,update}db.timeristenildiğinde / gerektiğinde özel birim dosyalarının geçersiz kılınmasına izin vermez , çünkü sistemd /dev/nullmaskelenmiş bir birimi belirtmek için bunları sembolik bir bağlantıyla değiştirmek zorunda kalır.
Maskeleme en az müdahaleci bir çözüm gibi görünüyor. Her yükseltme işleminden sonra
el ile kaldırmayı /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerve el ile etkinleştirme / devre dışı bırakmayı etkinleştirmek için /etc/systemd/system/{man-,update}db.timerbir [Install]bölüme sahip geçersiz kılma birim dosyalarının olmasını tercih ederim .WantedBy=multi-user.targetsystemctl
Ne yazık ki, bu konuda basit bir çalışma yoktur, en azından şu anda düşünebildiğim.
Bu paketler varsayar man-db, mlocateonları istenen / kullanışlı bir çözüm olmaz çıkarmadan: sistemde yüklü tutulması için gerekli / aranıyor.
Ayrıca şunu da görün: https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/
rpmayrıca--whatrecommends. Bence Fedora son birkaç yıl içinde kavram olarak görmeye başladı. (Debian / ubuntu tarafının kurulmasından varsayılan olarak, "bağımlılıklar" olduğu kadar "tavsiye edilir" olanlar da kurulur.