LINUX.ORG.RU
решено ФорумAdmin

Debian Bookworm и updatedb - как посмотреть логи?

 , ,


2

2

Конечно сейчас набежится куча троллей, но нужна помощь.
Я пока так и не освоил journalctl и не понимаю как добыть нужные логи.

Есть Debian Bookworm, установлен по умолчанию. updatedb я не глушил. Шуршит каждый день, и стало интересно - сколько он шуршит по времени.

Ну значит прошу:
# journalctl -b -1|grep updatedb

В ответ - тишина.

Просто в #journalctl -b - прокорутил до 6:25, ни чего похожего не нашел.

В /etc/cron.daily есть locate - который запускает updatedb

Подскажите - где в дефолтном Дебиан искать логи updatedb?

****************************************
ПОССКРИПТУМ по результатам треда:
****************************************
ВХОДНЫЕ ДАННЫЕ:
Зоопарк из USB3 Винтов с ntfs и zfs:
2.5" 1T Transcend - ST1000LM035-1RK172
2.5" 2T Toshiba - TOSHIBA HDWL120
3.5" 1T Samsung - SAMSUNG HD105SI
3.5" 4T Toshiba - TOSHIBA MG04ACA400E
3.5" 4T Hitachi - HGST HUS726040ALE614

По отчёту: time locate /|wc -l >>updatedb.log
На всём этом живёт 41.508.070 файлов

locate к сожалению не ведёт логов. Ручной запуск обновления базы - дал следующие данные:

# time updatedb
real    680m24,601s
user    4m52,788s
sys     22m24,546s

База:
-rw-r--r-- 1 root root 717M апр 16 04:19 locatedb


По материалам треда - поставил plocate, просто:
# apt install plocate
Ручная индексация базы:
# time updatedb
real    111m52,880s
user    5m14,073s
sys     8m52,893s

База:
-rw-r----- 1 root plocate 935M апр 16 07:12 plocate.db

Да, есть проблемы с паматью и концентрацией, например сейчас сказал:
# locate /|wc -l >>updatedb.log

А надо было сказать: # time locate /|wc -l >>updatedb.log
Я понятия не имею - сколько оно ещё будет считать мои 35 миллионов файлов, и сколько потом это же будет считать plocate.
Пройдут часы, вернусь и дополню.

Вернулся. Как раз компьютер успокоился и не шуршит диском. Но переизмерять wc не стану. По прошлым подсчётам:
locate:
# time locate /|wc -l >>updatedb.log
real    38m58,342s
user    2m24,506s
sys     2m37,504s
41 508 070

т.е. список файлов он выводил 38 минут.

plocate:
# time plocate /|wc -l >>pupdatedb.log
real    99m16,560s
user    2m33,176s
sys     2m55,918s
41 508 070

Он работал аж 99 минут.

Решил упростить задачу. Есть у меня хостнейм: zer0 и в каких то бэкапах - везде это имя фигурирует в путях. Поищем его:

locate:
# time locate zer0|wc -l >>updatedb.log
real    0m12,923s
user    0m9,513s
sys     0m1,950s
598 320

Получется нашлось 600к вхождений этого слова в путях.

plocate:
time plocate zer0|wc -l >>pupdatedb.log
real    0m7,241s
user    0m5,916s
sys     0m1,328s
598 320

хотя на первом проходе он исполнил эту команду за 2:46

В целом plocate имеет преимущество лишь в скорости обновления базы, 111 минут вместо 680 у locate
При поиске, УВЫ! locate выигрывает, но этот выигрыш времени - ничтожен по сравнению с экономией времени создания индекса.

Вот такое получилось расследование инициированное желанием знать - сколько идёт индексация.

Спасибо всем позитивным помощникам, и жаль что я нагнал много оффтопика с тролями и хамами. В будущем постараюсь не отвечать подобным личностям и не портить тред, но могу забыть и не сдержаться.

★★★

Последнее исправление: n0mad (всего исправлений: 7)
journalctl -u cron.service

Это прям настолько сложно было? И по умолчанию там наверняка стоит rsyslog и есть обычный /var/log/cron.log, но это не совсем точно.

А locate лучше вообще удалить, бесполезная вещь, когда есть fd.

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

journalctl -u cron.service
Это прям настолько сложно было?

Да, я не знал этого.
Впрочем не помогло.
Там виден почему то только запуск /etc/cron.hourly
/etc/con.dayly ни разу не запускался, хотя я просил и -b -1, и -b -2, и -b -3

И по умолчанию там наверняка стоит rsyslog и есть обычный /var/log/cron.log, но это не совсем точно.

Нет там ни чего.

А locate лучше вообще удалить, бесполезная вещь, когда есть fd.

Погуглил, скачал, поставил. Как нибудь попробую. Интересно, как оно будет в сравнении с locate на 7T zfs

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

Нет, я про то, что locate не справится с задачей, если файл еще не будет внесен в базу. fd очень быстрый и не зависит от предварительной подготовки.

Имхо, вот эти все обновления данных по расписанию не стоят того. Раньше на медленных носителях это было оправдано. Возможно в вашем случае, 7T, тоже. Но нужно сравнивать.

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

Нет, я про то, что locate не справится с задачей, если файл еще не будет внесен в базу. fd очень быстрый и не зависит от предварительной подготовки.

Тем не менее «очень быстрый» не может быть быстрее скорости работы системы, а locate может.

Имхо, вот эти все обновления данных по расписанию не стоят того. Раньше на медленных носителях это было оправдано. Возможно в вашем случае, 7T, тоже. Но нужно сравнивать.

Почувствуйте разницу:

# time fd zer0 /
real    154m48,354s
user    2m6,685s
sys     10m33,021s

# time locate zer0
real    0m53,885s
user    0m21,235s
sys     0m2,985s

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

А у тебя locate или plocate используется?

Я же написал, то что Дебиан ставит по умолчанию.
Скорее всего locate

Но вообще стиранно что по теме топика - так решения и не нашлось. Мне не нужно обсуждать преимущество и недостатки систем поиска - МНЕ НУЖНО ТУПО ПОСМОТРЕТЬ ЛОГ ЭТОЙ ТВАРИ!
Неужели разработчики не предусмотрели логов? Или местная общественность просто не знает как посмотреть лог в современном дистре - поставленном с нуля?

Я хочу освоить инструменты просмотра логов. Нужели нигде updatedb не отмечает время старта и остановки?

Сейчас удаляю 2Т данных с беспонтового ЯДа. Иногда надо проверить есть ли локальные копии чего то. locate помогает. Отрабатывает за минуту, а не часами...

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

Разницу проверить не могу, нет [pm]?locate
Размер имеет значение

$ time fd zer0 /

real	0m0.564s
user	0m0.614s
sys	0m1.297s

$ df -h / /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  234G  8.9G  213G   5% /
/dev/nvme1n1p1  916G  174G  697G  20% /data

Но locate не справится с новыми файлами, это главный недостаток. Придется сначала делать updatedb

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

Почему ты думаешь что у updatedb есть логи?

По логике Линукса. Любое порядочное приложение - обязано вести журнал, и сейчас это централизованная подсистема....
Вот это убожество, стартануло в 6:30 и пока всё ещё работает find
Надо бы погасить комп, но это 10 часов тарахтения диском насмарку!

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

Первая ссылка в Гугле

Что?

https://forums.debian.net/viewtopic.php?t=157636

Мне нужен locate, а не plocate.
Ну фас фсех фпень! Пойду примитивным способом
Скрипт: date>log;updatedb.0;date>log и назову его updatedb
Вот он лог и сделает вместо этого ушлёпка updatedb.
А уж потом заряжу фсех локейтов по почереди и пусть тоже в лог пишут...

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

updatedb сам себя не запускает. Или руками или в пакете mlocate оно вроде в крон кладёт задачу.

Мне нужно знать когда он завершится. Ну ладно, пойдём примитивным способом. Пусть крон зовёт скрипт updatedb, он и будет писать в лог и запускать оригинальный updatedb.0
Я думал кто то здесь сможет показать кошерный способ. Стоит то дефолтный Дебиан и странно что такого там невозможно искаропки.
По идее каждый системный процесс - должен вести логи старта и остановки, иначе система получатся неанализируемая.

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

А чё париться? Почему никто не предложил? Залез в скрипт updatedb и прочитал!

# ls -l /var/cache/locate/
итого 623684
-rw-r--r-- 1 root root 638641974 апр 14 12:25 locatedb
-rw-r--r-- 1 root root 0 апр 14 23:58 locatedb.n

Зная что крон запускает в 6:25 мы как ни странно - получаем ровно 6 часов работы...
А locatedb.n это новый, который сейчас пилится из скрипта с таймстампами. Посмотрим что случится в 6:25. Отработает этот экземпляр или нет.

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

просто запусти в консоли time updatedb

И такая мысль была, но хочу лог! Мне просто хотелось найти логи в системе, жаль что это не продумано.
Но забавно, индекс 8Т данных, занимает 640Мб.

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

Насколько я помню он не пишет никаких логов, молча обновляет бд, крон так же не пишет логов что он там запускает, максимум логирует вывод, которого у updatedb нет. Так что в твоем случае никаких логов нет.

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

Хотя что-то пишет, а ты запускаешь journalctl -u cron.service c sudo?

От рута :)
но самое интересное что фигурирует лишь:
(root) CMD (cd / && run-parts --report /etc/cron.hourly)

dayly отсуствует.

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

Как я вижу updatedb в моем дебиане trixie запускается через locate.timer

Да пофигу, ща ещё разок-другой запустится. Проверю стабильность времени исполнения и накачу plocate, благо всего то
#apt install plocate

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

Он просто агрессивное быдло.

Алсо, напишите им Копирасты охренели кто-нибудь уже, что кавычки из запроса надо убрать. Сами ж просили чтоб гугл синтаксис воспринимал, теперь жалуются.

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

А есть сервис вообще? sudo systemctl status locate.service

Зачем? Он же через cron пускается...

# sudo systemctl status locate.service
Unit locate.service could not be found.

Спасибо за акцент, а то тут предлагают, я исполняю, а такого сервиса и нет в Дебиане.

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

Мне нужен locate, а не plocate.

А чем plocate не угодил?

Тем что разработчики Debian Bookworm - дефолтом ставят locate, он и стоит. Задолбал пилить диск. Хотел узнать, сколько он вообще этим занимается каждый день. Узнал что в дефолтной настройке - этого узнать НЕВОЗМОЖНО. Соответственно надо сначала замерить время пиления, а потом заапгрейдить на plocate.
Но косяк-с вышел. Вручную запустил в 23:58 и потом косвенно выяснил что ему это делать, как минимум 6 часов, а следующий кронзапуск в 6:25.
Сейчас 09:00 - ПИЛИТ!
Всё ещё тот, запущеный в 23:58
Но не понятно, почему из /etc/cron.dayly/..... УПС! ЗАГЛЯНУЛ!
Он пускает напрямую /usr/bin/updatedb.findutils а не цепочку симлинков начиная с /usr/bin/updatedb - потому и не будет ни каких логов при использовании моего хака.

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

Спасибо. Было интересно узнать, как там в букворме. Есть/нет сервиса. В трикси тоже есть крон-скрипт в daily, но он запускается из systemd, а из крона игнорируется

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

«Факир был пьян» :(
Исполнил: # time updatedb
И эта тварь опять в 2х экземплярах...

# ps ax|grep update
 556672 pts/4    S+     0:00 /bin/sh /usr/bin/updatedb
 556680 pts/4    S+     0:00 /bin/sh /usr/bin/updatedb
 556715 pts/5    S+     0:00 grep update

Опять будет шуршать пятью винтами...
А в 6:25 крон исполнит /bin/updatedb.findutils

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

Посмотрел его прошлые треды..

Как узнать время работы команды cd?

Думаю что хватит его кормить.

Зачем хамить? Я обращаюсь за помощью, а тут вылезают хамы с предложением: «хватит ему помогать».
Порядочные люди, в отличии от тролей и хамов - помогают.
Я теперь знаю про plocate.
И в этом треде в итоге я озвучу итоги сравнения locate и plocate
locate вот уже более 8 часв шуршит дисками, и надеюсь успеет до 6:25, до крона.

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 5)