В Linux есть масса утилит, для поиска файлов. К примеру всем известный монструозный find, который умеет даже тапочки приносить.

Но что, если мне нужно просто найти какой-то файл? Использовать find для такой простой задачи, это явно стрельба из пушки по воробьям. Для таких задач, как моя, есть более изящные решения.

И это решение, утилита locate.

Утилита locate используется для поиска файлов, расположенных на машине пользователя или на сервере. Фактически она выполняет ту же работу, что и команда find, однако, ведёт поиск в собственной базе данных.

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

Обновление базы данных locate происходит автоматически, как правило, раз в сутки. Либо можно запустить руками командой updatedb.

Давай теперь потыкаем, запускай:

locate txt

Ищем все файлы, имена которых содержат «txt». Опа, меньше чем за секунду команда нашла все подходящие файлы, которые можно было найти. А если сделать это через find, то это у меня это заняло 18 секунд. Разница очень ощутимая.

Ищем файлы, которые оканчиваются на «txt»

locate '*txt' 

А теперь давай посчитаем общее количество файлов, которые нашлись

locate -ic '*txt' 

Ключ -i = режим регистронезависимости
Ключ -с = вывести общее количество найденных файлов

Полезли в кишки, заводим strace.

Переходим в папку cd /tmp и создаем подопытный файл: > hello.txt

Знал же что пустой файл можно создать через символ «>»? Если нет, то теперь знаешь.

Так, я нахожусь в папке tmp и у меня создан файл hello.txt запускаю:

locate *txt

Опа, ничего нет, как так? Мы же уже запускали ранее это, чтобы найти все файлы, которые заканчиваются на txt. Что случилось?

Мы вызываем внешнюю команду locate, но вызываем мы ее из интерпретатора bash. Вернее её вызывает сам интерпретатор. И это накладывает свои нюансы. В нашем случае этот нюанс «Подстановка имен файлов», то есть Globbing.

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

Во времена UNIX V6, существовала программа /etc/glob, которая могла раскрывать шаблоны подстановки. Очень скоро она стала встроенной функцией командной оболочки.

Но что же случилось то в итоге, почему ничего не нашлось? А произошло следующее: после того, как интерпретатор обнаружил символ «*», который является спецсимволом и соответствует любой строке, интерпретатор попытался сделать подстановку Globbing и ему это удалось.

И при вызове команды locate она получила в качестве аргументов, результат этих подстановок. Давай посмотрим наглядно что произошло. Запускаем:

strace -e execve locate *txt 

На выходе получаем:

execve("/usr/bin/locate", ["locate", "hello.txt"], 0x7ffe242252d8 /* 27 vars */) = 0

Опция «e» и аргумент «execve» сообщают strace, что я хочу отслеживать только системные вызовы «execve».

execve() выполняет программу, заданную параметром filename

Возвращаемся к выводу от strace и видим что locate получила в качестве аргумента hello.txt

И теперь locate будет искать файлы именно по этому шаблону, а не по тому, что мы с тобой ожидали, когда писали «*txt».

Вот лишь по этому на экран ничего не вывелось, когда я запустил locate *txt

А чтобы этого не происходило всегда используй quoting (кавычки) и будешь получать ожидаемый результат.

locate '*txt' 

Механизм подстановки имен файлов (Globbing) на самом деле удобен, просто нужно использовать его по назначению.

Если ты это усвоил, то уже не наступишь на грабли. Да и strace снова немного затронули, можешь применять для дебага и смотреть что происходит внутри, после вызова той или иной команды.

Поигрались и хватит. Пошли дальше работу работать. Всех был рад видеть, пока-пока!

tags: #bash #strace #debug
—
💩 @bashdays

Service или Systemctl?

Каждый стартует или стопает процессы как привык. Во времена динозавров когда еще не существовало systemd, всё сводилось к командам:

service apache restart

Сейчас мир изменился, появился systemd, но привычки остались прежними.
ㅤ
Теперь сервисами рекомендуется управлять через systemctl.

Но какая в хуй разница как управлять сервисам?

И service и systemctl выполняют по сути одно и тоже и ты по итогу получаешь ожидаемый результат.

На самом деле сейчас команда service это обёртка вокруг systemctl.

Давай убедимся:

strace -f service nginx restart 2>&1 | grep execve

По итогу ты получишь:

execve("/usr/bin/systemctl", ["systemctl", "restart", "nginx.service"])

То есть service обратился к systemctl и произвел перезапуск nginx.

А если глянуть исходник service:

cat /usr/sbin/service

То ты увидишь обычный bash скрипт в котором и происходит вся эта магия.

Если система использует SysVinit или Upstart (например, старые версии Debian, CentOS 6, Ubuntu 14.04), то service будет работать напрямую со скриптами /etc/init.d/.

По бест-практикам старайся использовать systemctl. Но опять же service никто не запретит тебе использовать.

Хотя когда молодые ребята видят как ты вводишь service, у них разрывает жопу и ты автоматически присваиваешь себя к престарелым скуфам.

Как это делаю я? И так и сяк, мне вообще похуй, главное достигнут ожидаемый результат.

Кроме systemctl и service есть такие штуки для управления процессами:

/etc/init.d/nginx restart
rc-service nginx restart
sv restart nginx
s6-rc -d change nginx
supervisorctl restart nginx

А чтобы проверить какая система инициализации у тебя, вот тебе пиздатая команда:

ps -p 1 -o comm=

Вот и вся наука.

А как ты рулишь сервисами? Как скуф или как современный молодой человек?

tags: #linux #debug #strace
—
🔔 @bashdays➡️ @gitgate

Если ты выполняешь план, то тебе повысят план, а не зарплату!

Пытался вчера подружить taskwarrior и s3 для синхронизации, из коробки оно вроде как только с AWS работает.

Подкинул в конфиг параметры подключение к кастомному хранилищу. Ну думаю, какая в хуй разница.

sync.backend=s3
sync.aws.region=ru-7
sync.aws.bucket=taskwarrior
sync.aws.access_key_id=aed38518013b4ab
sync.aws.secret_access_key=992570bad57
sync.aws.endpoint=s3.ru-7.storage.selcloud.ru

Проверяю task sync init, хуй там плавал, ошибка:

unhandled error: dispatch failure: io error: error trying to connect: dns error: failed to lookup address information: Name or service not known: dns error: failed to lookup address information: Name or service not known: failed to lookup address information: Name or service not known

Мде… Всёж правильно, эндпоинт пингуется, курлится, телнетится. Описывать весь момент дебага не буду, но там конкретный такой - метод тыка был.

Ну раз обычный «метод тыка» не помогает, расчехляем strace!

strace -s 200 -f -e trace=network,connect,sendto,recvfrom task sync

Что делает команда:

-s 200 — печатать до 200 байт строковых аргументов (по умолчанию strace режет строки до 32 байт). Это важно, чтобы увидеть полный URL/hostname, который передаётся в syscalls.

-f — следить не только за основным процессом, но и за всеми дочерними (fork/clone)

-e trace=network, connect, sendto, recvfrom — ограничиваем вывод только сетевыми вызовами: socket, connect → создание сокетов и подключения (TCP/UDP). sendto / recvfrom → передача данных (обычно видно DNS-запросы, HTTP-заголовки и т.д.).

И в выхлопе находим строчку: taskwarrior.s3.ru-7.amazonaws.com.

😀😃😄😁😅😂🤣😊
😇🙂🙃😉😌😍🥰😘
😗😙😚😋😛😝😜🤪
🤨🧐🤓😎🤩🥳😏😒
😞😔😟😕🙁☹️😣😖
😫😩🥺😢😭😤😠😡

Ну ёб твою мать! А нахуй я тогда все эти приседания с конфигом устраивал, если эта падла хуй положила и по task diagnostic никаких ошибок не вывело.

То есть настройка sync.aws.endpoint=… вообще не учитывается — клиент жёстко строит URL по схеме AWS.

Ну хоть проблему нашли. Strace все же достаточно пиздатый инструмент.

Отсюда вывод: с кастомным S3 напрямую taskwarrior работать не сможет. Даже если устроить подмену хостов или сделать хак через CNAME.

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

Хороших тебе выходных!

🛠 #strace #debug #taskwarrior
—
✅ @bashdays ✅ @linuxfactory ✅ @blog