Linux++ | Кирилл Жильников

Понимание типов оболочек: interactive, non-interactive, login, non-login

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

Оболочки "interactive"

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

Оболочки "non-interactive"

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

#!/bin/sh

Так вот, для запуска скрипта мы изначально открываем bash (интерактивная оболочка) и указываем путь:

$ ./script.sh

Далее bash запустит интерпретатор sh (неинтерактивная оболочка), после чего тот "втихую" выполнит скрипт.

Это ВАЖНО помнить! Скрипты отрабатывают в неинтерактивных оболочках и ваши настройки в файле "~/.bashrc" окажутся бесполезными. Почему такие оболочки не подгружают конфиги? Хороший вопрос. Есть несколько причин:

1) скрипту не следует полагаться на пользовательские настройки - быть "пользователезависимым". Если юзер "настругал" скрипт, опираясь, допустим, на свои алиасы, будет нарушена портируемость и у другого человека он, вероятно, не стартанет.

2) чтение и отработка конфигов может занимать время. Без дополнительных подготовок скрипт банально быстрее отработает.

Оболочки "login"

Такая оболочка создается первым пользовательским процессом, когда тот успешно логинится в системе и открывает сессию через tty или ssh. Если вы авторизовались через GUI - дисплей менеджер, "login shell" обычно заменяется оконным менеджером либо менеджером сессии.

Данный тип оболочки не создается все время, как мы открываем терминал и отличается тем, что читает дополнительные конфиги. Явно его можно идентифицировать по префиксу '-' для исполняемого файла. Давайте зайдем пользователем через tty и проверим:

$ ps -auxf
(root) /bin/login -p --
(user) \_ -bash
          \_ ps -auxf

А теперь сами запустим еще одну оболочку внутри родительской и убедимся, что статус "login shell" выдается невсегда:

$ bash
$ ps -auxf
 /bin/login -p --
 \_ -bash
    \_ bash
      \_ ps -auxf

Также узнать тип оболочки можно через переменную '0':

$ echo $0 
-bash

Оболочки "non-login"

Создаются при обычном старте - без авторизации пользователя. Все, что нужно для инициализации такой оболочки - просто открыть терминал либо самому запустить исполняемый файл без дополнительных флагов, которые переводят оболочку в режим "login": "-l" и "--login".

Linux++ | IT-Образование

Командные оболочки: от классики до инноваций

Наверняка многие знают оболочки sh и bash. Так же большинство из нас что-то слышали про zsh и fish. Однако на этом список не заканчивается.

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

Оболочка sh (Bourne shell)

Эта оболочка была написана Стивом Борном в 1977 году и является старейшей из известных публике.

Bourne shell была первой полноценной оболочкой и содержала функционал, который сейчас реализован всеми актуальными последователями: использование переменных, выполнение команд и функций, перенаправление ввода-вывода.

Сейчас sh по ряду причин является ссылкой на sh-совместимую оболочку:

$ ls -l | grep sh
sh -> dash

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

Именно поэтому он и существует в качестве ссылки, чтобы не ломать совместимость для выполнения скриптов. Все же помнят про shebang?)

#!/bin/sh

Оболочка bash (Bourne again shell)

Была разработана в рамках проекта GNU в качестве улучшенной реализации Bourne shell в 1989 году.

Основными создателями bash являются Брайан Фокс и Чет Рэми. Название можно перевести, как «Возрождённый шелл Борна». Скорее всего, самая популярная оболочка на сегодняшний день.

Данная оболочка является наследником sh и значительно расширяет его функционал. Однако все еще является древней и не такой красивой и конфигурируемой, как более новые zsh и fish.

Оболочка zsh (Z shell)

Свободная современная sh-совместимая оболочка, созданная в 1990 году. Имеет ряд преимуществ перед bash, касающихся в основном работы в интерактивном режиме.

$ sudo apt install zsh

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

Однако zsh в полной мере раскрывается только через настройку конфигов. При первом запуске вы, вероятно, зададитесь вопросом: Зачем оно вообще надо - тот же самый bash... Да, его нужно вручную настраивать.

Очень рекомендованным дополнением к оболочке zsh является фреймворк "OH MY ZSH", который предназначен для управления настройками zsh и расширения его функционала за счет плагинов и тем.

Оболочка fish (friendly interactive shell)

Fish уже не такая "бородатая" оболочка. Первая версия датируется 2005 годом. На фоне основных коллег по цеху, которые были выпущены еще в прошлом веке fish — свежий огурчик.

$ sudo apt-add-repository ppa:fish-shell/release-3
$ sudo apt update
$ sudo apt install fish

Если вам нужен функционал больше, чем у bash, но вам не хочется зарываться в конфиги, как с zsh, можно рассмотреть данную оболочку.

Все бы хорошо, но есть нюанс: fish - POSIX-несовместимая оболочка. Это значит, что правила, продиктованные стандартом POSIX для ряда оболочек (bash, zsh и т.д.), не имеют никакого влияния на fish.

Пример. Вот так мы определяем локальные переменные в bash и zsh:

$ MY_VAR="Hello"

Давайте попробуем повторить то же самое в fish:

$ MY_VAR="Hello"
fish: Unsupported use of '='. In fish, please use 'set MY_VAR "Hello"'

Тут так не получится. В fish переменные определяются следующим образом:

$ set MY_VAR "Hello"

Уже поняли в чем суть? Если вы напишите скрипт на специфичном для fish синтаксисе и попытаетесь запустить его через интерпретатор bash, sh или zsh, вероятно, он упадет с ошибкой.

Linux++ | IT-Образование

Оболочка - не терминал: что это и зачем нужно?

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

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

$ whereis bash
bash: /usr/bin/bash

Она принимает понятные человеку команды и выполняет их через обращения к ядру - на его языке - через набор системных вызовов: fork(), execve() и т.д.

Вот мы вводим команду "ls -l". Грубо говоря, как оболочка ее выполняет: создает дочерний процесс через вызов fork(), выполняет программу с заданными аргументами через execve() и дожидается ее завершения через wait().

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

Никто же нам не мешает просто удалить исполняемые файлы оболочек (bash, sh, zsh) и запустить терминал... Так, конечно же, делать НЕ СТОИТ, но приложение, вероятно, запустится и выведет следующее сообщение:

Warning: Could not find an interactive shell to start

При этом мы все еще сможем вводить текст и видеть его в окошке. Без оболочки терминал уже не так полезен - он понятия не имеет, как выполнить ту же команду "ls -l".

Также у оболочек может быть набор встроенных команд, которые могут отличаться от типа к типу. Помните, мы тут alias рассматривали? Так вот, это и есть та самая, встроенная в оболочку команда:

$ type alias
alias is a shell builtin

Команды оболочки - не отдельные программы. За их выполнением оболочка не пойдет по каталогам, прописанным в переменной $PATH: /usr/bin, /usr/sbin... К встроенным командам еще можно отнести: cd, case, export, pwd и т.д.

Linux++ | IT-Образование

Ускорь свою работу в командной строке - используй alias!

Приветствую! В прошлой публикации о псевдонимах мы познакомились с потрясающей командой оболочки alias и научились сокращать вызовы команд с длинным перечнем аргументов до пары символов.

Сегодня мы обратимся к моему опыту и рассмотрим ТОП команд, которые удобно использовать под псевдонимами.

Быстрый поиск команды по истории

$ alias hgrep='history | grep'
$ hgrep cat
712  cat gtk-dark.css

Создание родительских директорий

$ alias mkdirs='mkdir -pv'
$ mkdirs ./dir1/dir2/dir3

Удаление директории

$ alias rmd='rm -rf'
$ rmd ./dir1

Перезагрузка и отключение системы

$ alias reboot='sudo /sbin/reboot'
$ alias poweroff='sudo /sbin/poweroff'

Переход назад по каталогам

$ alias ..="cd .."
$ alias ..2="cd ../.."
$ alias ..3="cd ../../.."

Установка пакетов

$ alias install='sudo apt install'

Обновление пакетов

$ alias upgrade='sudo apt update && sudo apt dist-upgrade'

Топ 5 потребление памяти

$ alias mem5='ps auxf | sort -nr -k 4 | head -5'

Топ 5 потребление CPU

$ alias cpu5='ps auxf | sort -nr -k 3 | head -5'

Сравнение файлов и директорий

$ alias diff='diff -Naur'

Упаковка и распаковка .tar архива

$ alias tar='tar -cvf'
$ alias untar='tar -xvf'

Отображение скрытых файлов и каталогов

$ alias ls.='ls -d .* --color=auto'

Linux++ | IT-Образование

Сокращаем команды: Мощь псевдонимов в Linux

Команда alias — это удобный инструмент для тех, кто постоянно работает в командной строке.

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

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

К примеру, нам нужно понять, какие файлы занимают в целевом каталоге слишком много места и не надо ли их удалить...

Для реализации этой задачи нам потребуется команда ls и много-много аргументов:

$ ls --human-readable --size -1 -S --classify

Каждый раз набирать команду с таким количеством параметров не слишком удобно и хорошо бы это дело как-то сократить. Можно воспользоваться alias и определить ярлык для данного вызова:

$ alias lsrt='ls --human-readable --size -1 -S --classify'

Теперь запуск lsrt приведет к тому же результату, что и использование ls с параметрами.

Если нам больше не нужен ярлык, мы можем воспользоваться командой "unalias" и удалить его:

$ unalias lsrt
$ lsrt
Command 'lsrt' not found

Если требуется вывести значение конкретного псевдонима, запустите alias и передайте его имя в качестве аргумента:

$ alias g
alias g='grep'

Важно: после начала нового сеанса оболочки псевдоним пропадет, а при попытке его использовать мы получим ошибку следующего вида:

<your-alias-name> : command not found.

Создание постоянных псевдонимов

Давайте, для начала, посмотрим, какие псевдонимы уже заданы в системе и доступны для текущей сессии:

$ alias
alias l='ls -CF'
alias la='ls -A'
...

Хммм, интересно, почему я ничего еще не делал, а уже что-то определено...

Да, в зависимости от дистрибутива, определенный набор псевдонимов уже будет заранее задан.

Как правило, найти и определить глобальные псевдонимы можно в скрипте "~/.bashrc", который выполняется каждый раз при инициализации оболочки:

$ cat ~/.bashrc | grep alias
alias la='ls -A'
alias l='ls -CF'

Вот и они - те самые псевдонимы. Таким образом, для того, чтобы наш ярлык был доступен в разных терминалах целевого пользователя, нам требуется прописать его в локальном файле "~/.bashrc".

Если вы хотите, чтобы ваши алиасы были доступны для всех юзеров системы, необходимо использовать файл "/etc/bash.bashrc".

Linux++ | IT-Образование

Подгружаем, отгружаем, управляем – просто и эффективно

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

Сегодня посмотрим на парочку команд и приемов по администрированию модулей.

Перечисление загруженных модулей

У вас есть возможность вывести список, подгруженных на данный момент, модулей. Выполнить это нам поможет lsmod - простая утилита, которая не принимает никаких опций или аргументов.

Все, что делает команда - читает файл "/proc/modules" и отображает его содержимое в хорошо отформатированном списке:

$ lsmod
Module                  Size  Used by
tcp_lp                 12663  0
bluetooth             372662  7 bnep
rfkill                 26536  3 bluetooth

Результат дает нам следующую информацию:

1) Module - название модуля, выгруженного в память;

2) Size - количество памяти (в килобайтах), которое занимает модуль;

3) Used by - количество экземпляров модуля, используемое в настоящее время. Нулевое значение означает, что модуль не используется и его можно безопасно выгрузить.

Разделенный запятыми список после числа показывает, какие модули использует экземпляр;

Вывод информации о модуле

Команда modinfo отображает дополнительную информацию о модуле:

$ modinfo i915
filename: /lib/modules/6.8.12-060812-generic/kernel/drivers/gpu/drm/i915/i915.ko.zst

license: GPL and additional rights

description: Intel Graphics

author: Intel Corporation
...

Загрузка модулей в рантайме

Как уже говорилось, подгрузка модулей - эффективный способ расширить функционал ядра. Как загрузить модуль? Использовать команды modprobe и insmod:

1) modprobe - умная команда, которая анализирует файл modules.dep, чтобы сначала загрузить зависимости, потом уже сам модуль:

$ modprobe i915
$ lsmod | grep i915
i915  4268032  53

2) insmod - более простая и менее гибкая команда, которая загружает модуль без проверки зависимостей:

$ insmod helloWorld.ko
Welcome to Hello world Module.

Выгрузка модулей в рантайме

При необходимости можно удалить модули из работающей системы. Это также можно выполнить 2 способами: использовать rmmod или modprobe -r.

Последняя используется для более безопасного удаления, учитывая зависимости.

При выгрузке модуля через rmmod, остальные, которые от него зависят, будут пытаться функционировать.

Также команда поддерживает опцию "--force", которая ингода может быть полезна для агрессивной выгрузки:

$ rmmod module.ko
Goodbye, from module

$ modprobe -r module.ko
Goodbye, from module

Исключение модуля из автоматической загрузки

Для того, чтобы не загружать модуль на этапе бута системы, его требуется добавить в ЧС - файл blacklist.conf:

$ cat /etc/modprobe.d/blacklist.conf

blacklist eepro100
blacklist evbug

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

Автозагрузка модулей

Для того, чтобы каждый раз не производить ручную загрузку модулей, работать с которыми требуется регулярно, существует отдельный каталог, в котором можно настроить автоматическую загрузку модулей на старте системы "/etc/modules-load.d/".

В каталоге хранятся конфиги, содержащие наименования необходимых модулей:

$ cat modules.conf
video
e1000
serio_raw

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

Linux++ | IT-Образование

Модуль ядра — ключ к расширению возможностей Linux

Как вы знаете, или, может быть, слышали, ядро Linux изначально задумывалось монолитным - весь функционал отрабатывает в рамках одной программы:

/boot/vmlinuz-6.8.0-47-generic

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

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

Модуль ядра - это программа, которая может отсоединяться от ядра и присоединяться к нему по необходимости, без повторной его компиляции и перезагрузки системы.

В общих терминах, модуль можно описать, как плагин, который расширяет функциональность ядра.

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

Находятся все модули в директории "/lib/modules/". Учитывая то, что они собираются под каждую отдельную версию ядра, в этом каталоге выстраивается структура папок - по штуке на установленную версию:

$ cd /lib/modules
$ ls
6.10.1-061001-generic  6.11.0-9-generic       6.8.0-060800-generic   6.9.0-060900-generic

В директории целевого ядра находятся, как сами модули, так и дополнительные конфиги:

$ cd 6.8.12-060812-generic
$ ls
build
modules.builtin            
modules.dep.bin  
kernel
...

В ОС Linux все модули имеют расширение .ko (kernel object) или .ko.zst (модуль, сжатый с помощью алгоритма Zstandard). Подгружаются они, как правило, на этапе бута системы.

Помните, я тут недавно жаловался на драйвер i915, который в старых ядрах очень несовместим с некоторыми intel процессорами. Давайте посмотрим, где он засел:

$ find /lib/modules/$(uname -r) -name *.ko* | grep i915

/lib/modules/6.8.12-060812-generic/kernel/drivers/gpu/drm/i915/i915.ko.zst

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

Linux++ | IT-Образование

Старость - не радость!

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

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

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

Но за всем не уследишь. На днях, что вы думаете, нашел очередную проблему в модуле ядра - драйвере i915... По итогу, уже 2 очень неприятных графических бага решаются просто поднятием версии до плюс-минус актуальной.

Больше шансов столкнуться с проблемами у тех пользователей, которые сидят на старых ядрах и новом железе. Какие-то шестеренки linux kernel могут очень тяжело прокручиваться на вашем 144Гц мониторе или, к примеру, intel I9 последнего поколения.

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

Linux++ | IT-Образование

Во, отличная шпаргалка, которая будет полезным дополнением к 2 предыдущим постам:

1) разница между chmod и chown;
2) файл групп /etc/group;

Много раз слышал от знакомых "Ой, вот помню, что 777 дает всем права на все, дальше хз...".

Та я и сам, когда лень вспоминать степени 2 и что-то там считать, обычно проставляю права через "буковки". Теперь, может, и другие комбинации в голове отложатся)

Linux++ | IT-Образование

Учимся работать с историей bash

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

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

История команд bash хранится в специальном файле .bash_history, который лежит в домашней директории пользователя. Каждый раз, когда пользователь вводит команду, она попадает именно в этот файл. Запись происходит при завершении сеанса.

За то, какое количество команд хранится в истории, отвечает переменная окружения HISTFILESIZE. Если она выставлена, то берется указанное в ней число, иначе история не обрезается и файл .bash_history растет бесконечно:

$ cat ~/.bash_history

history | grep qdbu
qdbus org.kde.KWin /Compositor suspend

Посмотреть историю можно и более простым способом - выполнить команду history. Эта команда выведет содержимое .bash_history, добавив слева номер:

$ history
6  exit
7  docker ps

Если набрать "history 5", то отобразятся только пять последних введенных команд:

$ history 5
1498  sudo reboot
1499  cat ~/.bash_history
...

При необходимости историю всегда можно погрепать:

$ history | grep export
174  export HOME=/tmp
183  history | grep export

Еще один способ - использовать комбинацию Ctrl+R прямо в оболочке. После нажатия клавиш начинается поиск:

$ (reverse-i-search)`qdb': qdbus org.kde.KWin /Compositor suspend

Настройка истории Linux

По умолчанию, команда history дополняет .bash_history только порядковым номером, но вы можете выводить еще и дату выполнения команды. Для этого нужно экспортировать переменную HISTORYFORMAT вместе нужным форматом:

$ export HISTTIMEFORMAT='%F %T '

$ history
1503  2024-10-28 11:17:56 cat ~/.history

Также можно отключить вывод одинаковых команд:

$ export HISTCONTROL=ignoredups

Вы можете указать какие команды не стоит отображать, например, не будем выводить ls -l, pwd и date:

$ export HISTIGNORE='ls -l:pwd:date:'

Linux++ | IT-Образование

Мониторинг ресурсов системы: Mission Center

Mission Center — полезная GUI программа для мониторинга использования CPU, RAM, GPU, дисков, сети, процессов.

Является более стильным аналогом приложения «Системный монитор» в GNOME. Интерфейс программы - диспетчер задач Windows, реализованный на GTK4.

Mission Center может быть отличным выбором для новичков, которым первое время может быть трудно ориентироваться в терминале и использовать утилиты top и htop.

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

Возможности:

1. Мониторинг использования CPU: общая статистика, статистика по каждому ядру и процессу.

2. Просмотр процессов и потоков.

3. Мониторинг использования RAM и Swap.

4. Мониторинг использования дисков, расчет скорости записи и чтения.

5. Оценка использования сети.

6. Мониторинг использования GPU: потребление памяти, питания и т.д.

7. Просмотр информации о сетевых интерфейсах: имя сетевой карты, тип соединения, ip адрес и т.д.

Установка:

1. Если дистрибутив поддерживает Flatpak, то ставится и запускается все максимально просто:

Установка Flatpak

$ sudo apt install flatpak
$ flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Установка Mission Center

$ flatpak install flathub io.missioncenter.MissionCenter
$ flatpak run io.missioncenter.MissionCenter

2. Во втором случае путь один - ручная сборка через исходники. Подробная инструкция по установке содержится в GitLab репозитории проекта: ИСХОДНИКИ.

Сайт проекта: Mission Center.

Linux++ | IT-Образование

Топ команд по управлению процессами

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

Команда для просмотра процессов "ps":

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

Если выполнить ps без каких-либо флагов, то получится просмотреть только процессы, запущенные текущим терминалом:

$ ps  
PID TTY       TIME CMD  
107468 pts/1  00:00:00 bash  
107747 pts/1  00:00:00 ps

C этой командой вам нужно быть довольно точным в требованиях. Если вы хотите посмотреть на полный список процессов, запущенных целевым пользователем, вам нужно попросить именно об этом:

$ ps -u xodefender | grep picom  
109331 ?        00:00:00 picom

Если мы посмотрим на вывод с флагом "--help", то поймем, что команда на столько обширная, что и для "--help" есть ряд параметров:

$ ps --help  
  
Usage:  
ps [options]  
  
Try 'ps --help <simple|list|output|threads|misc|all>'

Возможных флагов и комбинаций, на самом деле, уйма. На практике, чаще всего, используется именно следующая запись "ps -aux", где:

'a' говорит о выводе процессов всех пользователей;
'u' требует отобразить пользователя, которому принадлежит процесс;
'x' просит вывести процессы, которые не привязаны к управляющему терминалу (TTY) - демоны и другие фоновые процессы.

$ ps -aux  
USER   PID %CPU %MEM    VSZ   RSS    TTY  STAT  START   TIME COMMAND  
root   1    0.0  0.3    23128 13352   ?    Ss   08:57   0:07 /sbin/init

Команды для убийства процессов "kill/pkill":

Бывает же такое, программа просто перестает отвечать на запросы. Да, знаю, частенько бывает. В таком случае может быть полезно, во что бы то ни стало, уничтожить подвисший процесс. Сделать это можно с помощью команд "kill" и "pkill".

Команда "kill" требует указать id процесса, который необходимо терминировать:

$ kill 109331

Работает это через отправку сигнала целевому процессу. Без явного указания, команда пытается "убить" процесс с помощью сигнала "SIGTERM", которые не гарантирует полное и сиюсекундное терминирование.

Для того, чтобы по-настоящему "убить" процесс, требуется отправить сигнал "SIGKILL", который находится под 9 номером:

$ kill -9 109331

Список всех сигналов можно получить через флаг '-l':

$ kill -l  
1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP ...

Утилита "pkill" позволяет оперировать именами, а не идентификаторами и отправляет сигнал она всем процессам с указанным именем:

$ pkill -9 picom

Команда для получения id процесса "pgrep":

pgrep позволяет находить идентификаторы (PID) запущенных процессов на основе заданных критериев: имя процесса, его владелец и т.д. Для того, чтобы получить (PID) процесса по его имени, следует выполнить:

$ pgrep picom  
109331

Команды для оценки потребления ресурсов системы "top/htop":

Их использование полезно для анализа процессов и определения того, сколько CPU тратится на их выполнение, какое потребление оперативной памяти и т.д. htop является более продвинутой версией, но, в своей основе, они используются для идентичных целей:

$ top
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND 106676 xodefen+  20   0  495180  92356  63828 S   1.0   2.3   0:34.08 Xorg

Linux++ | IT-Образование

Базовые принципы коммуникации "пользователь -> приложение"

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

Обозреваемые концепты относятся к исполняемым файлам в целом, поэтому затрагивают и динамические библиотеки.

Некоторые из нас в курсе про какие-нибудь механизмы IPC (Inter Process Communications), как например: DBUS. IPC подразумевает коммуникацию между приложениями. Выглядеть она может следующим образом "пользователь -> приложение_1 -> приложение_2".

Причем пользователь в этой схеме не является ключевой сущностью - он может как-то повлиять на "приложение_1" и затригерить его обратиться к "приложение_2".

Коммуникация "пользователь -> приложение" обычно реализована 3 способами: конфиги, переменные окружения, аргументы командной строки:

Общение через файлы конфигурации

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

# читаем мануал к программе
$ man picom
# смотрим на список установленных файлов
$ dpkg -L picom

Для удобства, в последнем случае можно "грепнуть" вывод, т.к. обычно конфиги заканчиваются ".cnf" и ".conf":

$ dpkg -L picom | grep -e .conf -e .cnf
/usr/share/doc/picom/examples/picom.sample.conf

Также стоит упомянуть тот факт, что конфиги бывают пользовательскими и системными. Пользовательские, как правило, имеют больший приоритет и расположены в скрытой директории внутри хомяка "~/.config". Системные, в свою очередь, где-то внутри "/etc/":

$ dpkg -L openssl | grep -e .conf -e .cnf
/etc/ssl/openssl.cnf

Общение через переменные окружения

Приложение может поддерживать коннект с пользователем и обрабатывать запросы в том числе и через переменные. Если мы посмотрим на мануал к проекту mesa, сколько же там всего можно проконтролировать, оставляю ссылочку. Аналогичная история и с такими проектами, как gtk, kwin и т.д.

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

Общение через переменные происходит обычно по 3 сценариям:

1) мы определяем переменную для конкретного пользователя, например через файл "~/.bashrc". В таком случае, каждый раз, как пользователь открывает сессию, переменная становится видимой для приложений внутри:

$ cat ~/.bashrc
export SOME_VARIABLE="some value"

2) мы определяем общесистемную переменную "/etc/environment", которая доступна приложениям любой сессии и всем пользователям:

$ cat /etc/environment
SOME_VARIABLE="some value"

3) мы передаем переменную программе на старте. В результате, только целевая программа и ее потомки будут видеть переменную и смогут с ней работать:

$ SOME_VARIABLE="some value" picom

Общение через аргументы командной строки

Еще одна полезная опция - передавать программе определенный пулл параметром через CLI (Command line interface) в момент запуска. Такой формат очень распространен в "no-GUI" утилитах, работа с которыми происходит исключительно в командной строке: nmcli, pkcs11-tool, ssh и т.д.:

$ pkcs11-tool --module /usr/lib/librtpkcs11ecp.so -T

Список параметров программа, как правило, выдает через флаг "--help":

$ nmcli --help

nmcli [ПАРАМЕТРЫ] ОБЪЕКТ { КОМАНДА | help }
ПАРАМЕТРЫ
-a, --ask  запрос отсутствующих параметров

Linux++ | IT-Образование

Как демоны выполняют логгирование?

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

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

Что такое syslog?

Система syslog предоставляет единый централизованный механизм, который позволяет любому приложению записывать свои сообщения в единый журнал. Система syslog состоит из двух основных компонентов: демона syslogd и библиотечной функции syslog().

Демон syslogd, принимает сообщения из двух разных источников: сокета UNIX-домена (/dev/log), который хранит сообщения, сгенерированные локально, и сокета интернет-домена, который хранит сообщения, отправленные по TCP/IP.

Для записи сообщений в журнал любой процесс может воспользоваться библиотечной функцией syslog(). На основе переданных ей аргументов она создает сообщение и помещает его в сокет "/dev/log", где оно будет доступно для syslogd.

Файл /etc/syslog.conf

Конфигурационный файл "/etc/syslog.conf" определяет поведение демона syslogd и то, как и куда должны записываться системные сообщения. Он состоит из набора правил, которые имеют следующий вид:

источник.приоритет действие

# Записывать все сообщения от ядра в файл kern.log
kern.*              /var/log/kern.log

Программный интерфейс syslog

Программный интерфейс syslog состоит из трех основных функций, которые входят в пространство "syslog.h":

1. Функция openlog() устанавливает настройки, которые по умолчанию применяются ко всем последующим вызовам syslog():

void openlog(const char *ident, int log_options, int facility);

openlog("slog", LOG_PID|LOG_CONS, LOG_DAEMON);

2. Функция syslog() записывает сообщения в журнал:

void syslog(int priority, const char *format, ...);

syslog(LOG_INFO, "Hello world ... ");

‰3. Функция closelog() вызывается после окончания записи сообщений, чтобы разорвать соединение с журналом:

void closelog(void);

Если не прорабатывать конфиги и не указывать альтернативные пути вывода сообщений для различных источников, то последовательное выполнение функций выше приведет к появлению лога в файле "/var/log/syslog":

xodefenderpc slog[754521]: Hello world ...

Linux++ | IT-Образование

Переводим .rpm пакет в .deb (alien)

Представим такую ситуацию - ваш друг очень хочет дать вам потестить свое революционное приложение...

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

Без паники, есть решение - утилита alien, которая способна перегнать "инородную" для вашего пакетного менеджера бинарную сборку из одного формата в другой.

Поддерживается преобразование между пакетами: Linux Standard Base (.lsb), Redhat (.rpm), Debian (.deb), Stampede (.slp), Solaris (.pkg) и Slackware (.tgz).

$ sudo apt install alien

Для преобразования .deb файла в .rpm с изменением стандартных для Debian инсталляционных скриптов используется опция -r. На выходе получится RPM-пакет:

$ sudo alien -r --scripts <some_pkg>.deb 

<some_pkg>.rpm generated

Для преобразования .rpm файла в .deb используется опция -d. На выходе получится DEB-пакет:

$ sudo alien -d --scripts <some_pkg>.rpm 

<some_pkg>.deb generated

За дополнительной информацией об утилите направляю вас прямо в мануал.

Linux++ | IT-Образование

Микротуториал по управлению пакетами (Debian-based)

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

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

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

Основные команды apt

1. Обновляет локальный кэш с информацией о доступных пакетах и их версиях из репозиториев, прописанных в "/etc/apt/sources.list":

$ sudo apt update

2. Обновляет все установленные пакеты до актуальных версий, НО существующие пакеты не удаляет.

Если для обновления требуется удаление/установка зависимостей, оно пропускается, и пакет остается нетронутым в текущей версии:

$ sudo apt upgrade

3. Обновляет все установленные пакеты до актуальных версий, устанавливает или удаляет пакеты для разрешения зависимостей:

$ sudo apt dist-upgrade

4. Устанавливает пакет вместе со всеми его зависимостями:

$ sudo apt install <имя_пакета>

5. Переустанавливает пакет и обновляет все его содержимое. Бывает полезно, если какие-то файлы пакета были удалены или повреждены:

$ sudo apt install --reinstall <имя_пакета>

6. Удаляет указанный пакет, но оставляет файлы конфигурации:

$ sudo apt remove <имя_пакета>

7. Полностью удаляет пакет и его конфигурационные файлы:

$ sudo apt purge <имя_пакета>

8. Показывает информацию о пакете: версия, зависимости, описание, размер и т.д.:

$ sudo apt show <имя_пакета>

9. Ищет пакеты в репозиториях по имени или описанию:

$ sudo apt search <имя_пакета>

10. Удаляет пакеты, которые были установлены как зависимости, но больше не требуются:

$ sudo apt autoremove

11. Удаляет все загруженные архивы пакетов из кэша "/var/cache/apt/archives/":

$ sudo apt clean

Основные команды dpkg

1. Устанавливает пакет из локального файла .deb и не подтягивает зависимости:

$ sudo dpkg -i <имя_пакета.deb>

2. Удаляет пакет, но сохраняет конфигурационные файлы:

$ sudo dpkg -r <имя_пакета>

3. Полностью удаляет пакет и его конфигурационные файлы:

$ sudo dpkg -P <имя_пакета>

4. Показывает список всех установленных пакетов либо информацию о конкретном пакете:

$ dpkg -l
$ dpkg -l <имя_пакета>

5. Выводит подробную информацию о пакете/пакетах:

$ dpkg -s
$ dpkg -s <имя_пакета>

6. Показывает список файлов, установленных данным пакетом:

$ dpkg -L <имя_пакета>

7. Показывает содержимое архива .deb (файлы, которые будут установлены):

$ dpkg -c <имя_пакета.deb>

8. Доводит конфигурацию пакета/пакетов до конца при аварийном завершении:

$ sudo dpkg --configure -a
$ sudo dpkg --configure <имя_пакета>

9. Показывает имя пакета, который устанавливает указанный файл:

$ dpkg -S picom.desktop
picom: /etc/xdg/autostart/picom.desktop

Linux++ | IT-Образование

Слышали про chroot?

Chroot (change root) - это утилита, которая используется для того, чтобы создать закрытое окружение "тюрьму", в которой программа будет видеть определенную часть файловой системы, как корневую '/'.

Это похоже на создание миниатюрного "сейфа" или "контейнера" для запуска приложений. В качестве примера можете вспомнить тот же Docker.

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

Системный вызов chroot()

Каждый процесс обладает корневым каталогом — он представляет собой стартовую точку, от которой интерпретируются абсолютные имена путей, начинающиеся с символа '/'. По умолчанию данным каталогом является реальный корневой каталог файловой системы.

Иногда бывает удобно, чтобы процесс изменил свой корневой каталог. Это может реализовать с помощью системного вызова chroot(). Системный вызов chroot() изменяет корневой каталог процесса на каталог, указанный в аргументе pathname:

#include <unistd.h>
int chroot(const char *pathname);

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

Моменты, которые стоит учитывать при работе с chroot

Следует 100% помнить, что вызов chroot() не меняет текущий рабочий каталог процесса. Для обеспечения полной безопасности, либо перед, либо после chroot() необходимо выполнить вызов chdir(), иначе процесс сможет использовать относительные пути для доступа к ресурсам вне клетки.

Также, при переходе в пространство chroot, вы можете столкнуться с тем, что ничего не работает) Это и не удивительно, как оболочка будет выполнять команды, которых для нее просто не существует...

Для решения проблемы вам может понадобиться перенести ряд библиотек и программ из "реальной" корневой системы в имитированную либо использовать команду debootstrap, но это уже отдельная история)

Linux++ | IT-Образование

Пора обновляться на Kernel 6.11?

Серия ядер Linux 6.10 достигла конца срока поддержки, и вам следует рассмотреть возможность обновления до ядра Linux 6.11.

Ядро Linux 6.10 было выпущено 14 июля 2024 года и представило новые функции, среди которых:

1) системный вызов mseal() для защиты памяти;
2) поддержку языка Rust для архитектуры RISC-V;
3) поддержку сжатия Zstandard для файловой системы EROFS;

Ядро Linux 6.10 не является веткой с долгосрочной поддержкой (LTS), поэтому поддерживалось только несколько месяцев и получило четырнадцать обновлений.

Ядро Linux 6.11 было выпущено 15 сентября 2024 года и уже было принято различными популярными дистрибутивами: Ubuntu 24.10, Arch Linux, Fedora Linux и openSUSE Tumbleweed.

Данный релиз также является краткосрочным - будет поддерживаться несколько месяцев.

Если вам нужна долгосрочная поддержка, следует использовать либо Linux 6.6, либо Linux 6.1, обе версии будут поддерживаться до декабря 2026 года и являются LTS.

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

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

Linux++ | IT-Образование