Це updatedbвзагалі потрібно? Я ніколи не використовую, locateі мої сервери, як правило, мають десятки мільйонів файлів, що зазвичай робить updateb для роботи протягом тривалого часу і споживає введення-виведення, необхідне для MySQL та / або іншого програмного забезпечення.
Чи можу я просто вийняти його з cron і очікувати, що все спрацює? (я маю на увазі звичайне програмне забезпечення, яке можна знайти на сервері: linux, cpanel, mysql, apache, php тощо).
Відповіді:
Так, ви можете відключити його в кронах або видалити пакет, який надається updatedb. У системі Red Hat слід ознайомитись із кроками, щоб визначити, чи вимагає чогось перед видаленням.
Спочатку з’ясуйте, де програма знаходиться на диску.
$ type updatedb
updatedb is /usr/bin/updatedb
Далі з’ясуйте, що надає пакет updatedb.
$ rpm -qf /usr/bin/updatedb
mlocate-0.26-3.fc19.x86_64
Подивіться, чи потрібно щось mlocate.
$ rpm -q --whatrequires mlocate
no package requires mlocate
Нічого цього не вимагає, щоб ви могли вийняти пакет.
$ yum remove mlocate
/var/lib/mlocate?
Видаліть його за допомогою менеджера пакунків, якщо інший пакет ним користується, ви знатимете, оскільки він повинен залежати від нього (залежність пакета).
У мене є сервер з Nginx, php-fpmі mysql, і він прекрасно працює без нього updatedb.
aptitude remove, aptitude whyабо aptitude search '?installed ?recommends(mlocate)'. Всі вони покажуть, рекомендує залежності, крім необхідних. apt тепер встановлює рекомендовані пакети за замовчуванням, тому, хоча вони не вважаються істотними, на них цілком можна покластися, щоб забезпечити деяку дуже корисну підфункцію.
Я не збираюся далеко виходити на кінцівку, кажучи це, але, швидше за все, це не оновлення, яке викликає ваші проблеми. Можливо, чогось іншого, чого ви не хочете, або додатка для резервного копіювання, який ви не налаштували на свій смак, або якогось питання безпеки з вашою структурою групи профілю / системи.
Інший випадок, коли, здавалося б, розподіл пам’яті системи працює проти користувача, це сценарій, коли «невідоме складання віртуальних файлових систем». І це є великою проблемою. «Віртуальна бомба з логікою», так би мовити.
Досить часто трапляється з USB-накопичувачами, відформатованими у fat32 в системі ext 4, які потім переносяться на системи zfs, які неправильно налаштовані разом із оболонками csh як оболонка входу людини. Це створює віртуальну рекурсію проблеми "Файл лише для USB-файлів" на диску та форматує / монтує диск на vFat від fat32, що, в свою чергу, створює сектор поганих блоків і витягує (практично переміщує) каталог до його рівень батьківських каталогів, що викликає нескінченний цикл! Каталог фізично не є рівнем батьківської ієрархії. Синтаксис csh причини є причиною цього. * ПРИМІТКА: Привід зчитується лише у всіх системах, але не входить в систему zfs c-shell входу.
Повністю вимкнути оновленийb може створити неправильну логіку щодо розподілу пам'яті та "ефекту відката". Якщо у вас коли-небудь був відкат, коли ви цього не хотіли, ви знаєте, що я маю на увазі, коли командний рядок коштує дві години сценарій є Fubar-ed, тому що ви не виділили свою роботу з обробкою в пам'ять.
Тепер, якщо у вас є два або більше фізичних процесора (наприклад, двоядерний або більше) і ddr3 ram, то ваш штраф. До тих пір, поки ваша не працює важка графіка, і в цьому випадку, якщо це завантаження викликає ваші проблеми, updateb буде останнім у вашому списку. Якщо ви намагаєтесь з якихось причин замаскувати свої рухи до системи, то є інші способи зробити це, а не вимкнути оновленняb, і насправді оновлення зміцнить ваші дії, які «нічого не трапляться», наскільки маскування до вашої системи.
Відверто базуючись на розмірі двійкового файлу / usr / bin / updatedb та з огляду на архітектуру сигналу / системної комунікації з-в ОС, і що Bash в 10 разів перевищує розмір взаємно пов'язаного тире оболонки або попелу, асинхронний виклик дуже недорогий у системі.
Якщо ви ввійшли в оболонку, де виконуються написані послідовні сценарії, і ви є адміністратором (наприклад, sudo), виконуючи таку команду:
~$ sudo bash
:~# ./script.sh
Тоді, ймовірно, ви хочете створити локальну змінну у вашому сценарії (оновленняb потребує системних привілеїв, корінь / судо / колесо AKA), наприклад:
#! /bin/sh
# Create local variables
UPD="updatedb"
echo "Beginning Execution of sequence "
У такому випадку послідовність використовує STDOUT / STDIN з інших сценаріїв оболонки, які ви написали та виконуєте як змінні у своєму головному сценарії, або скажіть, що у вас встановлений персональний або службовий пакет адміністратора, де ви завантажуєте / завантажуєте / портуєте з cdrom або usb чи будь-що інше, що надзвичайно велике та має персональні сценарії встановлення для них, ЩО ВИ ХОЧЕТЕ ДЕРЖАВАТИ updateb. Коли оболонка термінала відкрита, це ваш головний екземпляр програми. Інші програми можуть / не працювати асинхронно, але оновленийb є одним з найменш дорогих з точки зору загального системного / обчислювального попиту. Багато разів, особливо з lxdm Desk Enviro's та Lxterm (це дуже швидко), але не виключно; з додаванням updateb до моїх сценаріїв, система видала мені помилки, що файли не існують, або що щось кричуще сталося. І мені подобається, ЩО!
Оболонка швидша, ніж система, яку вона адмініструє. Я вам гарантую!
У такому випадку ви б зателефонували до змінної updatedb, щоб заблокувати попередню послідовність у пам'яті, як показано
echo "Updating local database "
$UPD
echo "Exiting script two "
exit
Ви бачите, що я кажу? Якщо ви запитаєте це, тому що ви виконуєте тести на швидкість виконання, тобто стиль Ендрю Таненбаума, ніж у нього. Інші розумно використовують інструмент на вашу користь.
locateце не корисно, оскільки я не можу бути впевнений, що він індексується. Коли файли постаріють, я переходжу до fzfнечіткого пошуку.
Принаймні , в 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все одно створюватимуться при повторній установці / оновлення, що ефективно переновлює .timers.
Ви також можете бігти systemctl mask man-db.timer updatedb.timerмаскувати таймери.
Навіть якщо все-таки вдасться вручну запустити systemctl start man-db.service updatedb.serviceдля запуску відповідних служб, ви не зможете вручну запустити таймери, з будь-якої причини користувач виявить, що хочуть / потребують цього зробити.
Таке вирішення не дозволяє мати /etc/systemd/system/{man-,update}db.timerпри бажанні / необхідності переопределення файлів користувацьких одиниць, оскільки systemd потребує заміни їх символічним посиланням, /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.targetщоб увімкнути systemctl/ відключити вручну .
На жаль, простого вирішення цього питання немає, що, принаймні, я можу подумати, в цей час.
Це передбачає, що пакунки man-db, mlocateякі потрібно / потрібно тримати, встановлюються в системі: видалення їх не буде бажаним / корисним рішенням.
Також дивіться це: https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/
rpmтакож є--whatrecommends. Я думаю, що Fedora почала розглядати це як концепцію за останні кілька років. (Довго після того, як сторона debian / ubuntu за замовчуванням встановила "рекомендує" залежності, а також "вимагає".