Все знают команду date для работы с датами/временем.

🔤🔤🔥🔤🔤🔤🔤

Очень удобная команда, имеет очень много форматов и позволяет складывать/вычитать даты, например:

date -d"-1 day" # Чт 02 янв 2025 21:52:15 MSK - текущая дата минус один день.
date -d"+2 week" # Пт 17 янв 2025 21:53:48 MSK - текущая дата плюс две недели.
"day", "week" "month", "year", "hour", "min", "sec"

Но в bash есть еще средства для работы со временем:
ㅤ
Переменная SECONDS показывает, сколько секунд прошло с начала запуска скрипта или момента задания значения переменной. Обычно используется для хронометража блока кода скрипта. Например:

SECONDS=0
# здесь блок длительного кода
echo $SECONDS

Переменная EPOCHSECONDS - показывает число секунд, прошедших с начала эпохи UNIX (01.01.1970 00:00:00 UTC).

Обратите внимание, число секунд не зависит от часового пояса.

EPOCHREALTIME - аналогична предыдущей, но секунды с точностью до микросекунды. С помощью этой переменной можно точно отслеживать время небольших кусков кода. Даже если просто вывести переменную дважды - будет разное время:

echo $EPOCHREALTIME $EPOCHREALTIME
# 1744652451,166523 1744652451,166539

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

Переменные EPOCHSECONDS и EPOCHREALTIME обнулить не получится.

И еще есть специальный формат оператора printf для преобразования секунд UNIX в формат дат:

printf '%(DT_FORMAT)T' $EPOCHSECONDS

DT_FORMAT - практически полностью совпадает с форматом команды date.

Например:

printf '%(%Y%m%d-%H%M%S)T' $EPOCHSECONDS
# 20250414-203214

Если не указать переменную или указать -1 - будет использовано текущая дата/время. Если указать -2 - будет использовано время начала работы этого экземпляра bash.

printf удобен тем, что выполняется гораздо быстрее чем date (хотя говорить о скорости bash немного смешно) и позволяет результат операции записать сразу в переменную (Например DT).

printf -v DT '%(%Y%m%d-%H%M%S)T'

И date и printf работают в локальной временно́й зоне, чтобы это изменить можно задать "врéменную переменную" TZ.

Например:

TZ='UTC' date
# Пн 14 апр 2025 16:15:57 UTC

TZ='Asia/Irkutsk' printf '%(%Y%m%d-%H%M%S)T\n'
# 20250415-001621

Полный список временны́х зон на системах с systemd можно получить с помощью команды timedatectl list-timezones.

🛠 #bash
—
✅ @bashdays / @linuxfactory / @blog

Всё тебе, блядь, смехуюшечки да пиздахаханьки.
ㅤ
Создаём файл:

echo -e "foo\nbar\nfoo again" > bashdays.txt

Внутри получаем:

foo
bar
foo again

И применяем бэд-практику:

cat bashdays.txt | sed 's/foo/baz/g' > bashdays.txt

Эта команда читает файл bashdays.txt и одновременно пишет в него.

Что тут не так?

А всё! В лучшем случае получишь хуем по лбу и примеришь золотой пизды колпак. Эта команда испортит файл. Низя так делать! Всё проебёшь!

После этой команды файл bashdays.txt обнулится. Хотя визуально команда выглядит абсолютно безопасной.

А теперь делаем правильно!

sed 's/foo/baz/g' bashdays.txt > tmpfile && mv tmpfile bashdays.txt

Смотрим содержимое файла bashdays.txt и видим ожидаемый результат:

baz
bar
baz again

Здесь мы всё сделали через временный файл, громоздко, но по крайней мере безопасно. Веселый колпак тебе теперь точно не светит.

Можно извратиться и провернуть всё это дело на основе дескрипторов, но опять же этот способ не безопасен.

Можно правда хакнуть таким методом:

printf '%s\n' ',s/foo/baz/g' w q | ed -s bashdays.txt

Это работает без временного файла на уровне Bash, потому что ed сделаем всё сам. Но опять же конструкция нихуя непонятная.

Резюмируем: Не ссы использовать временные файлы, пусть твои bash скрипты будут безопасны и читаемы.

🛠 #bash #badpractices #bestpractices
—
✅ @bashdays / @linuxfactory / @blog

Нежных много, деловых мало. Ну не могу я из песни слов выбросить, получится сухо и не интересно.
ㅤ
Поэтому нарушать традиций не будем, продолжаем в том же ключе. А нежные пусть идут на... ну ты понял.

Рассмотрим распространённый случай:

echo $foo

Тут всё предельно ясно и понятно. Все в ажуре!

Но это вершина айсберга. Эта команда может отрабатывать не так, как ты ожидаешь. Потому что foo это переменная. И если ты её не возьмешь в кавычки, то Bash может сделать с её содержимым всякие хитрые штуки.

Что подразумевается по «хитрыми штуками»

— Разделить содержимое на отдельные слова (если там есть пробелы).

— Подставить имена файлов с таким шаблоном, если он выглядит как *.zip (это называется глоббинг).

И тут у новичков возникает многочасовой проёб, когда переменная выводит неправильные значения.

Смотри:

msg="Пожалуйста, введите имя файла в формате *.zip"
echo $msg

Выглядит опять всё красиво. А по факту получаешь:

Пожалуйста, введите имя файла в формате awscliv2.zip

Да блядь! А я просто хотел вывести строкой *.zip а не получить список файлов в текущей папке.

var="*.zip"
echo "$var"
echo $var

Первое echo напечатает *.zip, а второе выведет список всех файлов, которые заканчиваются на .zip.

Поэтому, если ты хочешь наверняка вывести переменную как есть, лучше используй `printf`

printf "%s\n" "$foo"

Для маленьких:

Представь, что ты говоришь падшей женщине: «покажи что у тебя в трусах», она снимает трусы, а там — большой сочный хуй.

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

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

Такие дела. Изучай!

🛠 #bash #badpractices #bestpractices
—
✅ @bashdays / @linuxfactory / @blog

Живу в лесу, поклоняюсь колесу…
ㅤ
А чё эта хуйня не работает? Яж всё правильно сделал!

su -c 'ls -la'

С виду всё верно. Но если внимательно прочитать команду и подумать, происходит такое:

Хочу стать root и выполнить команду ls -la.

Но у su другое мнение:

Хочу стать пользователем с именем -c

А -c — это не имя пользователя, а опция.

Поэтому правильно так:

su root -c 'ls -la'

Теперь логика не хромает:

Перейти к пользователю root и выполнить команду ls -la.

Вроде мелочь, а на эти грабли постоянно наступают и бегут — аа, у меня принтер не печатает!!! Что я делаю не так???

А чем отличается su от sudo я писал тут, почитай на досуге и обнови нейронные связи.

🛠 #bash #badpractices #bestpractices
—
✅ @bashdays / @linuxfactory / @blog

Сегодня будем собирать "сливки на молоке". Поговорим немного об оптимизации bash по времени исполнения.

🔤🔤🔥🔤🔤🔤🔤
ㅤ
Все помнят, что есть команда time, которая с точностью до 1e-3 может подсчитать время выполнения конвейера.

Для перфекционистов, вроде меня, есть переменная EPOCHREALTIME, которая выдает текущее время в системе с точностью до 1e-6, т.е до микросекунды.

Но для ее использования есть два препятствия:

1. Она в вещественном формате, а bash не работает с вещественными числами.

2. Разделитель дробной части зависит от языковых настроек. (где-то точка, где-то запятая...)

Попробуем решить эти проблемы. Простая функция. Вычисляет разницу RealTime2-RealTime1 в микросекундах. Если RealTime2 не задана - принимается EPOCHREALTIME.

#uTIME RealTime1 [RealTime2]
function uTIME(){
  local T2=${2:-$EPOCHREALTIME}
  local T1=${1:-$T2}
  T2=${T2/[^0-9]/} ;T1=${T1/[^0-9]/}
# ((T2-T1)) &&  \
  echo $((T2-T1))
}

Ну и теперь, вооружившись инструментом, попробуем использовать на практике:

1. Сравним время выполнения двух функций B1 - исполняется в текущей среде, B2 - исполняется в subshell

2. Сравним преобразование числа в дату с помощью date и printf

#!/bin/bash
function uTIME(){
  local T2=${2:-$EPOCHREALTIME}
  local T1=${1:-$T2}
  T2=${T2/[^0-9]/} ;T1=${T1/[^0-9]/}
# ((T2-T1)) &&  \
  echo $((T2-T1)) 
}

function B1(){ :;}
function B2()(:)

uTIME

echo -n 'function {} = '
T=$EPOCHREALTIME
B1
uTIME $T

echo -n 'function () = '
T=$EPOCHREALTIME
B2
uTIME $T

echo -n 'printf -v VAR "%(%Y%m%d)T" 1746024063 = '
T=$EPOCHREALTIME
printf -v VAR "%(%Y%m%d)T" 1746024063
uTIME $T

echo -n 'VAR=$(date -d@1746024063) = '
T=$EPOCHREALTIME
VAR=$(date -d@1746024063 +%Y%m%d)
uTIME $T

0
function {} = 106
function () = 2533
printf -v VAR "%(%Y%m%d)T" 1746024063 = 405
VAR=$(date -d@1746024063) = 5221

Обратите внимание - результаты отличаются на порядок.

Конечно, в реальных случаях использования, скорее всего, результаты будут отличаться меньше, но есть смысл задуматься. Особенно, если Вы будуте использовать функции во внутреннем цикле.

Первый (пустой) вызов uTIME нужен потому, что первый вызов функции всегда выполняется дольше, чем последующие. Если кого-то напрягает "0" на экране при инициализации - раскомментируйте строчку # ((T2-T1)) && \

Если нужно засечь время выполнения в контрольных точках - используйте массив:

RT+=($EPOCHREALTIME)

В при каждом исполнении этого оператора в массив будет добавляться время контрольной точки. Время исполнения между точками можно будет вычислить как

uTIME ${RT[N]} ${RT[N+1]}

Исследуйте bash, оптимизируйте, развивайтесь.

🛠 #bash
—
✅ @bashdays / @linuxfactory / @blog

Я тут недавно игрушку написал. Ну, как написал, реализовал.

🔤🔤🔥🔤🔤🔤🔤

Вариант 2048, оптимизированный по занимаемому экранному пространству.

➡️ Ознакомиться с игрушкой можно здесь.

Но у нас тут люди серьезные, поэтому рассмотрим проблемы, возникающие при реализации вывода скриптов.

Простой пример:

for i in {1..100};do
  printf "#"
  sleep .3
 done

Код просто выводит символы #, примерно 3 штуки в секунду. Все работает нормально, пока пользователь не начинает что-то набирать на клавиатуре.
ㅤ
И тогда получаем:

######sb#sf#bg#sfbg#wfgb#wg#fg#b###^[[A#^[[B#^[[D#^[[A#^[[B##

Убрать эхо вывода на терминал просто:

stty -echo

Классная команда. После ее выполнения нажатые клавиши не отображаются.

Все работает, команды выполняются, результат отображается, а набранная команда — нет. Как при наборе пароля.

Вернуть все просто:

stty echo

Но в скриптах желательно обрабатывать прерывания:

trap 'exit' INT HUP TERM
trap 'stty echo;tput cnorm' EXIT
# stop terminal echo
stty -echo
#hide cursor
tput civis

Применять исключительно для причинения добра.

man stty
man tput
help trap

🛠 #bash #linux #games
—
✅ @bashdays / @linuxfactory / @blog

Почему в юнитах не работает Environment.

Сразу пример:

[Service]
Environment="FOO=bar"
ExecStart=/bin/bash /usr/local/sbin/bashdays.sh

Сделал юнит, но в скрипт bashdays.sh не передаётся переменная FOO. Хотя логически всё правильно.

Тут снова приколы.

➡️ 1. Скрипт запускается не напрямую, а через интерпретатор.

Если в ExecStart указан скрипт с shebang’ом (#!/bin/bash), systemd запускает его как отдельный процесс, и переменные окружения передаются.
ㅤ
Но если ты укажешь в ExecStart сам интерпретатор, вот так:

ExecStart=/bin/bash /usr/local/sbin/bashdays.sh

То переменная FOO, заданная через Environment=, не попадёт в подскрипт, потому что ExecStart запускает bash, а уже bash запускает — скрипт, и переменные окружения само собой нихуя не передаются.

Как правильно?

Вот так:

[Service]
Environment="FOO=bar"
ExecStart=/usr/local/sbin/bashdays.sh

А сам скрипт:

#!/bin/bash

echo "FOO is $FOO"

Всё! Теперь переменная из юнита будет корректно передаваться в скрипт.

➡️ 2. Использовать EnvironmentFile=

Если у тебя дохуя переменных, то выносим их в отдельный файл, например сюда /etc/bashdays-service.env.

FOO=bar
BAZ=qux

А в самом юните прописываем:

[Service]
EnvironmentFile=/etc/bashdays-service.env
ExecStart=/usr/local/sbin/bashdays.sh

Всё! Теперь переменные считываются из файла и скрипт их видит.

➡️ 3. Передавать переменные прямо в ExecStart

[Service]
ExecStart=/bin/bash -c 'FOO=bar exec /usr/local/sbin/bashdays.sh'

Тут особо и комментировать нечего, всё очевидно.

Как отладить и задебажить?

А вот так:

systemctl show nginx

Вместо nginx подставляешь свой сервис и наблюдаешь все переменные которые передались. В наших примерах увидишь Environment=FOO=bar.

Справедливо не только для собственных юнитов, но и для других, например для того же nginx или docker.

Как вариант, можешь добавить в скрипт такую хуйню:

env > /tmp/env.log

И смотришь, какие переменные реально передаются в твой скрипт.

Еще одна база выдана, вроде очевидные вещи, но так глубоко в это никто не лезет. Пользуйся.

🛠 #linux #tricks #debug #systemd #bash
—
✅ @bashdays / @linuxfactory / @blog

Три скрытых героя systemd

А вот и сами герои: timer, path и socket

Это невидимые юниты systemd, которые могут заменить cron, inotify`и даже `xinetd.

➡️ 1. Timer

Про timer ты наверняка слышал. Это альтернатива crontab. Позволяет запускать сервис по расписанию. Вместо того чтобы писать крон-джобы, ты создаёшь .service и .timer.

Пример:

/etc/systemd/system/backup.service

[Unit]
Description=Backup job

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup.sh

/etc/systemd/system/backup.timer

[Unit]
Description=Run backup daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Активируем:

sudo systemctl enable --now backup.timer

Persistent=true гарантирует запуск пропущенной задачи, если система была выключена.

Всё! Никаких тебе легаси кронтабов, все работает на юнитах, запускается бэкапилка, тикает таймер.

➡️ 2. Path

Работает как inotifywait или File Watcher: следит за файлами/папками и запускает сервис при изменении.

Пример:

/etc/systemd/system/upload.path

[Unit]
Description=Watch upload folder

[Path]
PathModified=/var/www/bashdays/upload
Unit=process-upload.service

[Install]
WantedBy=multi-user.target

/etc/systemd/system/process-upload.service

[Unit]
Description=Process uploaded files

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/process-upload.sh

Теперь каждый раз когда в папке /var/www/bashdays/upload что-то меняется, автоматически запускается скрипт process-upload.sh.

Тут уже от твоих предпочтений зависит, как и с чем это скрещивать, но кейсов можно придумать довольно дохуя. Например, проверка антивирусом, или запуск какого-нибудь ffmpeg.

➡️ 3. Socket

Заменяет ручной systemctl start, активируя сервис при первом подключении к сокету. Аналог inetd/xinetd
ㅤ
Нихуя не понятно, но на примере сейчас всё прояснится.

Пример:

/etc/systemd/system/echo.socket

[Unit]
Description=Echo socket

[Socket]
ListenStream=12345
Accept=yes

[Install]
WantedBy=sockets.target

/etc/systemd/system/echo@.service

[Unit]
Description=Echo service

[Service]
ExecStart=/usr/bin/nc -l -p 12345 -e /bin/cat
StandardInput=socket

В примере, сервис НЕ работает постоянно, он стартует, только когда кто-то подключается к порту 12345.

Когда ты используешь .socket с Accept=yes, systemd открывает сокет сам и ждёт подключения. А когда подключение приходит — создаёт новый экземпляр сервиса, подставляя туда данные об этом соединении. После завершения — сервис умирает. Всё очень экономно и прозрачно.

Как понять, какой экземпляр стартует?

systemd запускает echo@<ID>.service, где <ID> — уникальный идентификатор подключения (например, PID или номер сокета).

journalctl -u echo@*

Зачем нужны скрытые юниты?

1. Не нужен cron, всё централизовано в systemd.
2. Не нужен inotify-tools.
3. Сервисы не висят без дела, запускаются только когда нужно
4. Журналирование через journalctl

Вот такие пироги. В повседневной работе я применяю timer и path, с сокетами как-то сильно не приходилось париться.

Ну а ты попробуй хотя бы перетащить свои кронджобы в timer и порадоваться бест-практикам.

🛠 #linux #tricks #debug #systemd #bash
—
✅ @bashdays / @linuxfactory / @blog

Продолжаем ковырять systemd

Для того чтобы потыкать systemd не обязательно обладать рутовскими правами или судой-мудой. Да, ты не ослышался, всё можно запускать под обычным юзером.

Делается это так:

systemctl --user enable bashdays.timer

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

Эта штука создаёт символическую ссылку в ~/.config/systemd/user/ в директории default.target.wants/

Если тебе нужно разово запустить такой юнит, то enable меняем на start. Вот и вся наука.

А как отлаживать?

➡️ 1. Сначала нужно убедиться что таймер активен:

systemctl --user status bashdays.timer

Если всё ок, то увидишь Active: active (waiting).

➡️ 2. Смотрим расписание запуска

systemctl --user list-timers

- NEXT — когда следующий запуск
- LEFT — сколько осталось времени
- LAST — когда запускался в прошлый раз
- UNIT — имя таймера

➡️ 3. Проверяем выполнялся ли сервис

journalctl --user-unit bashdays.service --since "1 hour ago"

Команда покажет логи выполнения скрипта. Можно сузить диапазон, например так:

journalctl --user-unit bashdays.service --since today

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

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

🛠 #linux #tricks #debug #systemd #bash
—
✅ @bashdays / @linuxfactory / @blog

Продолжаем разбирать systemd на кирпичики. Сегодня про кандишены (условия/ситуации).
ㅤ
Директива ConditionPathExists используется в юнит-файлах systemd и позволяет задать условие для запуска юнита: он будет запущен только если указанный файл или директория существует.

Пример:

[Unit]
Description=Special Service
ConditionPathExists=/etc/bashdays-config

[Service]
ExecStart=/usr/local/bin/bashdays-handler

Этот юнит не запустится, если файл /etc/bashdays-config не существует. В статусе сервиса ты увидишь:

ConditionPathExists=/etc/bashdays-config was not met

Если путь НЕ существует, systemd не будет запускать юнит. Вместо этого он будет считаться пропущенным (skipped), а не проваленным.

Нахуя это надо?

1. Например, если bashdays-config существует, запускается сервис с особым поведением.

2. Можно создавать один юнит, который активируется только при наличии определённого модуля или плагина.

3. Иногда это используют в early boot-юнитах, чтобы запускать их только если что-то доступно (например, том LUKS).

Список основных Condition's (нажми на спойлер)

ConditionPathExists — файл или каталог существует
ConditionPathIsDirectory — путь существует и это каталог
ConditionPathIsMountPoint — путь является точкой монтирования
ConditionFileIsExecutable — файл существует и он исполняемый
ConditionKernelCommandLine — есть ли параметр ядра с указанным значением
ConditionPathExistsGlob — совпадает ли хотя бы один путь по glob-шаблону
ConditionPathIsSymbolicLink — является ли путь символической ссылкой
ConditionFileNotEmpty — существует ли файл и не пуст ли он
ConditionEnvironment — установлена ли переменная окружения
ConditionArchitecture — архитектура CPU (например, x86_64, aarch64)
ConditionVirtualization — nип виртуализации (например, kvm, docker)
ConditionHost — имя хоста
ConditionMachineID — cовпадает ли machine-id
ConditionControlGroupController — есть ли указанный cgroup controller (например, cpu, memory)
ConditionNeedsUpdate — нуждается ли в обновлении (/usr или /etc)
ConditionFirstBoot — Первый ли это запуск после установки
ConditionACPower — Подключено ли питание от сети (для ноутбуков)
ConditionSecurity — Активен ли определённый LSM (например, selinux)
ConditionUser — Запускается ли от указанного пользователя
ConditionGroup — Запускается ли от указанной группы
ConditionCapability — Имеет ли процесс определённую capability
ConditionNetwork — Есть ли сеть (online, configured)
ConditionMemory — Есть ли минимум указанного объёма памяти

Дополнительно

Если заменить Condition на Assert, условие не выполнено — юнит считается проваленным, а не пропущенным.

То есть берем к примеру директиву ConditionPathExists и меняем её на AssertPathExists.

AssertPathExists=/etc/bashdays.conf

И получается:

ConditionPathExists — юнит пропускается (не считается ошибкой)

AssertPathExists — юнит падает (считается ошибкой)

Assert полезен, когда ты строго требуешь, чтобы ресурс (например, внешний диск, NFS, или другой том) был смонтирован перед запуском сервиса. Если его нет — это ошибка, а не «ну и похуй».

[Unit]
Description=Start backup script only if /mnt/backup is mounted
AssertPathIsMountPoint=/mnt/backup

[Service]
ExecStart=/usr/local/bin/backup.sh

Если /mnt/backup не смонтирован, systemd выдаст ошибку, и сервис не запустится.

Статус будет такой:

systemd[1]: Starting backup.service...
systemd[1]: backup.service: Failed with result 'assert'.

Ну и все это дело можно комбинировать:

ConditionPathExists=/mnt/backup
AssertPathIsMountPoint=/mnt/backup

Если /mnt/backup не существует — юнит пропускается.

Если существует, но не смонтирован — юнит заваливается.

Короче systemd не такой уж простой, как кажется с первого взгляда. На нём можно прям заебись логику построить и получить желаемое. Так что недооценивать его явно не стоит, это прям заебись комбайн.

🛠 #linux #tricks #debug #systemd #bash
—
✅ @bashdays / @linuxfactory / @blog

Всем привет. Опять решил поделиться опытом своих провалов.

🔤🔤🔥🔤🔤🔤🔤

Вобщем, как-то раз я решил написать самоучитель по bash.

По традиции все учебники либо в html, либо в pdf. Я решил остановиться на pdf. Я начал писать в libreoffice, там есть экспорт в pdf. Пока писал - познакомился с markdown. И вдруг подумалось, markdown - такой классный, напрямик можно в гитхаб запихнуть. И в pdf конвертнуть с помощью pandoc можно. Вобщем, решил верстать в markdown.
ㅤ
Для начала познакомился с редакторами, которые умеют подсвечивать markdown (pluma, mousepad, geany) Вобщем, жить можно, но подсвечивается не всё.

После этого попробовал Apostrophe. Он уже умеет дополнительно показывать результат. Но работает медленно. Особенно на больших документах.

В общем - перепопробовал, - не нравится. Решил писать в mousepad, а потом конвертить с помощью pandoc.

Написал скрипт для удобства пользования - меняется дата файла - автоматом резервная копия версии и конвертация в фоне.

Начал работать и тут вскрылась куча недостатков markdown;

1. Нет нормального форматирования (заголовок нельзя центрировать)
2. Нет нормальных таблиц, один ущерб какой-то.
3. Проблема с кирилицей (решаемая), но с помощью дополнительного tex-файла настроек.

\usepackage{longtable}\setlength{\LTleft}{2em}
\setmainfont{Liberation Serif}
\setsansfont{Liberation Sans}
\setmonofont{Liberation Mono}
\newfontfamily\cyrillicfont{Liberation Sans}
\defaultfontfeatures{Scale=MatchLowercase, Mapping=tex-text}
\usepackage{polyglossia}
\setmainlanguage{russian}
\setotherlanguage{english}

4. Нет возможности печатать некоторые символы UTF.
5. некоторые символы приходится маскировать, чтобы они не понимались, как управляющие.

Единственный плюс - подсветка синтаксиса bash.

В общем, после 19 главы я понял, что моего терпения не хватит закончить работу. Вернулся к libreoffice. За два дня освоил работу со стилями, и все пошло как по маслу. Кстати, экспорт в pdf тоже быстрее, на мой взгляд.

Может и не все получилось, сами знаете - первый блин комом.

Замечания и комментарии приветствуются.

С результатом можно ознакомиться здесь 👇

🅰️🅰️
➡️ https://github.com/tagd-tagd/self-instruction
🅰️🅰️

🛠 #bash #linux #utilites #markdown
—
✅ @bashdays / @linuxfactory / @blog

Сегодня будем убивать неугодные сервисы. Нет, тут будет не про kill и т.п. а будет все тот же systemd.

Короче в юните можно указать параметр RuntimeMaxSec, в нем задаём время жизни сервиса. Если сервис работает дольше указанного времени, то ему песда. Systemd принудительно завершит его.
ㅤ
Удобно применять для сервисов, которые не должны жить вечно. Нет ничего вечного! Например, временные задачи, вспомогательные демоны, скрипты и т.п.

[Service]
RuntimeMaxSec=30s

0s, 5min, 1h, 2d — интервалы
infinity — отключение лимита

А что будет если время вышло?

Как и написал выше — будет песда! Systemd пошлет SIGTERM. А если сервис сука живучий и не завершился, то в ход пойдет тяжелая артиллерия через TimeoutStopSec, тут уже будет послан SIGKILL. Но его нужно предварительно прописать.

TimeoutStopSec= — это время ожидания корректного завершения сервиса после того, как systemd послал ему сигнал SIGTERM.

[Service]
ExecStart=/usr/bin/python3 /opt/scripts/bashdays-task.py
RuntimeMaxSec=60

Этот сервис будет убит через 60 секунд после запуска — даже если скрипт ещё не завершился.

[Service]
ExecStart=/usr/bin/bashdays-daemon
RuntimeMaxSec=60
TimeoutStopSec=10

Если bashdays-daemon работает дольше 60 секунд → SIGTERM
Ждём до 10 секунд → если не завершился → SIGKILL

Частый паттерн

RuntimeMaxSec=300
TimeoutStopSec=5
Restart=on-failure

Сервис работает максимум 5 минут, и если завис — systemd подождёт 5 секунд на аккуратное завершение, а потом прибьёт его нахуй.

А нахуя тут Restart=on-failure?

Оно говорит — «если сервис завершился аварийно — перезапусти его» А завершение по SIGKILL из-за превышения времени жизни это и есть failure.

Если не указать TimeoutStopSec, будет использоваться значение по умолчанию: 90 секунд — порой это дохуя, поэтому предпочтительнее задать его руками.

Важный нюанс!

Если в юните используется Restart=always, то после убийства, сервис будет перезапущен и возможно сразу «помрёт» если не изменит своё поведение.

Такие дела, изучай!

🛠 #linux #tricks #debug #systemd #bash
—
✅ @bashdays / @linuxfactory / @blog

Имена файлов удаляются с помощью системных вызовов unlink, unlinkat.
ㅤ
Ну дак вот. Когда счетчик ссылок (имен) становится равен нулю — файл удаляется.

Физическое удаление (блоки маркируются свободными) происходит когда больше никто не удерживает файл. То есть процесс закрыл последний дескриптор ассоциированный с файлом.

Давай попробуем поймать (открыть файл) до того, как запустится вызов unlink.

Создаем искусственный временный файл:

printf '%s\n' {a..z} > /tmp/sh-thd-bashdays

Создаем и запускаем скрипт:

#!/bin/bash

file=/tmp/sh-thd-bashdays
exec 3< "$file"  
rm -vf "$file"      # Имени уже нет 
read -N 4096 -ru 3  # Но мы читаем  
printf '%s' $REPLY  # Выводим
exec 3>&-  
exit

Что тут происходит?

exec 3< - файл открывается на чтение, привязывается к дескриптору 3 и с этого момента файл начинает жить в «памяти» в open file table ядра, даже если мы его ёбнем удалим. Дескриптор 3 теперь указывает на открытый файл, независимо от имени.

rm -vf - файл удаляется из файловой системы, имени больше нет, НО, его содержимое еще доступно, потому что он открыт.

read -N 4096 - читаем до 4096 байт из открытого файла через дескриптор 3.

exec 3>& - закрываем дескриптор 3 и после этого файл окончательно исчезнет, если его больше никто не держит, а ядро высвобождает ресурсы.

Итоги:

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

Это классическая Unix-модель: имя файла — не сам файл, а просто ссылка.

Если держишь дескриптор — файл всё ещё существует.

А тут как-то рассказывал, как восстанавливать удаленные файлы, в том числе и запущенные.


Чтиво почитать:

man 2 unlink
man 2 unlinkat

🛠 #linux #bash
—
✅ @bashdays / @linuxfactory / @blog

Напозырить и ужаснуться

50 GNU Commands VS 50 PowerShell Commands
ㅤ
🛠 #bash #powershell
—
✅ @bashdays / @linuxfactory / @blog