LINUX.ORG.RU

locate + updatedb. Что за зверь и зачем нужен.

 , , , updatedb


1

1

Предыстория такая: просыпаюсь я как то в 6 утра на следующий день, после установки пары крупных пакетов в систему, и вижу что комп что то активно делает, хотя не должен. htop, читаю... А там updatedb, запущеный через хрон, пачками вызывает find и sort, и у каждого в качестве аргументов длиннющая строка с тоннами кавычек, экранирующих символов и кодов юникода. И полная неясность, что это и зачем. Неужели какая то вирусня оказалась прописана в хрон?

Чтение конфигов, скриптов и доков показало, что такая ежедневная задача действительно есть, похоже она действительно в составе дистрибутива и скрипт действительно написан таким странным образом. Вроде как есть команда locate (вообще не знал о такой), которая ищет файлы в системе по заготовленному индексу, а индексация по хрону раз в сутки.

Мне это не нужно, я предпочёл бы отключить индексацию и удалить индекс, у меня место на корне и ресурс microSD карты ограничены. Но вдруг это какой то ключевой компонент системных скриптов? Вдруг после отключения и/или удаления индекса у меня полезут косяки в системе когда я уже забуду об этой штуке? Кто нибудь знает что то об этом?

★★★★★

Если поиск не нужен можно смело отключать. Туда же и mandb

anonymous
()

★★★★★

впервые слышит про locate

facepalm.jpg

Удали просто это говно, если оно лично тебе не нужно.

anonymous
()
Ответ на: комментарий от bormant

гуёвый линуксоид

у тебя первая буква неправильная.

Ну и в любом случае это означает, что человеку на ЛОРе ловить нечего. Пусть этот сраный вантузоид на винфак валит!

anonymous
()
Ответ на: комментарий от anonymous

Обожаю этого анонима. Сидит на своём LFS и продрачивает каждый конфиг в /etc ежемесячно, зато система всегда в полном порядке.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Это означает, что Линуксом можно пользоваться годами и не знать про locate, что очень даже хорошо

Deleted
()
Ответ на: комментарий от kirill_rrr

Можно просто выключить updatedb.timer

Deleted
()
Ответ на: комментарий от greenman

Во-первых, find на SSD работает быстро, и locate теряет смысл. Во-вторых, locate по умолчанию сканирует весь корень, и если у тебя, например, зашифрован /home, а остальное нет, то список всех твоих секретных файлов будет в открытом доступе.

anonymous
()
Ответ на: комментарий от greenman

Да, делаю find. Даже на хардах. Я не люблю поиск по индексам.

kirill_rrr ★★★★★
() автор топика
~$ locate cowsay
bash: locate: command not found

Вроде где-то когда-то что-то слышал про эту штуку, но видимо сразу забыл за ненужностью.

MrClon ★★★★★
()
Ответ на: комментарий от anonymous

Во-вторых, locate по умолчанию сканирует весь корень

В начале 2010-ых, просто «обожал» Linux-дистрибутивы, в которых эта хрень включена по-умолчанию.

Ситуация: разработка ПО под железки, несколько наборов SDK с 3-4 миллионом файлов в сумме, HDD 5200 RPM, 12039 и эта хрень начинала индексацию.

Вспоминается как страшный сон.

P.S. скажи что за дистр-то? Страна должна знать где мейнтейнеры настолько упороты что включают эту хрень, потому что сами работают где-нибудь на macOS.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)

Это предок непомука. Можешь удалять.

boowai ★★★★
()
Ответ на: комментарий от MrClon

Видимо с чем-то притянулось и включилось.

EXL ★★★★★
()
Ответ на: комментарий от MrClon
$ cat /etc/debian_version 
9.6
$ ls -l /etc/cron.daily/mlocate 
-rwxr-xr-x 1 root root 538 Nov 13  2016 /etc/cron.daily/mlocate
xaizek ★★★★★
()
Ответ на: комментарий от EXL

У меня дебиан 8. Мне казалось, я вычистил все ненужные пакеты, но...

А по поводу производительности - я бы и не заметил никогда, если бы не нагрузка на cpu от sort. Судя по скрипту, у них сейчас самые жёсткие настройки приоритета idle.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от Moondancer

У меня важна только память и запись на корневой раздел, так что меня бы такая фоновая задача не напрягала. Для EXL были важны обращения к hdd. Если бы он победил 12039, то оно тоже могло бы не мешать.

Другое дело что сам по себе этот индеск - ненужная штука. Я при его удалении высвободил целых 9Мб, 1 пакет и ежедневную запись чего то на флэш-память.

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от anonymous

Так и вижу, как ты делаешь find на корне с суммарным размером в пару-тройку десятков терабайт!

список всех твоих секретных файлов будет в открытом доступе

И что? Содержимое их никто не будет знать. Ну и насрать, что будут знать, какие файлы у тебя есть!

anonymous
()
Ответ на: комментарий от anonymous

Че не так-то? Проверил, у меня так же копируется.

t184256 ★★★★★
()

Это для склеротиков, и ещё когда надо что-то отыскать в фс по имени не из PATH. В некоторых (или даже всех?) дистрибутивах - родом из пакета mlocate.

blexey ★★★★★
()
Ответ на: комментарий от anonymous

Так и вижу, как ты делаешь find на корне с суммарным размером в пару-тройку десятков терабайт!

Я конечно понимаю, что говнокодеры работают не покладая рук, но подвести размер корня к терабайту им пока не удалось даже при использовании самых современных инструментов виртуализации, контеризации, изоляции, snap, appimage, платформы electron и прочего.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от bormant

Неа, это шизик с одноплатником.

anonymous
()
Ответ на: комментарий от kirill_rrr

Я говорю о суммарном размере — со всеми примонтированными разделами.

Или ты будешь по экземпляру find на каждый раздел запускать (один для ~, один для /data, один для /www и т.п.?)

anonymous
()

ламер-недоумок, которому никогда не требовалось очень быстро вывести имена и пути.

откуда такие ватнузы берутся? пшёл нахрен с моего лора, животное!

хотя, что вы хотели от чела, с именем кириллллллллл. тормозззззз.

локейт уделает любой современный файнд по скорости выхлопа и не напряжности. то, что у некоторых даунов он адекватно не настроет - проблемы только этих, так называемых линуксоидов. с буквой й.

anonymous
()
Ответ на: комментарий от EXL

и эта хрень начинала индексацию.

она же это по ночам делает.

legolegs ★★★★★
()
Ответ на: комментарий от EXL

Хорошо, что сейчас есть быстрые SSD. На 500 Гб диске updatedb отработал за секунду только что.

aquadon ★★★★★
()
Ответ на: комментарий от anonymous

Да, потому что я не буду искать скажем музыку в скажем /usr/local/. Потому что её там нет и быть не должно.

rrr@raspberrypi:~$ time find /media/data2/ttemp/ | grep -i kotor
/media/data2/ttemp/KotOR_2
/media/data2/ttemp/KotOR_2/Setup-2.bin
/media/data2/ttemp/KotOR_2/Setup-1.bin
/media/data2/ttemp/KotOR_2/Setup-3.bin
/media/data2/ttemp/KotOR_2/Setup.exe
/media/data2/ttemp/KotOR_2/SW_KotOR_2_UE.txt

real    0m4.457s
user    0m0.095s
sys     0m0.215s

Это был кошмарный поиск по терабайту торрентов на usb2-hdd с помощью одноплатника. Аж целых 5 секунд. locate далбы мне коренное преимущество.

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от anonymous

Умный анонимус видимо делает updatedb каждый раз, когда где то в файловой системе создаётся новый файл. Ведь как же иначе, если ты постоянно теряешь файлы и даже предположить не можешь, где это могло бы лежать.

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

А теперь посмотри, сколько времени потратит locate на то же самое.

Ну и попробуй find'ом найти даташит в двухтерабайтной директории с несколькими сотнями миллионов файлов и поддиректорий!

updatedb работает ночью, так что никаких проблем не доставляет.

/media/data2/ttemp/KotOR_2/Setup.exe

Что гребаный вантузоид делает на моем ЛОРе?

anonymous
()
Ответ на: комментарий от anonymous

что делает на моем ЛОРе?
anonymous

Так вот кому принадлежит ЛОР на самом деле!

даташит в двухтерабайтной директории с несколькими сотнями миллионов файлов и поддиректорий

Батенька, похоже вам действительно нужна индексирующая база данных, причём уж точно не по именам а по содержимому. locate так не умеет.

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Не бывает индексирования по содержимому сканированных файлов. А распознавать их никто никогда не будет! Особенно когда это — тысячи даташитов...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.