Процесс в Linux (как и в UNIX) — это программа, которая выполняется в отдельном виртуальном адресном пространстве. Когда пользователь регистрируется в системе, под него автоматически создается процесс, в котором выполняется оболочка (shell), например, /bin/bash.

В Linux поддерживается классическая схема мультипрограммирования. При этом Linux поддерживает параллельное (или квазипараллельное при наличии только одного процессора) выполнение процессов пользователя. Каждый процесс выполняется в собственном виртуальном адресном пространстве, т.е. процессы защищены друг от друга и крах одного процесса никак не повлияет на другие выполняющиеся процессы и на всю систему в целом. Один процесс не может прочитать что-либо из памяти другого процесса (или записать в нее) без «разрешения» на то другого процесса. Санкционированные взаимодействия между процессами допускаются системой.

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

В связи с развитием SMP (Symmetric Multiprocessor Architectures) в ядро Linux был внедрен механизм нитей или потоков управления (threads). Нитями также называют «легковесные» процессы. Другими словами, нить — это процесс, выполняемый в виртуальной памяти, которая используется вместе с другими нитями одного и того же «тяжеловесного» процесса. Такой «тяжеловесный процесс» обладает отдельной виртуальной памятью и может иметь несколько «легковесных» процессов.

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

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

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

Если интерпретатору (shell) встречается команда, соответствующая выполняемому файлу, интерпретатор выполняет ее, начиная с точки входа (entry point). Для С-программ entry point — это функция main. Точка входа для каждой среды разработки различна. Запущенная программа тоже может создать процесс, т.е. запустить какую-то программу и ее выполнение тоже начнется с функции main. Затем с помощью системного вызова fork() создается адресное пространство — подготавливается «место» для нового процесса, а потом с помощью вызова ехес() в это адресное пространство загружается программа. Таким образом, каждый новый процесс выполняется в своей индивидуальной среде.

Для создания процессов используется системный вызов: fork(). Вызов fork() создает новое адресное пространство, которое полностью идентично адресному пространству основного процесса. Другими словами, вызов fork() создает новый процесс. После выполнения этого системного вызова вы получаете два абсолютно одинаковых процесса — основной и порожденный. Функция fork() возвращает 0 в порожденном процессе и PID (Process ID — идентификатор порожденного процесса) — в основном. PID — это целое число.

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

В качестве примера рассмотрим следующий фрагмент программы:

if (fork() == 0) wait(0);

else execl("ls", "ls", 0); /* порожденный процесс */

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

1. Выделяется память для описателя нового процесса в таблице процессов.

2. Назначается идентификатор процесса PID.

3. Создается логическая копия процесса, который выполняет fork() — полное копирование содержимого виртуальной памяти родительского процесса, копирование составляющих ядерного статического и динамического контекстов процесса-предка.

4. Увеличиваются счетчики открытия файлов (порожденный процесс наследует все открытые файлы родительского процесса).

5. Возвращается PID в точку возврата из системного вызова в родительском процессе и 0 — в процессе-потомке.

Каждый процесс может порождать полностью идентичный процесс с помощью fork(). Родительский процесс может дожидаться окончания выполнения всех своих процессов-потомков с помощью системного вызова wait. В любой момент времени процесс может изменить содержимое своего образа памяти, используя одну из разновидностей вызова ехес(). Каждый процесс реагирует на сигналы и, естественно, может установить собственную реакцию на сигналы, производимые операционной системой. Приоритет процесса может быть изменен с помощью системного вызова nice.

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

Примеры сигналов:

1. Окончание порожденного процесса (например, из-за системного вызова exit (см. ниже)).

2. Возникновение исключительной ситуации.

3. Сигналы, поступающие от пользователя, при нажатии определенных клавиш.

Установить реакцию на поступление сигнала можно с помощью системного вызова signal:

func = signal(snum, function);

где: snum — номер сигнала;

 function — адрес функции, которая должна быть выполнена при поступлении указанного сигнала.

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

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

kill(pid, snum);

где: pid — идентификатор процесса;

 snum — номер сигнала, который будет передан процессу (см. табл. 5.1).

Pid состоит из идентификатора группы процессов и идентификатора процесса в группе. Если вместо pid указать нуль, то сигнал snum будет направлен всем процессам, относящимся к данной группе (понятие группы процессов аналогично группе пользователей). В одну группу включаются процессы, имеющие общего предка. Идентификатор группы процесса можно изменить с помощью системного вызова setpgrp. Если вместо pid указать –1, то ядро передаст сигнал всем процессам, идентификатор пользователя которых равен идентификатору текущего выполнения процесса, посылающего сигнал. Номера сигналов приведены в табл. 5.1. Сигналы (точнее, их номера) описаны в файле signal.h.

Номера сигналов Таблица 5.1

Для нормального завершения процесса используется вызов:

exit(status)

где status — это целое число, возвращаемое процессу-предку для его информирования о причинах завершения процесса-потомка.

Вызов exit может задаваться в любой точке программы, но может быть и неявным, например, при выходе из функции main (при программировании на С) оператор return 0 будет воспринят как системный вызов exit(0).

Практически все операционные системы обладают механизмом перенаправления ввода/вывода, и Linux не является исключением из этого правила. Обычно программы вводят текстовые данные с консоли (терминала) и выводят данные на консоль. При вводе под консолью подразумевается клавиатура, а при выводе — экран монитора. Клавиатура и экран монитора — это, соответственно, стандартный ввод и вывод (stdin и stdout). Любой ввод/вывод можно интерпретировать как ввод из некоторого файла и вывод в файл. Работа с файлами производится через их дескрипторы.

Для организации ввода/вывода в UNIX используются три файла: stdin (дескриптор 0), stdout (дескриптор 1) и stderr (дескриптор 2).

Символ > («больше») используется для перенаправления стандартного вывода в файл. Например:

$ cat > newfile.txt

В этом примере стандартный вывод команды cat будет перенаправлен в файл newfile.txt, который будет создан после выполнения этой команды. Если файл с этим именем уже существует, то он будет перезаписан. Нажатие Ctrl + D остановит перенаправление и прервет выполнение команды cat.

Символ < («меньше») используется для переназначения стандартного ввода команды. Например, при выполнении команды cat < file.txt в качестве стандартного ввода будет использован файл file.txt, а не клавиатура.

Символ >> используется для присоединения данных в конец файла (append) стандартного вывода команды. Например, в отличие от случая с символом >, выполнение команды cat >> newfile.txt не перезапишет файл в случае его существования, а добавит данные в его конец.

Чтобы перенаправить весь стандартный поток ошибок в какой-нибудь файл, используйте переадресацию 2> имя файла или 2>> имя файла. В первом случае стандартный поток ошибок будет передан в файл или на устройство, а во втором — поток ошибок будет добавлен в файл, если такой существует. При использовании переадресации 2>&1 стандартный поток ошибок будет перенаправлен на стандартный вывод интерпретатора Bourne (здесь 1 и 2 — дескрипторы файлов). Для перенаправления стандартного потока ошибок в файл вы можете также использовать переадресацию >& имя_файла (интерпретатор C-Shell).

В командных интерпретаторах Korn и C-Shell можно использовать переадресацию >! имя_файла. При этом файл не будет перезаписан, если он существует.

Символ | используется для перенаправления стандартного вывода одной программы на стандартный ввод другой. Например,

ps –ax | grep httpd.

Можно также использовать переадресацию |&. В этом случае стандартный поток ошибок будет передан по каналу другой команде интерпретатора.

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

Параметры программы ps Таблица 5.2

Например, после ввода команды ps –а вы увидите примерно следующее:

PID  TTY   TIME     CMD

1007 tty1  00:00:00 bash

1036 tty2  00:00:00 bash

1424 tty1  00:00:02 me

1447 pts/0 00:00:02 mpg123

2309 tty2  00:00:00 ps

Для вывода информации о конкретном процессе вы можете воспользоваться командой:

# ps –ax | grep httpd

698  7 S 0:01 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1261 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1262 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1263 9 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1264 9 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1268 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1269 ? S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1270 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1271 9 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1272 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1273 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

1280 9 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

В приведенном выше примере используется перенаправление ввода/вывода между программами ps и grep, в результате чего будет отображена информация обо всех процессах, содержащих в строке запуска «httpd». Данную команду (ps –ax | grep httpd) я написал только лишь в демонстрационных целях — гораздо проще использовать параметр –С программы ps вместо перенаправления ввода/вывода и параметр –е вместо –ах.

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

# top

7:49pm up 5 min, 2 users, load average: 0.03, 0.20, 0.11

56 processes: 55 sleeping, 1 running, 0 zombie, 0 stopped

CPU states: 7.6% user, 9.8% system, 0.0% nice, 82.5% idle

Mem 130660K av, 94652K used, 36008K free, OK shrd, 5220K buff

Swap:72256K av, 0K used, 72256K free 60704K cached

PID  USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND

1067 root 14  0  892  892 680   R    2.8  0.6  0:00 top

1    root 0   0  468  468 404   S    0.0  0.3  0:06 init

2    root 0   0  0    0   0     SW   0.0  0.0  0:00 kflushd

3    root 0   0  0    0   0     SW   0.0  0.0  0:00 kupdate

4    root 0   0  0    0   0     SW   0.0  0.0  0:00 kswapd

Просмотреть информацию об оперативной памяти вы можете с помощью команды free, а о дисковой — с помощью команды df. Информация о зарегистрированных в системе пользователях доступна по команде w.

Существует графический аналог программы top — gtop (см. рис. 5.1).

Формат использования:

nice [-коэффициент понижения] команда [аргумент]

Рис. 5.1. Программа gtop

Команда nice выполняет указанную команду с пониженным приоритетом, коэффициент понижения указывается в диапазоне 1..19 (по умолчанию он равен 10). Суперпользователь может повышать приоритет команды, для этого нужно указать отрицательный коэффициент, например —10. Если указать коэффициент больше 19, то он будет рассматриваться как 19.

Формат использования:

nohup команда [аргумент]

Команда nohup выполняет запуск команды в режиме игнорирования сигналов. Не игнорируются только сигналы SIGHUP и SIGQUIT.

Формат использования:

kill [-номер сигнала] PID

где PID — идентификатор процесса, который можно узнать с помощью команды ps.

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

Команда jobs выводит список процессов, которые выполняются в фоновом режиме, fg — переводит процесс в нормальный режим («на передний план» — foreground), a bg — в фоновый. Запустить программу в фоновом режиме можно с помощью конструкции

<команда> &

Механизм расписаний Linux (UNIX) предоставляет удобные и мощные средства для обслуживания системы. Например, можно создать расписание резервирования данных в нерабочее время или обновления системы через Интернет.

Для запуска команд по расписанию используется демон cron. Он запускается автоматически из файла /etc/init.d при многопользовательском уровне запуска. Об уровнях запуска поговорим немного позже. Каждую минуту cron пробуждается и проверяет содержимое файлов crontab. Для какой-то определенности назовем эти файлы файлами расписаний.

Демон cron имеет свою буферную область (каталог /var/spool/cron/), в которой находятся файлы crontab — файлы расписаний. Имена файлов расписаний соответствуют именам пользователей из файла /etc/passwd. Если cron найдет файлы расписаний, он загрузит их в память. К этим файлам не должно быть прямого доступа, редактировать их можно с помощью программы crontab.

Когда демон cron выполняет команду, он посылает по почте сообщение владельцу файла crontab или пользователю, указанному в переменной MAILTO файла crontab.

Программа crontab используется для редактирования файлов расписаний отдельных пользователей. Программа позволяет устанавливать, удалять, редактировать и просматривать файлы расписаний. Например, для установки файла расписаний используется команда:

crontab –u user file.cron

Если не использовать опцию –u, то будет установлен файл расписания для пользователя, запустившего программу.

Каждый пользователь может иметь файл расписания. Для того, чтобы использовать эту возможность, пользователь должен быть прописан в файле /var/spool/cron.allow, если такой существует. Программу crontab можно запускать с опциями, приведенными в табл. 5.3.

Примечание. Последние версии демона crond используют файл /etc/cron.allow вместо файла /var/spool/cron.allow и файл/etc/cron.deny вместо файла /var/spool/cron.deny. В файле /etc/cron.allow содержится списокразрешенных пользователей, в файле /etc/cron.deny — запрещенных.

Опции программы crontab Таблица 5.3

Каждая строка файла расписания имеет такой формат:

время_выполнения действие

Время выполнения состоит из пяти полей. В первом поле задаются минуты (0…59), во втором — часы (0…23), в третьем — день месяца (1…31), в четвертом — номер месяца (1…12), а в пятом день недели (0…6, 0 соответствует воскресенью). В любом из этих полей можно поставить звездочку, которая обозначает все возможные значения. Например, следующая запись означает, что архивирование каталога /etc будет производиться каждый день, кроме воскресенья, в семь часов утра:

0 7 * * 1-6 tar cfz /backup /etc

В системе используется системный файл расписания — это /etc/crontab (см. листинг 5.1).

# Интерпретатор команд

SHELL=/bin/bash

# Путь для поиска команд

PATH=/sbin:/bin:/usr/sbin:/usr/bin

# Отчет о выполнении расписания будет отправлен

# пользователю root

MAILTO=root

# Домашний каталог

НОМЕ=/

# run-parts

01 * * * * root run-parts /etc/cron.hourly

02 4 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly

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

Еще одним способом планирования задач является использование демона atd. Этот демон используется для отложенного выполнения заданий. Для постановки заданий в очередь используются команды at и batch. Чтобы добавить задание в очередь используйте команду:

at время дата

После этого введите все команды, которые хотите выполнить. Для окончания ввода нажмите Ctrl+D. Более подробно о формате задания времени и даты вы можете прочитать в справочной системе. Например, для выполнения команд в 13:00 введите команду:

at 1pm

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

ОС Linux имеет шесть уровней выполнения, а также три уровня выполнения по требованию.

Программа init переключает систему в нужный режим работы (на нужный уровень выполнения), и ее имеет право использовать только пользователь root. Для переключения на уровень n достаточно ввести команду:

# init n

Иногда, при небольшом изменении файла /etc/inittab, нужно заново перечитать таблицу инициализации (inittab). Для этого воспользуйтесь командой:

init q

Помните, что вы в любой момент можете изменить файл /etc/inittab и перечитать его заново командой

init q.

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

init: init s

Описание уровней приведено в табл. 5.4.

Уровни выполнения Таблица 5.4

Файл /etc/inittab описывает, какие процессы должны запускаться во время загрузки и на протяжении нормальной работы системы. Программа init переключает уровни выполнения системы. Корректными номерами уровней системы являются 0…6, а также А, В и С.

Каждая строка файла /etc/inittab должна быть записана в формате:

id:уровни_выполнения:действие:процесс

Поле «Id» (идентификатор) — уникальная последовательность из четырех символов (в старых дистрибутивах длина имени идентификатора ограничена двумя символами).

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

Поле «действие» — задает действие, которое будет выполнено.

Поле «процесс» — определяет процесс, который будет выполнен.

В качестве значений поля «уровни_выполнения» могут быть указаны номера уровней выполнения без каких-либо разделителей. Например, значение данного поля 1235 означает, что указанное действие будет применено к уровням 1, 2, 3 и 5. В качестве дополнительных уровней, которые называются уровнями по требованию (ondemand), могут быть указаны уровни А, В и С.

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

Действия над процессами, задаваемые в файле /etc/inittab Таблица 5.5

Теперь рассмотрим листинг обычного файла /etc/inittab (см. листинг 5.2).

id:5:initdefault:

si::sysinit:/etc/rc.d/rc.sysinit

10:0:wait:/etc/re.d/rc 0

11:1:wait:/etc/re.d/rc 1

12:2:wait:/etc/re.d/rc 2

13:3:wait:/etc/re.d/rc 3

14:4:wait:/etc/re.d/rc 4

15:5:wait:/etc/re.d/rc 5

16:6:wait:/etc/re.d/rc 6

# Things to run in every runlevel.

ud::once:/sbin/update

# Trap CTRL-ALT-DELETE

ca::ctrlaltdel:/sbin/shutdown –t3 –r now

pf::powerfail:/sbin/shutdown –f –h +2 "Power Failure; System Shutting Down"

pr:12345:powerokwait:/sbin/shutdown –c "Power Restored; Shutdown Cancelled"

1:2345:respawn:/sbin/mingetty tty1

2:2345:respawn:/sbin/mingetty tty2

3:2345:respawn:/sbin/mingetty tty3

4:2345:respawn:/sbin/mingetty tty4

5:2345:respawn:/sbin/mingetty tty5

6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5

# xdm is now a separate service

x:5:respawn:/etc/X11/prefdm –nodaemon

Рассмотрим подробно приведенный пример. Самая первая строка определяет уровень выполнения по умолчанию. Очень рекомендую вам установить это значение. Во-первых, вводить уровень загрузки каждый раз при запуске системы не очень удобно. Во-вторых, если не установлен уровень выполнения по умолчанию, система не сможет запускаться автоматически: при загрузке она будет ждать ввода номера уровня выполнения. Для загрузки системы подойдут два уровня: или 3, или 5. Я рекомендую использовать третий уровень выполнения, использовать уровень выполнения 5 нужно только в том случае, если вы хотите, чтобы система X Window запускалась автоматически при старте системы.

Затем указываются программы, которые будут выполнены во время системной инициализации (sysinit). В нашем случае будет запушен сценарий загрузки системы /etc/re.d/rc.sysinit.

Далее следуют описания действий для каждого из уровней выполнения. Например, для уровня выполнения номер 5 будет запущен сценарий /etc/re.d/rc с параметром 5. Программа init будет ждать завершения процесса /etc/re.d/rc.

Программа /sbin/update будет запускаться на каждом из уровней выполнения один раз.

Реакция на нажатие комбинаций клавиш Ctrl+Alt+Del устанавливается с помощью действия ctrlaltdel. Будет запущена программа shutdown для немедленной (now) перезагрузки (-r) системы. Задержка перед переключением на шестой уровень (перезагрузка) составит три секунды (-t3).

Реакция на перебои с питанием устанавливается с помощью действий powerfail и powerokwait. В качестве реакции на событие powerfail будет запущена программа shutdown для останова системы (-h). Опция –f указывает, что при перезагрузке будет пропущена проверка файловой системы с помощью fsck. Задержка перед переключением на шестой уровень выполнения составит две минуты (+2). На всех активных терминалах пользователи увидят сообщение «Power Failure; System Shutting Down». Если в течение двух минут питание будет восстановлено, запустится программа shutdown для отмены останова системы (-с). На терминалах пользователей будет отображено сообщение «Power Restored; Shutdown Cancelled».

Наглядным примером для действия respawn может послужить система X Window. Можете провести такой эксперимент: перейдите на уровень выполнения 5: init 5

Если уровень 5 уже активен, этого делать, естественно, не нужно. Находясь в системе X Window, нажмите Ctrl+Alt+Backspace — эта комбинация клавиш используется для экстренного останова системы X Window. После останова система X Window будет перезапущена.

Все Red Hat-подобные системы, в отличие от BSD-подобных (Slackware), используют систему инициализации SysV, хотя и несколько переработанную.

Примечание. Система инициализации —это набор файлов, необходимых для запуска операционной системы. Обычно система инициализации представляет собой сценарии загрузки системы. В процессе развития Unix (см. гл. 1) выделились два основных типа систем — BSD-подобные системы и SysV-совместимые. Первые были совместимы (полностью или частично) с операционной системой BSD, разработанной Калифорнийским университетом, а вторые использовали в качестве своего предка операционную систему Unix System V, разработанную компанией AT&T. Системы инициализации BSD и SysV отличаются набором входящих в них файлов и их назначением.

Запуск и останов демонов осуществляется с помощью сценариев, расположенных в каталоге /etc/re.d/init.d. Демон — это программа, которая в фоновом режиме периодически выполняет какие-нибудь действия. Например, демон ftpd непрерывно проверяет наличие пользовательских запросов на соединение по протоколу FTP.

Сценарии каталога /etc/re.d выполняются автоматически при запуске системы. В этом каталоге есть несколько подкаталогов rcN.d, где N — это номер уровня выполнения. В большинстве случаев у вас будет установлен уровень 5 в качестве уровня по умолчанию. Этот уровень соответствует многопользовательскому режиму с автоматическим запуском системы X Window. В каталоге /etc/rd.d/rc5.d находятся символические ссылки на сценарии, расположенные в каталоге /etc/rc.d/init.d.

Для запуска какого-нибудь демона нужно выполнить соответствующий ему сценарий в каталоге /etc/rc.d/init.d с опцией start. Для останова нужно запустить тот же сценарий, но с опцией stop.

Чтобы обеспечить автоматический запуск какого-нибудь сервера, нужно создать сценарий для его запуска и поместить его в каталоге /etc/rc.d/init.d. Затем, в зависимости от уровня выполнения, в каталоге rcN.d нужно создать символическую ссылку на этот сценарий.

Для выбора демонов, которые будут запускаться автоматически при загрузке системы, обычно используют программу drakconf в операционной системе Linux Mandrake (см. рис. 5.2) или программу setup в ОС Red Hat Linux.

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

Рис. 5.2. Конфигуратор DrakConf

#!/bin/bash

# Шаблон для запуска демона

# Подключаем библиотеку функций

. /etc/init.d/functions

# Определяем параметры

case "$1" in

start)

 # Запуск демона

 echo "Starting my_daemon…"

 daemon my_daemon

 touch /var/lock/subsys/my_daemon

 ;;

stop)

 # Останов демона

 kill proc my_daemon

 rm –f /var/lock/subsys/my_daemon

 rm –f /var/run/my_daemon.pid

 ;;

status)

 # Выводим статистику работы

 ;;

restart | reload)

 # действия, выполняемые при перезагрузке демона

 :

 ;;

*)

 # Произошел вызов без параметров

 echo "Usage: my_daemon {start|stop|status|restart|reload}"

 exit 1

esac

exit 0

Теперь рассмотрим весь процесс загрузки системы, начиная с самого начала: от включения питания. Итак, вы включаете питание, система выполняет процедуру самотестирования POST (Power On Self Test). Если во время самотестирования ошибок обнаружено не было, из главной загрузочной записи MBR (Master Boot Record) вызывается загрузчик операционной системы. Поиск загрузчика происходит на загрузочных устройствах в соответствии с последовательностью загрузки (Boot Sequence). Данная последовательность определяется в программе настройки компьютера — SETUP. Например, у вас может быть установлена такая последовательность загрузки:

FLOPPY, HDD-0, CDROM

В этом случае система сначала будет искать загрузчик на дискете (диск А, устройство /dev/fd0). Если в дисководе нет дискеты, система перейдет к поиску загрузчика на первом жестком диске (HDD-0, устройство /dev/hda). Если же в дисководе есть дискета, но она не является загрузочной, вы получите соответствующее сообщение об этом. На этом этапе вы можете либо сменить дискету, либо вообще извлечь ее из дисковода, чтобы разрешить системе произвести поиск загрузчика операционной системы на жестком диске. Если и на жестком диске не будет обнаружен загрузчик, система перейдет к следующему элементу загрузочной последовательности — CDROM.

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

После того, как пользователь выберет нужное ему ядро, загрузка системы будет продолжена. Сначала будет загружаться ядро, а потом — программа init. Для полноты рассмотрения процесса загрузки я буду считать, что у нас установлен уровень управления 5.

Первыми будут выполнены процессы, которые указаны в действии sysinit файла /etc/inittab. Затем — процессы, перечисленные с помощью действий boot и bootwait (см. п. 5.5).

Обычно для действия sysinit выполняется сценарий загрузки /etc/re.d/rc.sysinit:

si::sysinit:/etc/rc.d/rc.sysinit

На данном этапе загрузки системы (sysinit) выполняются следующие действия:

1. Устанавливается имя машины (hostname).

2. Конфигурируются параметры ядра.

3. Устанавливается раскладка клавиш и системный шрифт.

4. Активируются разделы подкачки.

5. Корневая система проверяется программой fsck. Если будут найдены ошибки, которые невозможно исправить автоматически, будет запрошен пароль администратора для входа в административный режим, что равноценно переходу на уровень выполнения 1. В этом режиме вы запустите программу fsck с параметром /, который означает проверку корневой файловой системы. После исправления всех ошибок введите команду exit для перезагрузки системы. Если программа fsck ошибок не обнаружила, файловая система монтируется в режиме чтение/запись.

6. Проверяются зависимости модулей ядра.

7. Выполняется проверка других файловых систем.

8. Монтируются локальные файловые системы.

9. Включаются квоты.

10. Подключается (не активизируется!) раздел подкачки. С этого момента система начинает использовать раздел подкачки.

После выполнения сценария загрузки /etc/re.d/rc.sysinit выполняется сценарий /etc/re.d/rc. Этому сценарию передается один параметр –номер уровня выполнения. В рассматриваемом случае — это номер 5, поэтому будет выполнена команда:

/etc/re.d/rc 5

Разумеется, данный сценарий будет выполнен при наличии в вашем файле /etc/initab строки:

15:5:wait:/etc/re.d/rc 5

Вы можете определить любое другое действие для уровня выполнения 5. Однако я не рекомендую вам этого делать: если вы написали свой сценарий загрузки, который работает лучше, чем предлагаемый разработчиками дистрибутива по умолчанию, значит, вам самое время написать свой дистрибутив! Запуск пятого уровня выполнения подразумевает запуск сценариев из каталога /etc/re.d/rc5.d/.

После выполнения этого сценария будет выполнен сценарий /etc/re.d/rc. local. Данный сценарий всегда выполняется последним, вне зависимости от уровня выполнения.

После запуска сценариев пятого уровня выполнения создаются виртуальные консоли и запускается менеджер дисплеев системы X Window (xdm).

В любой Unix-системе есть стандартные файлы протоколов (журналов), расположение которых может изменяться в зависимости от операционной системы. В Linux они находятся в каталоге /var/log. К стандартным протоколам относятся следующие файлы:

secure

auth.log

boot.log

dmesg

messages

syslog

В подкаталогах каталога /var/log находятся журналы (протоколы) других программ, например, в каталоге /var/log/kernel находятся журналы ядра, а в /var/log/httpd — журналы HTTP-сервера. По большому счету расположение журналов зависит от настройки соответствующих им программ, но в стандартном виде все они находятся в каталоге /var/log и его подкаталогах. Назначение стандартных журналов представлено в табл. 5.6. Подробно файлы журналов будут рассмотрены в следующем пункте (п. 5.8), в котором мы научимся управлять процессом протоколирования.

Стандартные журналы Таблица 5.6

Этот раздел посвящен демону syslogd, а также управлению протоколированием сообщений системы и ядра с помощью этого демона. Прежде всего следует отметить, что демон находится в пакете sysklogd (если вы, конечно, используете Red Hat-совместимую систему), поэтому перед его использованием нужно установить этот пакет. В большинстве случаев у вас пакет уже будет установлен, а демон syslogd запущен. Чтобы проверить этот факт, введите команду syslogd. Если демон запущен, то в ответ вы должны получить сообщение:

syslogd: Already running.

Убедиться в том, что демон запущен, можно также с помощью команды:

ps –ax | grep syslogd

Обратите внимание, что в пакет sysklogd на самом деле входят две программы: syslogd и klogd. Программа syslogd отвечает за протоколирование сообщений системы, a klogd — ядра.

Демон syslogd (system logging-deamon) обеспечивает вид протоколирования, который поддерживается большинством программ. При этом демон syslogd пишет сообщения в файл /var/log/syslog. Записи в этом файле обычно содержат такие поля: дата и время, хост, программа, сообщение. Пример этого файла представлен ниже:

Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-service-1-0

Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-slot-1

Jan 27 17:12:28 dhsilabs kernel: VFS: Disk change detected on device ide1(22,64)

Jan 27 17:12:31 dhsilabs kernel: ISO 9660 Extensions: Microsoft Joliet Level 1

Jan 27 17:12:31 dhsilabs kernel: ISOFS: changing to secondary root

Jan 27 17:12:32 dhsilabs kernel: VFS: Disk change detected on device fd(2,0)

Jan 27 17:12:32 dhsilabs kernel: end_request: I/O error, dev 02:00 (floppy), sector 0

Например, из предпоследней записи мы можем узнать, что 27-го января 2002 года в 17:12 произошла смена носителя в устройстве fd, о чем нам любезно сообщило ядро системы (запись «программа» — kernel). А носитель (дискета) оказался подпорченным, о чем свидетельствует следующая запись — ошибка ввода/вывода (I/O error, dev 02:00 (floppy), sector 0).

Демон syslogd запускается автоматически при старте системы. Для его запуска предназначен сценарий /etc/rc.d/init.d/syslog. Как обычно, запустить демон самостоятельно вы можете с помощью команды: /etc/rc.d/init.d/syslog start, а остановить — /etc/rc.d/init.d/syslog stop. Для обеспечения автоматической загрузки нужно создать символическую ссылку на этот файл, например:

ls –s /etc/re.d/rc5.d/@S30syslog /etc/rc.d/init.d/syslog.

В этом случае вы обеспечите запуск демона на пятом уровне запуска (автоматический запуск X Window). Если вы используете Linux Mandrake, включить и отключить автоматический запуск вы можете с помощью команды drakxservices. При использовании Linux Red Hat включите автозапуск демона с помощью конфигуратора setup. Демон syslogd можно запускать с опциями, указанными в табл. 5.7.

В табл. 5.7 указаны не все опции демона. Назначение всех остальных опций вы можете найти в справочной системе, введя команду man syslogd.

Опции демона syslogd Таблица 5.7

Демон syslogd реагирует на следующие сигналы: SYGTERM, SIGINT, SIGQUIT, SIGHUP, SIGUSR1, SIGCHLD. Реакция демона на сигналы описана в табл. 5.8.

Реакция демона на сигналы Таблица 5.8 

По умолчанию используется файл конфигурации /etc/syslog.conf. Кроме этого вы можете указать другой файл конфигурации с помощью опции –f. Давайте рассмотрим установки демона на примере обычного файла конфигурации (см. листинг 5.4).

# Протоколирование аутентификации. Файл протокола /var/log/auth.log

auth,authpriv.* /var/log/auth.log

#  Префикс "-" используется, если вы хотите синхронизировать

#  файл после каждой записи в него.

*.*;auth,authpriv.none –/var/log/syslog

# Сообщения пользовательских программ

user.* –/var/log/user.log

#  Протоколировать все (кроме mail (почты)) . Уровень info и выше.

#  Частные (private) сообщения протоколироваться не будут (попе)

*.info;mail.none;authpriv.none –/var/log/messages

#  Файл регистрации частных сообщений имеет ограниченный доступ.

#  Обычно в этот файл записываются сообщения об удаленном доступе к этой

# машине, например, сообщения от демона FTP о том, какие пользователи и

#  когда регистрировались на данном сервере.

authpriv.* /var/log/secure

#  Протоколирование почты

# Уровень отладки, информации и замечаний

mail.=debug;mail.=info;mail.=notice –/var/log/mail/info

# Уровень предупреждений

mail.=warn –/var/log/mail/warnings

# Уровень ошибок

mail.err –/var/log/mail/errors

# Протоколирование демона cron. Уровни отладки, информации,

# предупреждений и ошибок

cron.=debug;cron.=info;cron.=notice –/var/log/cron/info

cron.=warn –/var/log/cron/warnings

cron.err –/var/log/cron/errors

# Протоколирование ядра

kern.=debug;kern.=info;kern.=notice –/var/log/kernel/infо

kern.=warn –/var/log/kernel/warnings

kern.err –/var/log/kernel/errors

# Протоколирование очереди печати

lpr.=debug;lpr.=info;lpr.=notice –/var/log/lpr/info

lpr.=warn –/var/log/lpr/warnings

lpr.err –/var/log/lpr/errors

# Протоколирование новостей

news.=debug;news.=infо;news.=notice –/var/log/news/info

news.=warn –/var/log/news/warnings

news.err –/var/log/news/errors

# Протоколирование демонов

daemon.=debug;daemon.=info;daemon.=notice –/var/log/daemons/infо

daemon.=warn –/var/log/daemons/warnings

daemon.err –/var/log/daemons/errors

# Критические сообщения *.emerg *

#  Сохранять ошибки почты и новостей (уровень err и выше)

#  в отдельном файле

uucp,news.crit –/var/log/spooler

# Загрузочные сообщения

local?.* –/var/log/boot.log

Как вы уже заметили, файл конфигурации состоит из двух полей: объект протоколирования и файл, в который будут записываться сообщения, порождаемые этим объектом. Для каждого объекта можно указать один из уровней протоколирования: debug, info, notice, warn, err. Первые три относятся к информационным сообщениям. Уровень warn — это предупреждения, а err — ошибки. Существуют специальные сообщения — критические. Обычно они выводятся прямо на консоль.

Как для обозначения объектов, так и для обозначения уровней протоколирования можно использовать символ *, который обозначает все объекты или все уровни. Например, если вы хотите протоколировать все сообщения демонов в файл /var/log/daemons, то используйте такую конструкцию: daemon.* /var/log/daemons.

Пример протоколирования всех сообщений уровня emerg (критический уровень) приведен выше. Если вы хотите отправлять сообщения не в файл, а в поименованный канал (FIFO), используйте символ | перед именем файла-потока.

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

Для передачи сообщений используется протокол UDP. Он менее надежный, чем TCP, но отправление пакетов происходит несколько быстрее. Начните с того, что убедитесь, не закомментирована ли следующая строка в вашем файле /etc/services:

syslog 514/udp

Затем необходимо внести некоторые коррективы в файл конфигурации. Как и прежде, определите объекты протоколирования, а вместо файлов протоколов используйте параметр @hostname, где hostname — это имя компьютера, на который будут перенаправлены сообщения. Например, для перенаправления всех сообщений об ошибках на узел сети hostname можно использовать такую запись:

*.err @hostname

Для перенаправления всех сообщений используется запись:

*.* @hostname

Имя узла желательно указать в файле /etc/hosts, так как демон syslogd может быть запущен после сервера доменных имен или сервер DNS окажется недоступным.

Вы можете организовать центральный сервер протоколирования для всей вашей локальной сети. Для того, чтобы указать, какие хосты вы хотите протоколировать, используйте опцию –l список_хостов. В списке указываются простые имена машин, то есть без указания имени домена. Имена машин разделяются двоеточием (:). Возможно, вы также захотите использовать опцию –s для указания дополнительного сокета для прослушивания. Для перенаправления сообщений используйте опцию –r на машине-клиенте, при этом сообщения будут перенаправлены на сервер (см. табл. 5.7).

Демон klogd предназначен для перехвата и протоколирования сообщений ядра Linux (klogd расшифровывается как kernel-logging daemon). В своей работе вы можете использовать параметры демона, указанные в табл. 5.9.

Параметры демона klogd Таблица 5.9

Для просмотра сообщений ядра используется команда dmesg. Обычно она используется так:

dmesg | less

Данная команда выводит сообщения ядра при запуске системы. С помощью параметра –с этой команды можно очистить ring-буфер ядра. Параметр –n задает уровень сообщений, которые будут выводиться на консоль.

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

Демон реагирует на сигналы: SIGHUP, SIGKILL, SIGINT, SIGTERM, SIGTSTP, SIGUSR1, SIGUSR2, SIGCONT. Сигналы SIGTSTP и SIGCONT используются для начала и завершения протоколирования сообщений ядра. Сигналы SIGUSR1 и SIGUSR2 аналогичны опциям –i и –I соответственно. То есть первый перезагружает информацию о модулях, а второй статическую информацию и информацию о модулях. Использовать сигнал GIGUSR1 (как и все остальные) можно так:

# kill –USR1 PID

Параметр debug ядра Linux задает уровень отладки. Сообщения ядра (важные и не очень) передаются через функцию prinfk(). Если сообщение очень важное, то его копия будет передана на консоль, а также демону klogd для регистрации сообщения на жестком диске. Сообщения передаются на консоль, потому что иногда невозможно запротоколировать сообщение на жестком диске (например, отказ диска).

Предел того, что будет отображаться на консоли, задается переменной console_loglevel. По умолчанию на консоли отображается все, что выше уровня DEBUG (7). Список уровней можно найти в файле kernel.h.