Основы Linux от основателя Gentoo. Часть вторая

Об авторах

Перевод

Перевод выполнил Dmitry Minsky (Dmitry.Minsky@gmail.com)

Daniel Robbins

Дэниэль Роббинс — основатель сообщества Gentoo и создатель операционной системы Gentoo Linux. Дэниэль проживает в Нью-Мехико со свой женой Мэри и двумя энергичными дочерьми. Он также основатель и глава Funtoo, написал множество технических статей для IBM developerWorks, Intel Developer Services и C/C++ Users Journal.

Chris Houser

Крис Хаусер был сторонником UNIX c 1994 года, когда присоединился к команде администраторов университета Тэйлора (Индиана, США), где получил степень бакалавра в компьютерных науках и математике. После он работал во множестве областей, включая веб-приложения, редактирование видео, драйвера для UNIX и криптографическую защиту. В настоящий момент работает в Sentry Data Systems. Крис также сделал вклад во множество свободных проектов, таких как Gentoo Linux и Clojure, стал соавтором книги The Joy of Clojure.

Aron Griffis

Эйрон Гриффис живет на территории Бостона, где провел последнее десятилетие работая в Hewlett-Packard над такими проектами, как сетевые UNIX-драйвера для Tru64, сертификация безопасности Linux, Xen и KVM виртуализация, и самое последнее — платформа HP ePrint. В свободное от программирования время Эйрон предпочитает размыщлять над проблемами программирования катаясь на своем велосипеде, жанглируя битами, или болея за бостонскую профессиональную бейсбольную команду «Красные Носки».


Предисловие

Об этом самоучителе

Добро пожаловать в «Азы администрирования», второе из четырех обучающих руководств, разработанных чтобы подготовить вас к экзамену 101 в Linux Professional Institute. В данной части мы рассмотрим как использовать регулярные выражения для поиска текста в файлах по шаблонам. Затем, вы познакомитесь со «Стандартом иерархии файловой системы» (Filesystem Hierarchy Standard или сокр. FHS), также мы покажем вам как находить нужные файлы в вашей системе. После чего, вы узнаете как получить полный контроль над процессами в Linux, запуская их в фоновом режиме, просматривая список процессов, отсоединяя их от терминала, и многое другое. Далее последует быстрое введение в конвейеры, перенаправления и команды обработки текста. И наконец, мы познакомим вас с модулями ядра Linux.

В частности эта часть самоучителя (Часть 2) идеальна для тех, кто уже имеет неплохие базовые знания bash и хочет получить качественное введение в основные задачи администрирования Linux. Если в Linux вы новичок, мы рекомендуем вам сперва закончить первую часть данной серии практических руководств. Для некоторых, большая часть данного материала будет новой, более опытные же пользователи Linux могут счесть его отличным средством подвести итог своим базовым навыкам администрирования.

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

Регулярные выражения

Что такое «регулярное выражение»?

Регулярное выражение (по англ. regular expression, сокр. «regexp» или «regex», в отечестве иногда зовется «регулярка» — прим. пер.) — это особый синтаксис используемый для описания текстовых шаблонов. В Linux-системах регулярные выражения широко используются для поиска в тексте по шаблону, а также для операций поиска и замены на текстовых потоках.

В сравнении с глоббингом

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

Простая подстрока

После этого предостережения, давайте рассмотрим самое основное в регулярных выражениях, простейшую подстроку. Для этого мы воспользуемся «grep», командой, которая сканирует содержимое файла согласно заданному регулярному выражению. grep выводит каждую строчку, которая совпадает с регулярным выражением, игнорируя остальные:

$ grep bash /etc/passwd

operator:x:11:0:operator:/root:/bin/bash
root:x:0:0::/root:/bin/bash
ftp:x:40:1::/home/ftp:/bin/bash



Выше, первый параметр для grep, это regex; второй — имя файла. grep считывал каждую строчку из /etc/passwd и прикладывал на нее простую regex-подстроку «bash» в поисках совпадения. Если совпадение обнаруживалось, то grep выводил всю строку целиком; в противном случае, строка игнорировалась.

Понимание простой подстроки

В общем случае, если вы ищите подстроку, вы просто можете указать её буквально, не используя каких-либо «специальных» символов. Вам понадобиться особо позаботиться, только если ваша подстрока содержит +, ., *, [, ] или \, в этом случае эти символы должны быть экранированы обратным слешем, а подстрока заключаться в кавычки. Вот несколько примеров регулярных выражений в виде простой подстроки:

    * /tmp (поиск строки /tmp)
    * "\[box\]" (поиск строки [box])
    * "\*funny\*" (поиск строки *funny*)
    * «ld\.so» (поиск строки ld.so)



Метасимволы

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

$ grep dev.sda /etc/fstab

/dev/sda3       /               reiserfs        noatime,ro 1 1
/dev/sda1       /boot           reiserfs        noauto,noatime,notail 1 2
/dev/sda2       swap            swap            sw 0 0
#/dev/sda4      /mnt/extra      reiserfs        noatime,rw 1 1



В этом примере текст dev.sda не появляется буквально ни в одной из строчек из /etc/fstab. Однако, grep сканирует его не буквально по строке dev.sda, а по dev.sda шаблону. Запомните, что "." будет соответствовать любому единичному символу. Как вы видите, метасимвол "." функционально эквивалентен тому, как работает метасимвол "?" в glob-подстановках.

Использование []

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

$ grep dev.sda[12] /etc/fstab

/dev/sda1       /boot           reiserfs        noauto,noatime,notail 1 2
/dev/sda2       swap            swap            sw 0 0



Как вы заметили, в частности, данная синтаксическая конструкция работает идентично конструкции "[]" при glob-подстановке имен файлов. Опять же, в этом заключается одна из неоднозначностей в изучении регулярных выражений: синтаксис похожий, но не идентичный синтаксису glob-подстановок, что сбивает с толку.

Использование [^]

Вы можете обратить значение квадратных скобок поместив ^ сразу после [. В этому случае скобки будут соответствовать любому символу который НЕ перечислен внутри них. И опять, заметьте что [^] мы используем с регулярными выражением, а [!] с glob:

$ grep dev.hda[^12] /etc/fstab

/dev/hda3       /               reiserfs        noatime,ro 1 1
#/dev/hda4      /mnt/extra      reiserfs        noatime,rw 1 1



Отличающийся синтаксис

Очень важно отметить, что синтаксис внутри квадратных скобок коренным образом отличается от остальной части регулярного выражения. К примеру, если вы поместите "." внутрь квадратных скобок, это позволит квадратным скобкам совпадать с "." буквально, также как 1 и 2 в примере выше. Для сравнения, "." помещенная вне квадратных скобок, будет интерпретирована как метасимвол, если не приставить "\". Мы можем получить выгоду из данного факта для вывода строк из /etc/fstab которые содержат строку dev.sda, как она записана:

$ grep dev[.]sda /etc/fstab


Также, мы могли бы набрать:

$ grep "dev\.sda" /etc/fstab


Эти регулярные выражения вероятно не удовлетворяют ни одной строчке из вашего /etc/fstab файла.

Матасимвол *

Некоторые метасимволы сами по себе не соответствуют ничему, но изменяют значение предыдущего символа. Один из таких символов, это * (звездочка), который используется для сопоставления нулевому или большему числу повторений предшествующего символа. Заметьте, это значит, что * имеет другое значение в регулярках, нежели в глоббинге. Вот несколько примеров, и обратите особое внимание на те случаи где сопоставление регулярных выражений отличается от glob-подстановок:

* ab*c совпадает с «abbbbc», но не с «abqc» (в случае glob-подстановки, обе строчки будут удовлетворять шаблону. Вы уже поняли почему?)
* ab*c совпадает с «abc», но не с «abbqbbc» (опять же, при glob-подстановке, шаблон сопоставим с обоими строчками)
* ab*c совпадает с «ac», но не с «cba» (в случае глоббинга, ни «ac», ни «cba» не удовлетворяют шаблону)
* b[cq]*e совпадает с «bqe» и с «be» (glob-подстановке удовлетворяет «bqe», но не «be»)
* b[cq]*e совпадает с «bccqqe», но не с «bccc» (при глоббинге шаблон точно так же совпадет с первым, но не со вторым)
* b[cq]*e совпадает с «bqqcce», но не с «cqe» (так же и при glob-подстановке)
* b[cq]*e удовлетворяет «bbbeee» (но не в случае глоббинга)
* .* сопоставим с любой строкой (glob-подстановке удовлетворяют только строки начинающиеся с ".")
* foo.* совпадет с любой подстрокой начинающийся с «foo» (в случае glob-подстановки этот шаблон будет совпадать со строками, начинающимися с четырех символов «foo.»)


Итак, повторим для закрепления: строчка «ac» подходит под регулярное выражение «ab*c» потому, что звездочка также позволяет повторение предшествующего выражения (b) ноль раз. И опять, ценно отметить для себя, что метасимвол * в регулярках интерпретируется совершенно иначе, нежели символ * в glob-подстновках.

Начало и конец строки

Последние метасимволы, что мы детально рассмотрим, это ^ и $, которые используются для сопостовления началу и концу строки, соответственно. Воспользовавшись ^ в начале вашего regex, вы «прикрепите» ваш шаблон к началу строки. В следующием примере, мы используем регулярное выражение ^#, которое удовлетворяет любой строке начинающийся с символа #:

$ grep ^# /etc/fstab
# /etc/fstab: static file system information.
#


Полнострочные регулярки

^ и $ можно комбинировать, для сопоставлений со всей строкой целиком. Например, нижеследующая регулярка будет соответсвовать строкам начинающимся с символа #, а заканчивающимся символом ".", при произвольном количестве символов между ними:

$ grep '^#.*\.$' /etc/fstab
# /etc/fstab: static file system information.


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

FHS и поиск файлов

Стандарт иерархии файловой системы

Стандарт иерархии файловой системы (Filesystem Hierarchy Standard или сокр. FHS) — это документ который определяет схему директорий в Linux-системах. FHS разработан чтобы представить общую схему для упрощения независимой от дистрибутива разработки программного обеспечения, поскольку так все необходимое располагается одинаково в большинстве дистрибутивов. FHS определяет следующее дерево директорий (взято непосредственно из спецификации):

  • / (корневая директория)
  • /boot (статичные файлы загрузчика)
  • /dev (файлы устройств)
  • /etc (специфические для хоста конфигурационные файлы)
  • /lib (основные разделяемые библиотеки и модули ядра)
  • /mnt (точка монтирования для временных нужд)
  • /opt (дополнительные пакеты ПО)
  • /sbin (основные системные программы)
  • /tmp (временные файлы)
  • /usr (вторичная иерархия)
  • /var (изменяемые данные)


Две независимые классификации в FHS

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

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

+------------+-----------------+---------------+
|            | разделяемые     | неразделяемые |
+------------+-----------------+---------------+
| статичные  | /usr            | /etc          |
|            | /opt            | /boot         |
+------------+-----------------+---------------+
| изменяемые | /var/mail       | /var/run      |
|            | /var/spool/news | /var/lock     |
+------------+-----------------+---------------+



Вторичная иерархия в /usr

Внутри /usr вы обнаружите вторичную иерархию, которая выглядит очень похоже на корневую файловую систему. Для /usr не критично существование во время включения машины, она может быть общим сетевым ресурсом (разделяема) или примонтирована с CD-ROM (статична). Большинство конфигурация Linux не используют «разделяемость» /usr, но ценно понимать полезность отличия между основной иерархией в корневой директории и вторичной иерархией в /usr.

Это все, что мы расскажем о стандарте иерархии файловой системы. Сам по себе документ довольно читабелен и вам стоит на него взглянуть. После его прочтения вы будете гораздо лучше понимать файловую систему Linux. Найти спецификацию можно здесь: http://www.pathname.com/fhs/.

Поиск файлов

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

PATH

Когда вы запускаете программу из командной строки, bash начинает просматривать список директорий в поисках программы которую вы указали. Например, когда вы вводите ls, bash в действительности не знает, что программа ls находится в /usr/bin. Вместо этого, он ссылается на переменную окружения называемую PATH, которая содержит список директорий разделенных двоеточием. Мы можем проверить значение PATH:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin.


С таким значением PATH (у вас оно может быть другим) bash сначала проверит директорию /usr/local/bin, затем /usr/bin в поисках программы ls. Скорее всего, ls находится в /usr/bin, тогда на этой директории bash прекратит поиск.

Изменение PATH

Вы можете расширять переменную PATH, присваивая ей новое значение в командой строке:

$ PATH=$PATH:~/bin
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/agriffis/bin

Вы также можете удалять элементы из PATH, хотя это не так просто, поскольку вы не можете ссылаться в команде на существующий $PATH. Лучший вариант — это просто заново указать в PATH то, что вам нужно:

$ PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:~/bin
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/agriffis/bin


Чтобы сделать ваши изменения PATH доступными для процессов, которые будут запускаться в командной оболочке, необходимо «экспортировать» их используя команду export:

$ export PATH


О команде «which»

Вы можете проверить, есть ли конкретная программа в вашем PATH используя which. В следующем примере мы видим, в каталогах PATH нашей системы, программы с названием sense нет:

$ which sense
which: no sense in (/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin)


В этом примере, ls успешно находится:

$ which ls
/usr/bin/ls


which -a


Наконец, вы должны знать о флаге -a, который укажет which показать вам все экземпляры программы в PATH:

$ which -a ls
/usr/bin/ls
/bin/ls


whereis

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

$ whereis ls
ls: /bin/ls /usr/bin/ls /usr/share/man/man1/ls.1.gz


Здесь мы видим что ls находится в двух каталогах с общими исполняемыми файлами, /bin и /usr/bin. Кроме того, нам сообщили что есть документация, которая находится в /usr/share/man. Это man-страница которую вы увидите, если введете man ls.

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

find

Команда find это другой удобный инструмент в вашем арсенале. Используя find вы не ограничены лишь поиском программ; вы можете искать любые типы файлов, используя различные критерии поиска. Например, поищем в директории /usr/share/doc, файл который называется README:

$ find /usr/share/doc -name README
/usr/share/doc/ion-20010523/README
/usr/share/doc/bind-9.1.3-r6/dhcp-dynamic-dns-examples/README
/usr/share/doc/sane-1.0.5/README


find и шаблоны

Вы можете использовать glob-шаблоны для аргументов -name, при условии что вы экранируете их кавычками или обратным слешем (таким образом они будут переданы команде в нетронутом виде, иначе они сначала будут развернуты bash'ем и уже после переданы команде). Давайте поищем все файлы README с расширением:

$ find /usr/share/doc -name README\*
/usr/share/doc/iproute2-2.4.7/README.gz
/usr/share/doc/iproute2-2.4.7/README.iproute2+tc.gz
/usr/share/doc/iproute2-2.4.7/README.decnet.gz
/usr/share/doc/iproute2-2.4.7/examples/diffserv/README.gz
/usr/share/doc/pilot-link-0.9.6-r2/README.gz
/usr/share/doc/gnome-pilot-conduits-0.8/README.gz
/usr/share/doc/gimp-1.2.2/README.i18n.gz
/usr/share/doc/gimp-1.2.2/README.win32.gz
/usr/share/doc/gimp-1.2.2/README.gz
/usr/share/doc/gimp-1.2.2/README.perl.gz
[еще 578 строк опущено]

Игнорирование регистра в find

Конечно, вы можете игнорировать регистр при поиске:

$ find /usr/share/doc -name '[Rr][Ee][Aa][Dd][Mm][Ee]*'


Или, намного проще:

$ find /usr/share/doc -iname readme\*


Как видно, для поиска без учета регистра можно использовать опцию -iname .

find и регулярные выражения

Если вы знакомы с регулярными выражениями, вы можете использовать опцию -regex для поиска файлов с именами соответствующими шаблону. А также опцию похожую на -iname, которая называется -iregex и заставляет find игнорировать регистр в шаблоне. Пример:

$ find /etc -iregex '.*xt.*'
/etc/X11/xkb/types/extra
/etc/X11/xkb/semantics/xtest
/etc/X11/xkb/compat/xtest
/etc/X11/app-defaults/XTerm
/etc/X11/app-defaults/XTerm-color


Однако в отличии от большинства программ, find требует чтобы регулярное выражение указывалось для всего пути, а не только его части. По этой причине, стоит в начале и конце шаблона ставить .*; простого использования xt в качестве шаблона будет недостаточно.

find и типы файлов

Опция -type позволяет искать в файловой системе файлы определенного типа. Возможные аргументы для -type это: b (блочное устройство), c (символьное устройство), d (директория), p (именованый канал), f (обычный файл), l (символическая ссылка), и s (сокет). Например, поиск символической ссылки в /usr/bin, которая содержит в своем имени строку vim:

$ find /usr/bin -name '*vim*' -type l
/usr/bin/rvim
/usr/bin/vimdiff
/usr/bin/gvimdiff


find и mtimes

Опция -mtime позволяет вам искать файлы основываясь на дате их последней модификации. Аргументом mtime является количество 24-часовых периодов, и наиболее полезным будет указывать перед аргументом плюс (означает «после») или минус (означает «перед»). Например, рассмотрим следующий сценарий:

$ ls -l ?

-rw-------    1 root     root            0 Jan  7 18:00 a
-rw-------    1 root     root            0 Jan  6 18:00 b
-rw-------    1 root     root            0 Jan  5 18:00 c
-rw-------    1 root     root            0 Jan  4 18:00 d



$ date
Mon May 7 18:14:52 EST 2003


Вы можете найти файлы, которые были модифицированы за последние 24 часа:

$ find . -name \? -mtime -1
./a


Или файлы которые были изменены до текущего 24-часового периода:

$ find . -name \? -mtime +0
./b
./c
./d


Опция -daystart

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

$ find . -name \? -daystart -mtime +0 -mtime -3
./b
./c
$ ls -l b c

-rw-------    1 root     root            0 May  6 18:00 b
-rw-------    1 root     root            0 May  5 18:00 c



Опция -size

Опция -size позваляет искать файлы по их размеру. По-умолчанию, аргумент -size это количество 512-байтных блоков, но добавляя к опции суффикс, можно сделать вывод более понятным. Доступные суффиксы: b (512-байтные блоки), c (байт), k (килобайт), и w (2-байтные слова). Дополнительно, перед аргументом можно указать плюс («больше чем») или минус («меньше чем»).

Например, для поиска обычного файла в /usr/bin размер которого меньше 50 байт:

$ find /usr/bin -type f -size -50c
/usr/bin/krdb
/usr/bin/run-nautilus
/usr/bin/sgmlwhich
/usr/bin/muttbug


Работа с найдеными файлами

Вы даже не представляете, что можно делать с найденными файлами! Итак, find может производить любые действия над файлами используя опцию -exec. Эта опция принимает строку команд для выполнения, которая оканчивается на ;, и заменяет все вхождения {} именем файла. Это проще всего понять на примере:

$ find /usr/bin -type f -size -50c -exec ls -l '{}' ';'

-rwxr-xr-x    1 root     root           27 Oct 28 07:13 /usr/bin/krdb
-rwxr-xr-x    1 root     root           35 Nov 28 18:26 /usr/bin/run-nautilus
-rwxr-xr-x    1 root     root           25 Oct 21 17:51 /usr/bin/sgmlwhich
-rwxr-xr-x    1 root     root           26 Sep 26 08:00 /usr/bin/muttbug



Как видите, find это очень мощная команда. Она «выросла» за годы разработки UNIX и Linux. У find существует много других полезных опций. Вы можете прочитать о них в man-страничке.

locate

Мы уже рассмотрели which, whereis и find. Как вы уже наверно заметили, выполнение find может занять некоторое время, т.к. ей необходимо прочитать каждую директорию в которой выполняется поиск. Оказывается, что команда locate может ускорить процесс использую внешнюю базу данных, генерируемую updatedb (updatedb мы рассмотрим ниже).

Команда locate ищет совпадения любой части пути, а не только самого файла. Пример:

$ locate bin/ls
/var/ftp/bin/ls
/bin/ls
/sbin/lsmod
/sbin/lspci
/usr/bin/lsattr
/usr/bin/lspgpot
/usr/sbin/lsof


Использование updatedb

Во многих Linux системах есть «cron job» для периодического обновления базы. В случае если вызов locate вернул нижеописанную ошибку, вам необходимо запустить updatedb от root'а для генерации поисковой базы:

$ locate bin/ls
locate: /var/spool/locate/locatedb: No such file or directory
$ su -
Password:
# updatedb


Работа программы updatedb может занять некоторое время. Если у вас шумный жесткий диск, вы услышите как он шуршит индексируя файловую систему. :)

slocate

Во многих Linux дистрибутивах, утилита locate была заменена на slocate. Как правило существует также ссылка на locate, так что вам не нужно запоминать, что именно имеется в системе. slocate означает «безопасный locate» (от англ. secure locate — прим. пер.). Он сохраняет информацию о правах доступа в поисковой базе, так что, обычные пользователи не смогут увидеть директории, которые они и так не смогли бы видеть. Используется slocate точно также как locate, но вывод программы может быть различными в зависимости от пользователя ее запустившего.

Управление процессами

Запуск xeyes

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

$ xeyes -center red


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

Остановка процесса

Чтобы вернуть приглашение, вы должны нажать Control-C (часто пишется как Ctrl-C или ^C):

Вы получили назад свое приглашение, но и окно xeyes исчезло. Фактически, процесс был «убит». Вместо завершения по Control-C, мы можем просто остановить процесс с помощью Control-Z:

$ xeyes -center red
Control-Z

[1]+  Stopped                 xeyes -center red

$


На этот раз вы получите приглашение bash'a, а окно xeyes останется сверху. Если вы с ним немного поиграете, возможно заметите, что глаза заморожены на одном месте. Если окно xeyes будет перекрыто другим окном и затем снова открыто, вы увидите, что оно даже не перерисовалось. Процесс не делает ничего. Он на самом деле остановлен.

fg и bg

Чтобы процесс «растормошить» и запустить обратно, мы можем вывести его на передний план используя команду fg (от англ. foreground — прим. пер.):

$ fg
(test it out, then stop the process again)
Control-Z

[1]+  Stopped                 xeyes -center red

$


А теперь продолжим его в фоне с помощью команды bg (от англ. backgroud — прим. пер.):

$ bg
[1]+ xeyes -center red &
$


Прекрасно! Процесс xeyes сейчас запущен в фоновом режиме, а мы снова имеем приглашение bash.

Использование "&"

Если нам нужно сразу запустить xeyes в фоновом режиме (вместо использования Control-Z и bg), мы можем просто добавить "&" (амперсанд) в конец команды xeyes:

$ xeyes -center blue &
[2] 16224


Несколько фоновых процессов

Теперь в фоне у нас одновременно работают красные и синие xeyes. Мы можем просмотреть список заданий с помощью jobs:

$ jobs -l

[1]- 16217 Running                 xeyes -center red &
[2]+ 16224 Running                 xeyes -center blue &



Число в левой колонке — это порядковый номер задания, который bash присваивает ему при запуске. Плюс (+) у второго задания значит, что это «текущее задание», оно будет выведено на передний план при вводе fg. Вы также можете вывести на передний план конкретное задание указывая его номер; например, fg 1 сделает таковым красный xeyes. Следующая колонка это идентификатор процесса или сокращенно pid, любезно добавленный в вывод благодаря опции -l. Наконец, состояние обоих процессов «Running» (выполняется) и их командная строка справа.

Введение в сигналы

Чтобы убить, остановить, или продолжить процесс, Linux использует специальную форму взаимодействия, называемую сигналы. Отправляя сигнал некоторому процессу, вы можете его завершить, остановить, или сделать что-нибудь еще. Это то, что происходит на самом деле, когда вы нажимаете Control-C, Control-Z, или используете bg и fg — вы указываете bash отправить процессу определенный сигнал. Сигналы также можно отправить с помощью команды kill указав ей как параметр id процесса (pid):

$ kill -s SIGSTOP 16224
$ jobs -l

[1]- 16217 Running                 xeyes -center red &
[2]+ 16224 Stopped (signal)        xeyes -center blue



Как можно заметить, kill не обязательно «убивает» процесс, хотя может и это. Используя опцию -s, kill может отправить процессу любой сигнал. Linux убивает, останавливает или продолжает процессы когда они получают SIGINT, SIGSTOP, или SIGCONT сигнал соответственно. Есть и другие сигналы, которые вы можете отправить процессам; некоторые сигналы могут обрабатываться внутри самих программ. Вы можете узнать о сигналах которые обрабатывает конкретная программа поискав в ее man'е секцию SIGNALS.

SIGTERM и SIGINT

Если вы хотите убить процесс, есть несколько вариантов. По-умолчанию, kill отправляет SIGTERM, который отличается от SIGINT отправляемого по Control-C, но обычно имеет тот же эффект:

$ kill 16217
$ jobs -l

[1]- 16217 Terminated              xeyes -center red
[2]+ 16224 Stopped (signal)        xeyes -center blue



Полное убийство

Процесс может игнорировать оба сигнала, SIGTERM и SIGINT, либо по своему усмотрению, либо потому, что он остановлен, либо еще как-то «застрял». В этом случае, может быть необходимо использование большого молотка — сигнала SIGKILL. Процесс не может игнорировать SIGKILL:

$ kill 16224
$ jobs -l

[2]+ 16224 Stopped (signal)        xeyes -center blue

$ kill -s SIGKILL 16224
$ jobs -l

[2]+ 16224 Interrupt               xeyes -center blue


nohup


Терминал в котором вы запускаете задания, называется терминалом управления заданиями. Некоторые шеллы (но не bash по-умолчанию), отправляют сигнал SIGHUP фоновым заданиям когда вы выходите, заставляя их завершаться. Для защиты процессов от такого поведения, используйте nohup когда запускаете процесс:

$ nohup make &
[1] 15632
$ exit


Используем ps для вывода списка процессов

Команда jobs, которую мы использовали ранее выводит только те процессы, которые были запущены в вашей сессии bash. Чтобы увидеть все процессы в вашей системе, используйте ps совместно с опциями a и x:

$ ps ax

  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:04 init [3]
    2 ?        SW     0:11 [keventd]
    3 ?        SWN    0:13 [ksoftirqd_CPU0]
    4 ?        SW     2:33 [kswapd]
    5 ?        SW     0:00 [bdflush]



Здесь приведены только первые 5 процессов, поскольку обычно список процессов очень длинный. Команда дает вам «слепок» всего, что в данный момент выполняется на машине, однако в нем много лишней информации. Если бы вы, не указали ax, вы бы получили список только тех процессов, которые принадлежат вам, и которые есть в управляющем терминале. Команда ps x покажет все ваши процессы, даже те, которых нет в управляющем терминале. Если использовать ps a, то будет получен список процессов из терминалов всех пользователей.

Просмотр «леса» и «деревьев»

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

$ ps x --forest

  PID TTY      STAT   TIME COMMAND
  927 pts/1    S      0:00 bash
 6690 pts/1    S      0:00  \_ bash
26909 pts/1    R      0:00      \_ ps x --forest
19930 pts/4    S      0:01 bash
25740 pts/4    S      0:04  \_ vi processes.txt


«u» и «l» опции ps

Опции u и l могут быть использованы в любой комбинации с опциями a, x с целью получения более подробной информации о процессах:

$ ps au

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
agriffis   403  0.0  0.0  2484   72 tty1     S     2001   0:00 -bash
chouser    404  0.0  0.0  2508   92 tty2     S     2001   0:00 -bash
root       408  0.0  0.0  1308  248 tty6     S     2001   0:00 /sbin/agetty 3
agriffis   434  0.0  0.0  1008    4 tty1     S     2001   0:00 /bin/sh /usr/X
chouser    927  0.0  0.0  2540   96 pts/1    S     2001   0:00 bash

$ ps al

  F   UID   PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
100  1001   403     1   9   0  2484   72 wait4  S    tty1       0:00 -bash
100  1000   404     1   9   0  2508   92 wait4  S    tty2       0:00 -bash
000     0   408     1   9   0  1308  248 read_c S    tty6       0:00 /sbin/ag
000  1001   434   403   9   0  1008    4 wait4  S    tty1       0:00 /bin/sh
000  1000   927   652   9   0  2540   96 wait4  S    pts/1      0:00 bash



Использование top

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

$ top

10:02pm  up 19 days,  6:24,  8 users,  load average: 0.04, 0.05, 0.00
75 processes: 74 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  1.3% user,  2.5% system,  0.0% nice, 96.0% idle
Mem:   256020K av,  226580K used,   29440K free,       0K shrd,    3804K buff
Swap:  136544K av,   80256K used,   56288K free                  101760K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
  628 root      16   0  213M  31M  2304 S       0  1.9 12.5  91:43 X
26934 chouser   17   0  1272 1272  1076 R       0  1.1  0.4   0:00 top
  652 chouser   11   0 12016 8840  1604 S       0  0.5  3.4   3:52 gnome-termin
  641 chouser    9   0  2936 2808  1416 S       0  0.1  1.0   2:13 sawfish



nice

Каждый процесс имеет свое значение приоритета, которое Linux использует для разделения времени CPU. Вы можете указать приоритет процесса при его запуске, с помощью команды nice:

$ nice -n 10 oggenc /tmp/song.wav


С тех пор, как приоритет стал называться nice, он стал легче для запоминания, так, большее значение nice делает «хорошо» (nice — хорошо, замечательно; прим. пер.) другим процессам, позволяя им получить более приоритетный доступ к времени CPU. По-умолчанию, процессы запускаются с приоритетом 0, поэтому установка приоритета в 10 для oggenc значит, что он будет давать больше времени поработать другим процессам. Как правило, это означает, что oggenc даст возможность другим процессам выполняться со своей обычной скоростью, не зависимо от того, сколько времени процессора хочет сам oggenc. Вы могли видеть эти «уровни любезности» в колонке NI у ps и top ранее.

renice

Команда nice может изменять приоритет процессов только во время их запуска. Если вам необходимо изменить приоритет работающего процесса, воспользуйтесь командой renice:

$ ps l 641

  F   UID   PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
000  1000   641     1   9   0  5876 2808 do_sel S    ?          2:14 sawfish

$ renice 10 641
641: old priority 0, new priority 10
$ ps l 641

  F   UID   PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
000  1000   641     1   9  10  5876 2808 do_sel S    ?          2:14 sawfish


Модули ядра

Знакомьтесь, «uname»

Команда uname дает множество интересной информации о вашей системе. Вот пример вывода на моей рабочей машине, после того, как я набрал uname -a, что говорит команде uname напечатать всю имеющуюся информацию:

$ uname -a
Linux inventor 2.4.20-gaming-r1 #1 Fri Apr 11 18:33:35 MDT 2003 i686 AMD Athlon(tm) XP 2100+ AuthenticAMD GNU/Linux


Подробнее о uname

Теперь, давайте посмотрим, какую же информацию о системе может дать uname

тип информации аргумент пример
имя ядра -s "Linux"
имя хоста -n "inventor"
релиз ядра -r "2.4.20-gaming-r1"
версия ядра -v "#1 Fri Apr 11 18:33:35 MDT 2003"
архитектура -m "i686"
процессор -p "AMD Athlon(tm) XP 2100+"
платформа -i "AuthenticAMD"
операционная система -o "GNU/Linux"


Интригующе! А что напечатает uname -a у вас?

Релиз ядра

А теперь небольшой трюк. Для начала выполните uname -r чтобы программа напечатала релиз ядра, которое работает в данный момент.

Теперь посмотрите в директорию /lib/modules и — опа! — Я уверен, что вы обнаружили каталог с точно таким же именем! OK, никакой магии, теперь самое время поговорить о значении каталогов в /lib/modules, а также объяснить, что такое модули ядра.

Ядро

Ядро Linux это сердце того, что обычно называют «Linux» — это кусок кода, который напрямую взаимодействует с вашим железом и абстрагирует от него обычные программы. Благодаря ядру, вашему текстовому редактору не нужно беспокоиться на какой диск, SCSI или IDE, а может даже в RAM, он производит запись. Редактор просто записывает в файловую систему, а ядро заботится обо всем остальном.

Введение в модули ядра

Итак, что такое модули ядра? Они представляют собой часть ядра, которая сохраняется на диске в специальном формате. По вашей команде, они подгружаются в работающее ядро и добавляют в него новую функциональность.

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

Модули ядра вкратце

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

lsmod

Для просмотра загруженных модулей на вашей системе используйте команду lsmod:

# lsmod

Module                  Size  Used by    Tainted: PF
vmnet                  20520   5
vmmon                  22484  11
nvidia               1547648  10
mousedev                3860   2
hid                    16772   0  (unused)
usbmouse                1848   0  (unused)
input                   3136   0  [mousedev hid usbmouse]
usb-ohci               15976   0  (unused)
ehci-hcd               13288   0  (unused)
emu10k1                64264   2
ac97_codec              9000   0  [emu10k1]
sound                  51508   0  [emu10k1]
usbcore                55168   1  [hid usbmouse usb-ohci ehci-hcd]



Список модулей

Как видите, на моей системе загружено достаточно немного модулей. vmnet и vmmon модули, обеспечиваю необходимую функциональность для VMWare Workstation, которая позволяет мне запускать виртуальные машины в окне рабочего стола. Модуль nvidia выпущен NVIDIA corporation и позволяет использовать 3D-ускорение в Linux.

Дальше у меня есть набор модулей, которые используются для поддержки USB устройств ввода — mousedev, hid, usbmouse, input, usb-ohci, ehci-hcd и usbcore. Имеет смысл сконфигурировать ваше ядро для поддержки USB модулей. Почему? Потому что USB девайсы это «plug and play» (подключай и работай) девайсы и если у вас есть поддержка USB в модулях, вы можете спокойно пойти и купить новое USB устройство, подключить его, и ваша система автоматически загрузит соответствующие модули для этого устройства. Это удобный способ сделать что-то.

Сторонние модули

Завершают этот список модули: emu10k1, ac97_codec и sound, которые вместе обеспечиваю поддержку моей звуковой карты Audigy.

Следует отметить, некоторые из моих модулей доступны прямо в исходниках ядра. Например, все USB-модули были скомпилированы из стандартных исходных текстов ядра Linux. Однако, nvidia, emu10k1 и VMWare-модули были получены из других источников. Это подчеркивает другую важную особенность модулей ядра — возможность сторонних производителей добавлять необходимую функциональность в ядро и включать ее прямо в запущенное ядро. Без перезагрузки.

depmod и компания

В моей папке /lib/modules/2.4.20-gaming-r1/, есть несколько
файлов которые начинаются со строки «modules.»:

$ ls /lib/modules/2.4.20-gaming-r1/modules.*
/lib/modules/2.4.20-gaming-r1/modules.dep
/lib/modules/2.4.20-gaming-r1/modules.generic_string
/lib/modules/2.4.20-gaming-r1/modules.ieee1394map
/lib/modules/2.4.20-gaming-r1/modules.isapnpmap
/lib/modules/2.4.20-gaming-r1/modules.parportmap
/lib/modules/2.4.20-gaming-r1/modules.pcimap
/lib/modules/2.4.20-gaming-r1/modules.pnpbiosmap
/lib/modules/2.4.20-gaming-r1/modules.usbmap


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

Как получить модули

Некоторые модули ядра разработаны для работы со специальными устройствами, как например emu10k1 — модуль для поддержки моей звуковой карты. Для этого типа модулей, приведенные выше файлы включают также информацию о PCI IDs и прочие идентификационные метки оборудования, которое они поддерживают. Эта информация может быть использована различными скриптами, например «hotplug» (который мы рассмотрим в следующих руководствах) для автоматического определения оборудования и загрузки соответствующих модулей.

Использование depmod

Информация о зависимостях может становиться не актуальной, особенно в случае установки новых модулей. Чтобы ее обновить, просто введите depmod -a. Программа depmod просканирует модули из вашей папки /lib/modules и обновит информацию о зависимостях. Она делает это сканируя модули в /lib/modules и проверяя так называемые «symbols» внутри модулей.

Расположение модулей ядра

Итак, как выглядят модули ядра? Для ядра 2.4, все файлы модулей обычно находятся в /lib/modules и имеют имя оканчивающееся на ".o" (для 2.6 ".ko" — прим. ред.). Чтобы увидеть все модули из /lib/modules, введите следующее:

# find /lib/modules -name '*.o'
/lib/modules/2.4.20-gaming-r1/misc/vmmon.o
/lib/modules/2.4.20-gaming-r1/misc/vmnet.o
/lib/modules/2.4.20-gaming-r1/video/nvidia.o
/lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o
/lib/modules/2.4.20-gaming-r1/kernel/fs/vfat/vfat.o
/lib/modules/2.4.20-gaming-r1/kernel/fs/minix/minix.o
[список обрезан для краткости]


insmod vs. modprobe

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

# insmod /lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o
# lsmod | grep fat

fat                    29272   0  (unused)



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

rmmod и modprobe в действии

Давайте выгрузим наш модуль fat.o и загрузим его обратно используя modprobe:

# rmmod fat
# lsmod | grep fat
# modprobe fat
# lsmod | grep fat

fat                    29272   0  (unused)



Как видите, работа команды rmmod очень похожа на работу modprobe, но имеет противоположный эффект — она выгружает указанный модуль.

Ваши помощники modinfo и modules.conf

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

# modinfo fat

filename:    /lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o
description: author:      license:     "GPL"



Также обратите внимание на файл /etc/modules.conf. Он содержит настройки для modprobe и позволяет изменять поведение modprobe. Например, указывать какие модули загруть до/после загрузки остальных, запускать скрипты до и после загрузки модуля, и многое другое.

Структура modules.conf

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

Во-первых, многие дистрибутивы генерируют этот файл автоматически из набора файлов в других директориях, таких как /etc/modules.d/. Например, в Gentoo Linux есть такая папка, и запуск команды update-modules прочитает все файлы из /etc/modules.d/ и объединит их в новый /etc/modules.conf. Поэтому, сделав свои изменения в файлах из /etc/modules.d/ запустите update-modules, если вы используете Gentoo. В Debian, процедура очень похожа, за исключением того, что папка называется /etc/modutils/.

Для ядер версии 2.6 аналогичные по функциональности файл и папка из каталога etc называются modprobe.conf и modprobe.d соответственно. Синтаксис там упрощен, смотрите man modprobe.conf
— Примечание редактора.



Итоги и ресурсы

Итоги

Мои поздравления; вы дошли до конца этого учебника по основам администрирования Linux! Надеюсь он помог вам немного систематизировать ваши знания о Linux. Пожалуйста присоединяйтесь к нам в следующем руководстве раскрывающем более продвинутые аспекты администрирования, такие как права доступа, управление пользователями, файловую систему, монтирование и многое другое. В следующем руководстве мы будем опираться на фундамент, заложенный здесь. И помните, продолжая изучать эту серию руководств, вы уже совсем скоро будете готовы сдаче экзаменов на получение сертификата LPIC Level 1 от Linux Professional Institute.

Ресурсы

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