wiki/docs/linux/Заметки.md

Заметки

Диски

Жесткие ссылки

Что это: Это прямые ссылки на один и тот же файл в файловой системе. Несколько имен могут указывать на один и тот же файл (один inode). Информация, которую хранят: Жесткая ссылка хранит inode файла — уникальный идентификатор файла в файловой системе, но не содержит путь к файлу.

Особенности: У всех жестких ссылок один и тот же inode, то есть это фактически один и тот же файл. Если исходный файл удален, остальные жесткие ссылки остаются рабочими, так как данные физически не удаляются, пока существует хотя бы одна жесткая ссылка. Работают только внутри одной файловой системы. Не могут ссылаться на каталоги (кроме системных ссылок типа . и ..).

Символические ссылки (symlinks)

Что это: Это ссылки, которые содержат путь к другому файлу или каталогу. Это фактически отдельный файл, который указывает на местоположение целевого файла. Информация, которую хранят: Символическая ссылка хранит путь к целевому файлу или директории.

Особенности: Если целевой файл удален, символическая ссылка становится «битой» и неработоспособной, так как она указывает на несуществующий путь. Символические ссылки могут указывать на файлы или каталоги. Работают между различными файловыми системами. Они легче по объему, поскольку содержат только путь к файлу, а не данные самого файла.

!!! info "В файловой системе XFS иноды выделяются динамически, а вот в ext4 нет"

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

---

Виртуальная файловая система — это файловая система, которая существует только в оперативной памяти и не хранит данные на диске, например /proc, также известная как procfs (процессная файловая система).

• Не хранит данные на диске: Виртуальная файловая система отображает информацию, которая создаётся динамически при запросе и не сохраняется на постоянных носителях

• Динамическое содержимое: Данные генерируются операционной системой в реальном времени. Например, содержимое файлов в /proc — это текущая информация о системе, процессах, памяти, конфигурациях и т.д., которая изменяется в зависимости от состояния системы.

Почему система виртуальная

• Отражение состояния системы: Виртуальные файловые системы, такие как /proc, работают как интерфейс для чтения и управления текущим состоянием системы и процессами. Эти файлы не сохраняют данные, а лишь отображают их.

• Экономия ресурсов: Так как информация хранится только в памяти, это позволяет быстро получать текущие данные, не записывая их на диск.

• /sys: Динамическая информация о подключённых устройствах и драйверах.

• /dev: Содержит устройства, создаваемые динамически

---

Динамическое создание: В большинстве современных систем устройства в /dev управляются с помощью udev (система управления устройствами), которая автоматически создаёт и удаляет файлы в зависимости от подключаемых устройств.

Нет данных на постоянных носителях: Данные о состоянии устройств хранятся в памяти, а сами файлы в /dev отображают текущие устройства системы.

Доступ через ядро: Когда обращаются к файлам в /dev, ядро перенаправляет запросы к соответствующим драйверам, позволяя операционной системе взаимодействовать с оборудованием и эмулированными устройствами.

SSH

Файл ~/.ssh/known_hosts — это файл, который SSH использует для хранения информации о хостах (серверах), к которым вы ранее подключались. В этом файле хранятся "отпечатки" (fingerprints) публичных SSH-ключей серверов. Когда вы подключаетесь к серверу через SSH, клиент SSH проверяет, соответствует ли ключ сервера тому, который хранится в known_hosts.

Если ключ сервера изменился и не совпадает с тем, что хранится в known_hosts, SSH выдает предупреждение, чтобы предотвратить возможную атаку (например, "человек посередине").

Сигналы

В Linux можно отправлять процессы различные сигналы, которые управляют их поведением. Эти сигналы — это механизмы межпроцессного взаимодействия (IPC), которые позволяют процессам реагировать на внешние события, такие как завершение или перезапуск.

• kill -l - список всех сигналов в системе

Основные сигналы

• SIGTERM (15) - Завершение процесса

  kill -SIGTERM <pid>
  # или
  kill -15 <pid>
  

• SIGKILL (9) - Принудительное завершение процесса
• SIGHUP (1) - "Повесить" процесс (например, если конфигурационные файлы изменились, и процесс нужно перезагрузить без остановки. Процесс может получить SIGHUP при отключении терминала, и если он не запрограммирован для обработки этого сигнала, он просто завершится)
• SIGSTOP (19) - Остановка процесса.
• SIGCONT (18) - Возобновление выполнения остановленного процесса.

Зомби и сироты

Зомби-процесс — это завершившийся процесс, который всё ещё числится в таблице процессов, чтобы родитель мог получить его код завершения. Он не потребляет ресурсы, кроме записи в таблице процессов. Если таких процессов станет слишком много, это может помешать созданию новых, зомби не накапливаются, если родительский процесс правильно обрабатывает завершение дочерних.

Если родительский процесс корректно обрабатывает завершение своих дочерних процессов, зомби-процессы не накапливаются.

Если родительский процесс перестаёт функционировать, дочерние процессы (в том числе зомби) могут стать "сиротами" и будут переданы процессу init (PID 1), который автоматически собирает завершённые процессы и освобождает ресурсы.

Зомби-процессы нельзя "убить", так как они уже завершены. Однако можно решить проблему двумя способами:

• Перезагрузка системы: Это удалит все зомби-процессы.
• Убить родительский процесс: Если родительский процесс не обрабатывает завершение своих дочерних процессов, можно его завершить. Дочерние процессы будут переданы процессу init, который "соберёт" информацию о завершении и освободит зомби-процессы.

---

"Сирота" — это процесс, у которого завершился родительский процесс. В Linux системах, когда родительский процесс умирает до завершения своих дочерних процессов, эти дочерние процессы становятся "сиротами".

Что происходит с процессами-сиротами:

• Переназначение процессу init: Как только процесс становится сиротой, он автоматически "усыновляется" процессом с PID 1 (обычно это init или его современный аналог systemd в современных дистрибутивах). Процесс init берёт на себя ответственность за сироту и следит за его завершением.

• Корректное завершение: Когда процесс-сирота завершает свою работу, init собирает его статус завершения с помощью системного вызова wait() , предотвращая его превращение в зомби-процесс.

Отличие от зомби-процесса:

• Сирота — это активный процесс, который просто потерял своего родителя.
• Зомби — это завершённый процесс, чья запись остаётся в таблице процессов до тех пор, пока родитель не соберёт информацию о его завершении.

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

Bash

Команды в Linux выполняются слева направо, редиректы (>, >>, <) интерпретируются справа налево, потому что Bash сначала проверяет, куда нужно перенаправить вывод или откуда читать ввод, а потом выполняет саму команду.

echo "Hello" > file.txt

Здесь интерпретатор сначала создаёт или очищает файл file.txt (то есть обрабатывает часть > file.txt), а затем выполняет команду echo "Hello" и записывает результат в файл.

echo $(date)

Здесь сначала выполняется команда date (справа налево), а затем её результат подставляется в команду echo

echo `date`

Bash сначала выполнит команду date (внутри кавычек), затем передаст её результат команде echo.

Разное

Маска прав (umask) одна и та же для файлов и директорий, но результат применения маски отличается, поскольку начальные права у файлов и директорий разные (666 для файлов, 777 для директорий). То есть umask не различает файлы и директории, она применяется одинаково ко всем объектам, но итоговые права различаются из-за исходных прав.

---

top обновляется каждые 3 секунды

---

Что делает export?

export делает переменную окружения доступной для текущей оболочки и всех дочерних процессов. В данном случае она применяется к переменной PATH.

Systemd

Создание юнита

• в каталоге для хранения unit файлов cd /etc/systemd/system/ создаём файл с расширением .service для службы

• sudo vi /etc/systemd/system/myservice.service
  

• пишем unit файл

[Unit]
Description=Описание сервиса
After=network.target  # Определяет, когда сервис должен запускаться (например, после сети)

[Service]
ExecStart=/path/to/your/executable_or_script  # Команда для запуска сервиса
ExecStop=/path/to/stop/script (необязательно)  # Команда для остановки сервиса, если нужно
ExecReload=/path/to/reload/script (необязательно)  # Команда для перезагрузки
User=your_user  # Пользователь, от которого запустится сервис (если нужно)
Group=your_group  # Группа (если нужно)
Restart=always  # Политика перезапуска (может быть "on-failure", "always", "no")
RestartSec=5  # Задержка перед перезапуском
Environment="ENV_VAR=value"  # Можно задавать переменные окружения

[Install]
WantedBy=multi-user.target  # Указывает, что сервис должен запускаться в multi-user режиме (стандартный для большинства серверов)

multi-user - многопользовательский текстовый режим

• sudo systemctl daemon-reload - обновить конфигурацию systemd
• sudo systemctl enable myservice.service - включает автозапуск юнита при перезагрузке системы
• sudo systemctl start myservice.service - запустить юнит
• sudo systemctl status myservice.service - статус юнита

Где же живут эти ваши юниты

• /etc/systemd/system/ - пользовательские юниты (имеют приоритет)
• /usr/lib/systemd/system/ или /lib/systemd/system/ - юниты, которые создаются менеджерами пакетов при установке ПО
• /run/systemd/system/ - временные юниты, созданные во время работы чего-то (например, контейнера)

Про wants и requires

.wants

Используется для слабых зависимостей. Если основной юнит запущен, он попытается запустить все юниты, указанные в его .wants, но не завершит работу, если какой-то из них не удастся запустить.

Каталог .wants создается автоматически, если для юнита добавляют зависимость с WantedBy=.

.requires

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

Каталог .requires также создается при использовании директивы RequiredBy=, и его используют для критически необходимых зависимостей.