Является ли updatedbнужно вообще? Я никогда не использую, locateи мои серверы, как правило, содержат десятки миллионов файлов, что обычно заставляет updatedb работать долго и потреблять ввод-вывод, необходимый 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 в качестве оболочки man login. Он создает виртуальную рекурсию проблемы «Файловая система USB только для чтения» на диске и форматирует / монтирует диск в vFat из fat32, что, в свою очередь, создает сектор поврежденных блоков и извлекает (фактически перемещает) каталог до его Уровень родительских каталогов, который вызывает бесконечный цикл! Каталог не находится физически на уровне иерархии родителей. Синтаксис причин csh является причиной этого. * ПРИМЕЧАНИЕ. Диск доступен только для чтения во всех системах, кроме системы входа в систему zfs c-shell.
Полное отключение updatedb может привести к неправильной логике в отношении выделения памяти и «эффекта отката». Если у вас когда-либо был откат, когда он вам не нужен, вы понимаете, что я имею в виду, когда в командной строке стоит два часа Сценарии написаны Fubar-ed, потому что вы не распределили свою работу в память.
Теперь, если у вас есть два или более физических процессора (например, двухъядерный или более), и DDR3 RAM, то все в порядке. Пока вы не используете тяжелую графику, и в этом случае, если эта нагрузка вызывает ваши проблемы, updatedb будет последним в вашем списке. Если вы по какой-то причине пытаетесь замаскировать свои движения в системе, то есть другие способы, чем отключение updatedb, и на самом деле updatedb закрепит ваши действия так, что «ничего не произойдет», если замаскировать вашу систему.
Откровенно говоря, исходя из размера бинарного файла / usr / bin / updatedb и учитывая архитектуру обмена сигналами / системой с операционной системой, и то, что Bash в 10 раз превышает размер взаимно связанной черты оболочки или пепла, асинхронный вызов очень недорогой в системе.
Если вы вошли в оболочку, выполнив написанные вами последовательные сценарии, и вы являетесь администратором (например, sudo), выполните следующую команду:
~$ sudo bash
:~# ./script.sh
Тогда вы, вероятно, захотите создать локальную переменную в своем скрипте (для updatedb нужны системные привилегии, AKA root / sudo / wheel), например:
#! /bin/sh
# Create local variables
UPD="updatedb"
echo "Beginning Execution of sequence "
В этом случае последовательность использует STDOUT / STDIN из других сценариев оболочки, которые вы написали и выполняете как переменные в вашем основном сценарии, или говорите, что у вас настроен пакет для личного или бизнес-администрирования, куда вы загружаете / скачиваете / переносите из cdrom или usb или что-то еще, что очень велико, и для них есть персональные сценарии установки, ВЫ ХОТИТЕ ОБНОВЛЕНО Когда оболочка терминала открыта, это ваш основной экземпляр приложения. Другие приложения могут / действительно работают асинхронно, но updatedb является одним из наименее дорогих с точки зрения общей потребности системы / вычислений. Много раз, особенно с LXDM Desk Enviro и Lxterm (это очень быстро), но не только; без добавления updatedb в мои скрипты, система выдает мне ошибки, что файлы не существуют или что-то пошло не так. И я, как ЧТО!
Оболочка работает быстрее, чем система, которой она управляет. Я гарантирую это!
В этом случае вы должны вызвать переменную 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 по умолчанию установила «рекомендует» зависимости, а также «требует»).