создал заметки по линуху
All checks were successful
Build MkDocs / build-and-deploy (push) Successful in 14s
All checks were successful
Build MkDocs / build-and-deploy (push) Successful in 14s
This commit is contained in:
parent
12b4c91358
commit
c43ced7615
193
docs/linux/Заметки.md
Normal file
193
docs/linux/Заметки.md
Normal file
@ -0,0 +1,193 @@
|
||||
### Заметки
|
||||
|
||||
#### Диски
|
||||
|
||||
***Жесткие ссылки***
|
||||
|
||||
**Что это**: Это прямые ссылки на один и тот же файл в файловой системе. Несколько имен могут указывать на один и тот же файл (один 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 сначала проверяет, куда нужно перенаправить вывод или откуда читать ввод, а потом выполняет саму команду.
|
||||
```bash
|
||||
echo "Hello" > file.txt
|
||||
```
|
||||
Здесь интерпретатор сначала создаёт или очищает файл `file.txt` (то есть обрабатывает часть > `file.txt`), а затем выполняет команду `echo "Hello"` и записывает результат в файл.
|
||||
```bash
|
||||
echo $(date)
|
||||
```
|
||||
Здесь сначала выполняется команда `date` (справа налево), а затем её результат подставляется в команду `echo`
|
||||
```bash
|
||||
echo `date`
|
||||
```
|
||||
Bash сначала выполнит команду `date` (внутри кавычек), затем передаст её результат команде `echo`.
|
||||
|
||||
#### Разное
|
||||
|
||||
Маска прав (`umask`) одна и та же для файлов и директорий, но результат применения маски отличается, поскольку начальные права у файлов и директорий разные (666 для файлов, 777 для директорий). То есть `umask` не различает файлы и директории, она применяется одинаково ко всем объектам, но итоговые права различаются из-за исходных прав.
|
||||
|
||||
---
|
||||
|
||||
`top` обновляется каждые 3 секунды
|
||||
|
||||
---
|
||||
|
||||
Что делает `export`?
|
||||
|
||||
`export` делает переменную окружения доступной для текущей оболочки и всех дочерних процессов. В данном случае она применяется к переменной `PATH`.
|
||||
|
||||
|
||||
### Systemd
|
||||
|
||||
#### Создание юнита
|
||||
|
||||
- в каталоге для хранения unit файлов `cd /etc/systemd/system/` создаём файл с расширением `.service` для службы
|
||||
- ```bash
|
||||
sudo vi /etc/systemd/system/myservice.service
|
||||
```
|
||||
- пишем `unit` файл
|
||||
```bash
|
||||
[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=, и его используют для критически необходимых зависимостей.
|
||||
|
||||
@ -17,6 +17,7 @@
|
||||
- `apt upgrade` - обновляет все установленные пакеты до последних доступных версий, основываясь на информации, полученной с помощью `apt update`, однако эта команда не устанавливает новые пакеты или не удаляет старые. Если для обновления пакета требуются новые зависимости, они не будут установлены.
|
||||
- `apt full-upgrade` - не только обновляет пакеты, но и может устанавливать новые зависимости и удалять старые пакеты, если это необходимо для завершения обновления
|
||||
- `sudp apt install <packege_name>` - устанавливает пакет
|
||||
- `sudo apt install ./имя_пакета.deb` - устанавливает .deb пакет
|
||||
- `supo apt search <packege_name>` - поиск пакета по имени
|
||||
- `apt show <packege_name>` - инфо о пакете
|
||||
- `apt autoclean` - для удаления старых неиспользуемых файлов
|
||||
@ -346,4 +347,69 @@ mount [OPTIONS] <DEVICE> <MOUNTPOINT>
|
||||
- `w` - только целые слова
|
||||
- `x` - совпадение всей строки
|
||||
|
||||
- `cat <filename> | grep -P "May 2 08:5(3|4|5):"` - ну понятно
|
||||
- `cat <filename> | grep -P "May 2 08:5(3|4|5):"` - ну понятно
|
||||
|
||||
### Логирование
|
||||
|
||||
- `tail -f /var/log/*` - логи (`-f` - обновление в реальном времени)
|
||||
- `head` - как tail, но head
|
||||
- `journalctl` - утилита для просмотра логов служб, управляемых `systemd`
|
||||
- `-u <service_name>` - просмотр логов конкретной службы
|
||||
```bash
|
||||
journalctl -u nginx
|
||||
```
|
||||
- `journalctl -u nginx -f` - просмотр логов в реальном времени
|
||||
- `journalctl -n 100` - последние 100 строк
|
||||
- `journalctl --since "2024-10-03 12:00:00" --until "2024-10-03 14:00:00"` - логи за конкретный период
|
||||
- `journalctl -p err` - можно показывать только ошибки
|
||||
- emerg (0): Аварийные сообщения.
|
||||
- alert (1): Требуют немедленных действий.
|
||||
- crit (2): Критические ошибки.
|
||||
- err (3): Ошибки.
|
||||
- warning (4): Предупреждения.
|
||||
- notice (5): Важные события.
|
||||
- info (6): Информационные сообщения.
|
||||
- debug (7): Отладочные сообщения.
|
||||
- `journalctl -xe`
|
||||
- x (или --catalog) — выводит дополнительные объяснения (аннотации) к некоторым сообщениям журнала, помогает понять детали ошибок или предупреждений, предлагая описания и возможные решения, если такие есть.
|
||||
- e (или --pager-end) — открывает журнал в режиме постраничного просмотра и сразу прокручивает его до конца, показывая самые последние записи.
|
||||
- `less -S` - не переносит на новую строку
|
||||
- `dmesg -T` - логи ядра системы
|
||||
- `/var/log/dmesg` - логи загрузки ядра (только *загрузки* ядра! dmesg - все логи ядра)
|
||||
- `sudo journalctl --disk-usage` - сколько места занимают логи на диске, собираемые journalctl
|
||||
- `sudo journalctl --vacuum-size=1G` - задаёт максимально допустимый размер для хранимых на диске логов
|
||||
- `sudo journalctl --vacuum-time=1years` - задаёт максимально допустимое время для хранимых на диске логов
|
||||
- `tail -f` следит за файлом и выводит новые строки по мере их добавления в файл. Однако, если файл будет удалён и создан заново (например, при ротации логов), `tail -f` перестанет отслеживать файл, потому что он будет считать, что файл исчез.
|
||||
- `tail -F` делает то же самое, но в случае удаления файла и его создания заново, `tail -F` продолжит отслеживать файл. Это полезно для логов, так как они могут быть перезаписаны, но вы хотите продолжать их отслеживать, несмотря на изменения имени файла или его создание заново.
|
||||
|
||||
---
|
||||
|
||||
- `/var/log/messages` — общие системные сообщения, включая ошибки ядра, службы и аппаратные события (в CentOS).
|
||||
- `/var/log/syslog` — аналог messages в Debian/Ubuntu, содержит системные логи и логи демонов.
|
||||
- `dmesg -T` - логи ядра системы
|
||||
- `/var/log/dmesg` - логи загрузки ядра (только *загрузки* ядра! dmesg - все логи ядра)
|
||||
- `/var/log/secure` — логи аутентификации, попыток входа, работы sudo (RHEL/CentOS).
|
||||
- `/var/log/auth.log` — аналог в Debian/Ubuntu, логи SSH, sudo и других служб аутентификации
|
||||
|
||||
#### Logrotate
|
||||
|
||||
Logrotate - это системная утилита Linux, которая управляет автоматической ротацией и сжатием лог-файлов.
|
||||
|
||||
Пример конфига logrotate
|
||||
|
||||
```ini
|
||||
/var/log/messages {
|
||||
size 100M # Ротация, если размер превышает 100 МБ
|
||||
rotate 10 # Хранить до 10 архивов
|
||||
compress # Сжимать старые файлы
|
||||
delaycompress # Откладывать сжатие на один цикл
|
||||
missingok # Игнорировать, если файл отсутствует
|
||||
notifempty # Пропускать пустые файлы
|
||||
sharedscripts # Пост-скрипт выполняется один раз для всех лог-файлов
|
||||
postrotate # HUP позволяет rsyslog подхватить новые файлы логов.
|
||||
/usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
|
||||
endscript
|
||||
}
|
||||
```
|
||||
- `logrotate -d /etc/logrotate.d/app` - для проверки конфигурации
|
||||
- `logrotate -f /etc/logrotate.d/app` - для принудительной ротации логов
|
||||
Loading…
x
Reference in New Issue
Block a user