Запуск и остановка системы

Запуск и остановка: различия между Solaris и другими UNIX

Во-первых, Solaris относится к System V системам, и поэтому процедуры его запуска и остановки, а также файлы конфигурации и системные скрипты, используемые для этих процедур, в корне отличаются от таковых в системах BSD. Здесь не рассматриваются системы BSD, для изучения отличия между System V и BSD системами имеет смысл обратиться к книге [1] или другой литературе, в том числе к источникам в Интернете.

Во-вторых, Solaris отличается от собратьев по ветви System V наличием специального режима работы системы, который называется s или S. Ниже этот режим описан подробнее. В большинстве систем System V остальные семь режимов работы (0-6) имеют аналогичное назначение. Некоторые системы, например, многие из систем Linux, имеют несколько иную структуру каталогов системных скриптов. Так, в Solaris скрипты находятся в /etc/rc0.d, /etc/rc1.d и т.д., а в Linux – в /etc/rc.d/rc0/, /etc/rc.d/rc1/ и т.д. Однако, для того, чтобы уточнить местоположение этих скриптов в любой из систем System V, достаточно изучить man init.

В-третьих, Solaris обладает самой большой коллекцией программ для изменения режима работы системы: shutdown, reboot, halt, poweroff, init. В других системах не всегда есть полный набор этих программ, однако, в системах System V всегда присутствуют программы init и shutdown. Они всегда имеют одинаковое назначение, независимо от названия и поставщика ОС, хотя их ключи иногда могут несколько отличаться.

Повторимся еще раз: общие принципы загрузки и остановки системы очень схожи для всех систем UNIX ветви System V, особенности вашей системы всегда можно понять из man init, man shutdown.

Начиная с Solaris 10, в Solaris появилась новая подсистема Service Management Facility (SMF), которая непосредственно связана с загрузкой системы и управлением постоянно работающими в системе службами. Идея SMF состоит в том, что в Solaris поддерживается общесистемная база данных о взаимосвязях между различными службами и отдельный системный процесс отслеживает состояние служб. Благодаря SMF порядок загрузки Solaris изменился: теперь стартовые скрипты играют значительно меньшую роль, и управление тем, какие именно службы должны запуститься, полностью передано SMF. Для просмотра и модификации настроек служб начиная с Solaris 10 следует использовать команды svcs, svcadm и svccfg.

Режимы работы системы

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

Для того, чтобы системе было легче переключаться между разными наборами программ, которые используются для разных типов задач, была придумана концепция режимов работы системы. Любой UNIX ветви System V, в том числе и Solaris, может работать в одном из семи режимов. Каждый режим характеризуется своим назначением, которое определяет набор программ, выполняющихся в этом режиме. В Solaris используется восемь режимов (0-6 и S или s, режимы s и S – это одно и то же).

Режим работы системы (runlevel) иногда также называют состоянием (state) или уровнем выполнения. Фактически, набор программ, запускаемых в том или ином режиме, определяется соджержимым файла /etc/inittab. В этом файле указываются стартовые скрипты, которые будут автоматически запускаться при переходе к каждому из уровней выполнения. Эти скрипты расположены в каталоге /etc, и из них вызываются другие скрипты, которые лежат в каталогах /etc/rcN.d. ( N – число от 0 до 6 или символ S)

При переходе к режиму 0 выполняется /etc/rc0, к режиму 1 – /etc/rc1 и так далее. Далее даны описания всех возможных режимов работы Solaris.

Режим 0

Система останавливается, управление переходит к программе из ПЗУ (firmware) для компьютеров архитектуры SPARC, для компьютеров x86 – система останавливается и может быть перезагружена нажатием любой клавиши. В состоянии 0 компьютер можно выключить без опасений за сохранность данных.

Режим 1

Административный режим. Файловые системы, необходимые для многопользовательской работы, смонтированы, и можно использовать регистрационные имена, требующие доступа к многопользовательским файловым системам. Запущены некоторые демоны, однако пользователям не разрешено входить в систему. Режим 1 используется для установки пакетов ПО.

Режим s, S

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

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

Режим 2

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

Режим 3

Многопользовательский режим; кроме того, что разрешено в режиме 2, добавлен доступ к локальным ресурсам через сеть (поддерживается разделение каталогов с помощью NFS).

Режим 4

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

Режим 5

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

Режим 6

Останавливает и перезагружает операционную систему в состояние, определяемое записью initdefault в файле /etc/inittab. При необходимости конфигурирует перед перезагрузкой новый загружаемый образ ядра операционной системы. Для пересборки ядра после модификации параметров ядра или добавления новых устройств следует выполнить команду

touch /reconfigure

перед перезагрузкой.

Этапы работы системы

Кроме режимов, которые характерны для всех систем UNIX, подобных System V, в Solaris начиная с версии Solaris 10 введено понятие "этапов" (milestone). Как и понятие "режим", понятие "этап" связано с набором приложений, выполняющихся в системе. Разные этапы предполагают функционирование разных наборов служб. Переход от одного этапа к другому и объявление одного из этапов "этапом по умолчанию" (т.е. таким, к которому система должна прийти в результате нормальной загрузки) выполняется так же, как и другие виды управления службами с использованием SMF, т.е. командами svcs, svcadm и svccfg.

Более подробно об этапах рассказано в лекции 13 курса "Системное администрирование ОС Solaris 10" "Управление службами с помощью SMF".

В связи с появлением концепции этапов работы порядок загрузки системы изменился, равно как и действия, которые выполняет init, так как значительная часть функций по управлению службами перешла от init к svc.startd. Понятие "режима работы" при этом сохранилось. Теперь, начиная с Solaris 10, при загрузке системы после загрузки ядра в память компьютера происходит следующее:

TZ=Europe/Moscow
CMASK=022
LC_COLLATE=ru_RU.UTF-8
LC_CTYPE=ru_RU.UTF-8
LC_MESSAGES=C
LC_MONETARY=ru_RU.UTF-8
LC_NUMERIC=ru_RU.UTF-8
LC_TIME=ru_RU.UTF-8

Начальная загрузка системы

Загрузка Solaris 10 на компьютерах SPARC

После включения компьютера записанное в ПЗУ программное обеспечение (firmware) запускает процедуру самотестирования компьютера (power-on self-test – POST). То, как проходит эта процедура, зависит от конфигурации и модели компьютера.

Если тест прошел нормально, то программа автозагрузки пытается загрузить систему, используя имя устройства и имя файла ядра, записанные в ПЗУ.

Эти параметры могут быть изменены программой eeprom при интерактивной работе с Solaris из командной строки или после остановки системы – из командной строки ok, которую выдаст firmware по завершении остановки системы.

Программа, которая запускается после начального загрузчика, называется ufsboot, если загрузка происходит с диска, или inetboot, если выполняется загрузка по сети.

Загрузка по сети

Загрузка по сети может идти с применением DHCP или RARP/bootparams, зависимости от настроек, записанных в ПЗУ и реальной конфигурации сети (для настройки по DHCP в сети должен быть доступен DHCP-сервер).

Команду boot среды OpenBoot (иначе говоря, командной строки firmware) можно использовать для задания протокола загрузки явным образом:

boot net:rarp
boot net:dhcp

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

boot net

При этом загрузка осуществляется через тот интерфейс, для которого определен псевдоним net.

Загрузка через сеть с использованием RARP/bootparams

Начальный загрузчик из ПЗУ выполняет ARP-запрос (подробнее об ARP-запросах см. лекции 3 курса "Системное администрирование ОС Solaris 10") и, после получения ответа, посылает широковещательный запрос в локальную сеть по протоколу TFTP для загрузки программы inetboot из сети. Загрузив с ответившего TFTP-сервера программу inetboot, загрузчик передает ей управление, а она отправляет еще один ARP-запрос, после чего находит файловую систему в сети, с которой следует произвести загрузку ядра. Для этого inetboot использует протокол bootparams (см. man bootparams для получения детальной информации о протоколе). После того, как файловая система найдена, с нее по протоколу NFS загружается ядро и ему передается управление.

Загрузка через сеть с использованием DHCP

При загрузке по сети с использованием DHCP начальный загрузчик из ПЗУ посылает широковещательный запрос, в котором сообщает MAC-адрес своего компьютера и его архитектуру, запрашивая в ответ IP-адрес, параметры загрузки и настройки сети. После получения ответа начальный загрузчик загружает inetboot через сеть, inetboot загружает ядро, которое, в свою очередь, загружает необходимые ему файлы через сеть, после чего выгружает inetboot. Стартовые скрипты запускают dhcpagent, который выполняет оставшуюся часть настроек по DHCP.

Загрузка с диска

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

Если имя файла ядра указано не как полное имя файла (начинающееся с символа /), то такое имя расценивается как относительное и вторичный загрузчик ищет ядро в каталоге, соответствующем аппаратной платформе компьютера. Тогда путь к ядру точно будет лежать через каталог /platform/platform-name. Для многих компьютеров SPARC после этого выполняется поиск в каталоге /platform/hardware-class-name. Если указано полное имя файла, загрузчик будет пытаться загрузить в точности тот файл, что указан. После загрузки файла ядра в память загрузчик передает ему управление.

Если имя файла ядра не указано и из других настроек не понятно, какое ядро следует загружать, загрузчик сам решает, какое ядро требуется, основываясь на том, какое ПО установлено в системе, на известных свойствах аппаратуры и firmware и на записях в файле политики загрузки boot.conf. О местоположении и содержимом этого файла будет рассказно ниже, в разделе "Файлы, используемые при загрузке системы".

Среда OpenBoot. Команда boot

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

ok

Здесь мы рассмотрим команду boot среды OpenBoot.

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

boot [device] [arguments]

Если дать команду boot без параметров, то будет выполнена загрузка с устройства по умолчанию – то есть с того устройства, которое указано в переменной boot-device или diag-device в ПЗУ (NVRAM variable). Если система запускается в режиме диагностики, вместо переменных bootdevice и boot-file используются diag-device и diag-file.

Аргументы команды boot могут быть многострочными, они не анализируются загрузчиком OpenBoot, а передаются вторичному загрузчику как есть. Если команде boot переданы какие-нибудь аргументы, содержимое переменных boot-file и diag-file игнорируется. Например, если дана команда

boot –s

то подстрока "-s" расценивается как аргумент, а переменные boot-file и diag-file не принимаются во внимание.

boot net

и

boot cdrom

если даны без аргументов, будут использовать содержимое переменных boot-file и diag-file как путь к файлу ядра. Стало быть, когда boot-file содержит имя 64-разрядного ядра, а вы пытаетесь загрузиться с CD-ROM командой boot cdrom, то загрузка не состоится, если на CD-диске имеется только 32-разрядное ядро.

Для загрузки в специфическом режиме следует указывать команде boot соответствующие аргументы, в ответ на приглашение ok вводится команда:

Для SPARC-платформ

boot –as – загрузка ядра, используемого по умолчанию, в однопользовательском режиме;

boot kernel/unix –as – принудительная загрузка 32-разрядного ядра в однопользовательском режиме (для принудительной загрузки указывается имя файла явным образом);

boot kernel/sparcv9/unix –as – принудительная загрузка 64-разрядного ядра в однопользовательском режиме (для принудительной загрузки указывается имя файла явным образом).

Для более детального изучения команды boot в вашей системе следует использовать man boot ; помните, что на некоторых платформах, в зависимости от firmware, могут наблюдаться отклонения от описанной здесь и в документации схемы.

Загрузка Solaris 10 на компьютерах x86

На компьютерах x86 загрузка состоит из двух разных этапов: начальной загрузки и вторичной загрузки. Начальная загрузка выполняется BIOS системной платы и BIOS контроллеров. После процедуры POST начальный загрузчик пытается прочесть первый сектор с дискеты, компакт-диска, внешнего флэш-накопителя USB или жесткого диска, либо, если эта функция поддерживается, загрузить вторичный загрузчик через сеть. После того, как вторичный загрузчик записан в оперативную память, ему передается управление. Начальный загрузчик работает в режиме real mode процессора, а вторичный – в защищенном режиме (32-bit protected mode).

Вторичный загрузчик представляет собой знакомый по системам Linux загрузчик GRUB и способен считать ядро с диска из файловой системы UFS, компакт-диска или через сеть с использованием NFS.

Начиная с версии Solaris 10 1/06 описанная в этом и следующих двух абзацах процедура перестала использоваться. В версиях до Solaris 10 3/05 включительно в процессе загрузки применялся DCA (device configuration assistant). Вторичный загрузчик запускал программу DCA, которая определяет физические устройства компьютера. При этом системный администратор мог вмешаться в процесс определения устройств, если DCA их не мог верно определить автоматически.

После возвращения управления от DCA вторичный загрузчик выполнял скрипт /etc/bootrc, который управлял дальнейшим процессом загрузки. Обычный /etc/bootrc предлагает администратору ввести символ b для загрузки с определенными ключами и аргументами, символ i для запуска интерактивного командного интерпретатора и любой другой символ – для загрузки ядра с установками по умолчанию.

Для загрузки в специфическом режиме следует указывать команде boot соответствующие аргументы, так для x86 платформ в ответ на приглашение > вводится команда

b kernel/unix –as

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

Файлы и каталоги, используемые при загрузке

Только для компьютеров x86 (до Solaris 10 1/06 включительно):

Замечание о загрузке систем UltraSPARC

Некоторые старые компьютеры SPARC технически способны работать с 64-битной версией Solaris, но им может требоваться обновление firmware для того, чтобы эта работа стала в действительности возможной. Если вы обладаете как раз такой системой и установили 64-битный Solaris, то при загрузке этот факт будет обнаружен и вы получите сообщение о том, что firmware следует обновить, вслед за этим загрузчик выберет 32-разрядное ядро и загрузка продолжится.

Процессоры UltraSPARC-1 с частотой 200 MГц и меньше имеют ошибку в микрокоде, из-за которой на компьютерах с такими процессорами пользователь может запустить 64-битную программу, вызывающую остановку процессора посредством выполнения известной комбинации команд. Чтобы избежать этой неприятности, при работе на таких компьютерах Solaris при загрузке выбирает 32-битное ядро, так как 64-битное приложение не сможет запуститься при работе с 32-разрядным ядром.

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

В тех системах, где вероятность запуска такой зловредной программы мала, а пользователи работают только с обычными приложениями, полученными из надежных источников или собранных из исходеных текстов языка высокого уровня типа С, администратор может явным образом потребовать у загрузчика выполнять загрузку 64-разрядного ядра при старте системы. Для этого потребуется изменить файл политики загрузки /platform/platform-name/boot.conf:

ALLOW_64BIT_KERNEL_ON_UltraSPARC_1_CPU=true

Инициализация ядра

После того, как ядро загружено в память и ему передано управление, ядро начинает загрузку модулей. В этот момент оно еще не умеет читать файлы с файловой системы UFS, так как драйвер файловой системы еще на загружен. Поэтому для чтения модулей ядро использует ufsboot. После того, как загружено достаточно модулей для монтирования корневой файловой системы и самостоятельного продолжения загрузки, ядро выгружает ufsboot и выполняет остаток загрузки. Оно монтирует указанные в /etc/vfstab файловые системы и запускает процесс /sbin/init для перехода к рабочему режиму системы. Процесс /sbin/init, в свою очередь, запускает те программы и скрипты, которые перечислены в /etc/inittab, и передает управление службе svc.startd.

До Solaris 9 включительно режим работы по умолчанию указывался в /etc/inittab с меткой initdefault. Начиная с Solaris 10 рабочий режим определяется установками подсистемы SMF, а именно тем, какой этап системы требуется загрузить. По умолчанию происходит загрузка этапа milestone/multi-user-server. Конкретный набор служб, запускаемых для перехода к этому этапу, указан в профиле /var/svc/profile/generic.xml, или, если этот файл существует, в /var/svc/profile/generic_open.xml. Более подробно о профилях SMF рассказано в лекции 13 курса "Системное администрирование ОС Solaris 10".

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

Чтобы узнать, какие модули загружены в настоящий момент, следует выполнить команду

modinfo

Модули ядра хранятся в каталогах /kernel и /usr/kernel, специфичные для аппаратной платформы модули лежат в каталогах /platform/`uname –m`/kernel и /platform/` uname –i`/kernel (если такие есть).

Специфические указания, какие модули загружать при старте системы, следует разместить в файле /etc/system, который считывается ядром при загрузке. В этом файле можно также указать дополнительные параметры, которые надо передать модулям при загрузке.

В частности, /etc/system используют, чтобы указать:

Стандартный файл /etc/system в Solaris 10 выглядит примерно так (незначимые для данного примера строки не показаны):

* SYSTEM SPECIFICATION FILE
*
* moddir:
*
*     Set the search path for modules. This has a format similar
*     to the csh path variable. If the module isn't found in the
*     first directory it tries the second and so on. The default
*     is /kernel /usr/kernel
*
*     Example:
*           moddir: /kernel /usr/kernel /other/modules
*
* root device and root filesystem configuration:
*
*     The following may be used to override the defaults provided
*           by the boot program:
*
*     rootfs:           Set the filesystem type of the root.
*
*     rootdev:          Set the root device. This should be a
*                       fully expanded physical pathname. The
*                       default is the physical pathname of the
*                       device where the boot program resides.
*                       The physical pathname is highly platform
*                       and configuration dependent.
*
*     Example:
*           rootfs:ufs
*           rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a
*
*     (Swap device configuration should be specified in /etc/vfstab.)
*
* exclude:
*
*     Modules appearing in the moddir path which are NOT to be
*     loaded, even if referenced. Note that `exclude' accepts
*     either a module name, or a filename which includes the
*     directory.
*
*     Examples:
*           exclude: win
*           exclude: sys/shmsys
* forceload:
*
*     Cause these modules to be loaded at boot time, (just before
*     mounting the root filesystem) rather than at first
*     reference. Note that forceload expects a filename which
*     includes the directory. Also note that loading a module
*     does not necessarily imply that it will be installed.
*
*     Example:
*           forceload: drv/foo
*
* set:
*
*     Set an integer variable in the kernel or a module to a new
*     value. This facility should be used with caution. See
*     system(4).
*
*     Examples:
*
*     To set variables in 'unix':
*
*           set nautopush=32
*           set maxusers=40
*
*     To set a variable named 'debug' in the module named
*     'test_module'
*
*                set test_module:debug = 0x13

Важно!

Всегда делайте резервную копию любого файла конфигурации перед внесением изменений! Дать команду cp /etc/system /etc/system.bak – дело двух секунд, зато это действие сохранит вам нервы и время – проверено поколениями сисадминов!

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

Если правилом (2) вы пренебрегли вопреки голосу разума, то неверный файл /etc/system может вызвать ошибку при загрузке и система не загрузится. Если это случилось, то:

Как видно из приведенного примера, настройки в /etc/system часто выглядят так:

set параметр=значение

Например, параметр ядра MAXUSERS устанавливается в значение 50 следующей командой:

set maxusers = 50

Обратите внимание на то, что параметры статической части ядра (фактически, файла unix) устанавливаются без ссылки на модуль, а параметры, применимые к модулям, – с указанием имени модуля:

set модуль:параметр=значение

Длина команды в файле /etc/system не должна превышать 80 символов, строки, начинающиеся со знака звездочки "*" или решетки "#", интерпретируются как комментарии.

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

sysdef
*
* Hostid
*
  0930edc1
*
* i86pc Configuration
*
*
* Devices
*
scsi_vhci, instance #0
isa, instance #0
   i8042, instance #0
      keyboard, instance #0
      mouse, instance #0
   motherboard (driver not attached)
   asy, instance #0
   lp, instance #0
   asy, instance #1
   pit_beep, instance #0
pci, instance #0
   pci1025,10a (driver not attached)
   pci1002,5a34, instance #0
      display, instance #0
   pci1002,5a36 (driver not attached)
   pci1002,5a37 (driver not attached)
   pci1002,5a38 (driver not attached)
   pci1002,5a39, instance #4
   pci1468,422, instance #0
   pci-ide, instance #0
      ide, instance #0
         cmdk, instance #0
      ide (driver not attached)
   pci1025,10a, instance #0
   pci1025,10a, instance #1
      mouse, instance #2
   pci1025,10a, instance #0
      device, instance #0
   pci1025,10a (driver not attached)
<...>
*
* Loadable Objects
*
* Loadable Object Path = /platform/i86pc/kernel
*
kmdb/amd64/cpu.generic
kmdb/amd64/cpu_ms.AuthenticAMD.15
kmdb/amd64/pcplusmp
kmdb/amd64/unix
kmdb/amd64/uppc
kmdb/cpu.generic
kmdb/cpu_ms.AuthenticAMD.15
kmdb/pcplusmp
kmdb/unix
kmdb/uppc
drv/amd64/xsvc
drv/xsvc
drv/amd64/cpc
   hard link: sys/amd64/cpc
drv/cpc
   hard link: sys/cpc
misc/amd64/cpr
misc/cpr
drv/amd64/nxge
drv/nxge
drv/amd64/pci-ide
drv/pci-ide
amd64/unix
cpu/amd64/cpu.generic
cpu/amd64/cpu_ms.AuthenticAMD
cpu/amd64/cpu_ms.AuthenticAMD.15
cpu/amd64/cpu_ms.GenuineIntel
<...>
*
* Loadable Object Path = /usr/kernel
*
drv/ncall
drv/nsctl
drv/nskern
drv/sdbc
drv/amd64/sv
drv/sv
drv/amd64/pool
drv/pool
drv/amd64/zcons
drv/zcons
drv/amd64/winlock
drv/winlock
drv/amd64/ii
drv/ii
drv/amd64/ipf
drv/ipf
misc/spuni
misc/amd64/spuni
drv/amd64/pm
drv/pm
<...>
*
* System Configuration
*
  swap files
swapfile             dev      swaplo    blocks      free
/dev/dsk/c0d0s1      102,1    8         4209016  4036480
*
* Tunable Parameters
*
32006144   maximum memory allowed in buffer cache (bufhwm)
   24426   maximum number of processes (v.v_proc)
      99   maximum global priority in sys class (MAXCLSYSPRI)
   24421   maximum processes per user id (v.v_maxup)
      30   auto update time limit in seconds (NAUTOUP)
      25   page stealing low water mark (GPGSLO)
       1   fsflush run rate (FSFLUSHR)
      25   minimum resident memory for avoiding deadlock (MINARMEM)
      25   minimum swapable memory for avoiding deadlock (MINASMEM)
*
* Utsname Tunables
*
    5.11  release (REL)
 solaris  node name (NODE)
   SunOS  system name (SYS)
 snv_79a  version (VER)
*
* Process Resource Limit Tunables (Current:Maximum)
*
0x0000000000000100:0x0000000000010000  file descriptors
*
* Streams Tunables
*
     9  maximum number of pushes allowed (NSTRPUSH)
 65536  maximum stream message size (STRMSGSZ)
  1024  max size of ctl part of message (STRCTLSZ)
*
* IPC Messages module is not loaded
*
*
* IPC Semaphores module is not loaded
*
*
* IPC Shared Memory
*
* The IPC Shared Memory module no longer has system-wide limits.
* Please see the "Solaris Tunable Parameters Reference Manual" for
* information on how the old limits map to resource controls and
* the prctl(1) and getrctl(2) manual pages for information on
* observing the new limits.
*
*
* Time Sharing Scheduler Tunables
*
60 maximum time sharing user priority (TSMAXUPRI)
SYS system class name (SYS_NAME)

Запуск процесса init и файл /etc/inittab

Процесс init запускается ядром сразу после монтирования файловых систем из /etc/vfstab. После этого init осуществляет переход в тот режим выполнения, который ему указан. Начиная с Solaris 10 файл /etc/inittab, содержимое которого управляет тем, как init запускает службы, стал значительно короче, так как основная масса служб теперь управляется службой запуска – программой svc.startd. Вот типичный файл /etc/inittab в системе Solrais 10:

ap::sysinit:/sbin/autopush -f /etc/iu.ap
sp::sysinit:/sbin/soconfig -f /etc/sock2path
smf::sysinit:/lib/svc/bin/svc.startd   >/dev/msglog 2<>/dev/msglog
</dev/console
p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog
2<>/dev/msglog
pt:s1234:powerfail:/usr/lib/svc/method/installupdates lock

Первая строка файла отвечает за инициализацию модулей STREAMS, вторая – за настройку транспорта сокетов, третья – за запуск svc.startd, который и продолжит загрузку всех остальных служб. Четвертая и пятая строки определяют завершение работы системы в случае сбоя питания.

Хотя файл inittab и потерял свое значение для запуска и перезапуска служб в Solaris начиная с Solaris 10, возможность запускать службы посредством требования их запуска в определенных режимах работы оставлена для совместимости с приложениями сторонних разработчиков. Если при установке такого приложения файл /etc/inittab был модифицирован, то для интеграции содержимого файла в общую базу данных о службах в системе следует запустить inetconv. Без этого модификация /etc/inittab не окажет никакого действия на порядок загрузки служб в системе. Все указанные в /etc/inittab службы запускаются в статусе legacy_run после запуска всех остальных служб, перечисленных в базе данных (репозитории) SMF. Это делается для того, чтобы гарантированно запустить те службы, от которых зависят указанные в /etc/inittab службы.

Сценарии запуска системы

В каталогах /etc/rcN.d лежат скрипты запуска системы. Там располагаются те скрипты, которые запускают и останавливают отдельные приложения. Имена файлов в каталогах имеют вид KnnNAME или SnnNAME, где nn – это целое положительное число, а NAME – имя приложения (обычно – демона).

Файлы, начинающиеся с буквы S (start) – это скрипты для запуска приложения, файлы, начинающиеся с K (kill) – для завершения работы приложения. Номер nn определяет порядок запуска скриптов: вначале запускаются те, что имеют меньший порядковый номер.

При переходе в тот или иной режим работы системы выполняются вначале скрипты останова приложений, а затем – скрипты запуска приложений того режима, в который происходит переход. При старте системы выполняются скрипты запуска приложений режима 3, которому соответствует этап milestone/multi-user-server.

То, какие именно скрипты запускать, описано в файле /etc/rcN ( N может принимать значения от 0 до 6 и s), который собственно и вызывается процессом init. Файлы /etc/rcN являются символическими ссылками на файлы /sbin/rcN (см. файл /etc/inittab выше).

Так, если каталог /etc/rc3.d содержит нижеуказанные скрипты (см. рис 11.1), то первым выполнится S13kdc.master, затем S14kdc и так все по порядку (последним будет S90samba ).

Хотя стандартным для Solaris 10 (и, вероятно, следующих версий Solaris) является запуск служб не с помощью скриптов из каталогов /etc/rcN.d, а с помощью svc.startd, возможность использования скриптов сохранена для совместимости с приложениями сторонних разработчиков. Если при установке таких приложений происходит модификация /etc/inittab и размещение скриптов в каталогах /etc/rcN.d, то приложения будут нормально загружаться в порядке, описанном выше в разделе "Запуск процесса init и файл /etc/inittab", и выполняться, как обычно.

Программы shutdown, init, poweroff, halt, reboot

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

В Solaris есть несколько таких программ:

/usr/sbin/shutdown
/sbin/init
/usr/sbin/halt
/usr/sbin/reboot
/usr/sbin/poweroff
Stop+A или L1+A

Программы /usr/sbin/shutdown, /sbin/init, /usr/sbin/halt выполняют завершение всех процессов в системе, записывают несохраненные данные на диск, и переводят систему в новый режим работы (в том числе и в состояние остановки).

Программа /usr/sbin/reboot выполняет все вышеперечисленное и затем переводит систему в режим, определенный как initdefault в /etc/inittab.

Команда /usr/sbin/poweroff обеспечивает переход в режим номер 5, т.е. она эквивалентна команде init 5.

Последняя команда (комбинация клавиш <Stop+A> или <L1+A>) доступна только в SPARC-системах, где соответствующие клавиши есть на клавиатуре и посылаемый ими код отрабатывается как аварийная остановка. Аварийную остановку следует выполнять только в крайнем случае, так как при таком завершении работы системы все процессы прерываются немедленно, без всякой записи данных на диск, и последствия могут быть незавидными для тех, чьи данные не были сохранены.

Программа shutdown

Самый общий способ остановки системы – программа shutdown, она есть в любом UNIX'e. В Solaris эта программа имеет следующий стнтаксис вызова:

shutdown [-y] [-gпериод_ожидания [-iрежим]

например

shutdown –y –g0

Эта команда выполняется только привилегированным пользователем для изменения режима работы системы. Обычно она используется для перехода из многопользовательского режима (3) в другой режим.

По умолчанию, команда переводит систему в режим 0, т.е в состояние, в котором безопасно отключать питание. Это состояние называется состоянием остановки (shutdown state).

Команда посылает всем интерактивно работающим с системой пользователям предупреждающее сообщение о том, что система готовится к переходу в другой режим работы, и окончательное сообщение о том, что этот переход начинается перед началом реальных действий по остановке. Пользователи обязаны быстро завершить свои задачи после получения предупреждающего сообщения – на это у них по умолчанию есть одна минута. Если они проигнорируют предупреждение, их процессы будут принудительно завершены, а несохраненные данные потеряются. Программа shutdown берет стандартное значение периода ожидания после каждого из этих сообщений из файла /etc/default/shutdown, если он существует. Если shutdown не может найти файл или не может прочитать значение, она выдает предупреждение и устанавливает период ожидания в 60 секунд. По умолчанию программа запрашивает подтверждение у запустившего ее администратора, прежде чем начинать остановку демонов и прекращение процессов. Опции команды используются следующим образом:

Файл /etc/default/shutdown используется для задания значений, специфичных для вашей системы.

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

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

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

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

Стоит отметить, что кроме неукоснительного выполнения корректного завершения работы системы с помощью команды shutdown или аналогичной ей по смыслу, есть еще одно дело, о котором системный администратор должен помнить: стабильное электропитание. Если пьяный сантехник, ретивая уборщица или безмозглый помощник научены никогда не выдирать провода из розеток и всегда выполнять shutdown, это значит, что осталось установить надежную систему бесперебойного питания. Подсоединяя UPS к компьютеру, убедитесь, что он настроен так, чтобы выдавать сигнал бедствия компьютеру при отключении электропитания; получив такой сигнал, система немедленно запустит shutdown и ее работа завершится безболезненно. Конечно, для систем круглосуточной работы надо иметь UPS с запасом энергии батарей, достаточным для работы в течение всего времени восстановления питания.