Xinit linux что это

Обновлено: 04.07.2024

Несколько более успешный (но все еще не самый правильный) способ выхода в графический режим состоит в том, что Вы даете команду xinit .

Программа xinit предназначена для запуска сервера системы X Window и хотя бы одной программы-клиента.

Если в командной строке не указано, какой именно X-сервер запускать, xinit ищет в домашнем каталоге пользователя файл .xserverrc , чтобы выполнить содержащийся в нем скрипт запуска сервера. Если такого файла нет, xinit по умолчанию выполняет следующий скрипт: то есть запускает программу с именем X на дисплее 0. При этом предполагается, что в одном из каталогов, перечисленных в путях поиска, найдется программа с именем X . Но, как Вы уже знаете, сервера обычно называются XF86_displaytype , где displaytype - это тип графического дисплея, для которого предназначен данный сервер. Администратор сайта, следовательно, должен установить ссылку на подходящий сервер или создать скрипт, который запускает xinit с вызовом соответствующего сервера. Используя скрипт .xserverrc , удостоверьтесь, что по команде "exec" в нем запускается существующий X-сервер: В противном случае загрузка будет происходить очень медленно и завершится немедленным выходом.

Если в командной строке запуска xinit не указана клиентская программа, которую надо запускать, программа xinit ищет в домашнем каталоге пользователя файл .xinitrc , чтобы выполнить его как скрипт, запускающий клиентские программы(у). Если такого файла не существует, xinit по умолчанию выполняет вместо этого скрипта команду: Если Вы после установки Red Hat Linux еще не создали свой файл .xinitrc , и просто запустите команду xinit из командной строки, Вы увидите почти пустой рабочий стол с единственным окном терминала. Поскольку менеджера окон нет, Вы ничего не можете сделать с этим окном (переместить, изменить размер и т.д.), но Вы можете в этом окне запустить другие программы, в том числе менеджер окон. Перейдите, например, в каталог /usr/X11R6/bin и дайте команду fvwm (этот оконный менеджер обычно по умолчанию установлен). После этого вид экрана существенно изменится, Вы сможете изменять окна (обычным способом, захватывая мышкой границу окна), а по щелчку левой кнопкой по пустому полю рабочего стола получите выход в меню.

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

Ниже приведен пример скрипта .xinitrc , который запускает часы, несколько терминалов и оставляет менеджер окон в качестве "последнего" клиента. Важно отметить, что программы, запускаемые из .xinitrc , должны запускаться в фоновом режиме, если только они не завершаются немедленно. Иначе эти программы будут препятствовать запуску других программ. Однако одна из запущенных программ (обычно менеджер окон или эмулятор терминала) должна выполняться не в фоновом режиме, а на переднем плане, чтобы работа скрипта не завершалась (завершением работы этой программы пользователь сообщает программе xinit , что закончил работу и что сама программа xinit должна завершиться). В приведенном примере, если менеджер окон правильно сконфигурирован, то для завершения работы в X-сессии достаточно выбрать пункт "Exit" в меню менеджера twm.

Аргументы, заданные в командной строке вызова xinit , позволяют обойти выполнение скриптов .xinitrc и .xserverrc . В командной строке может быть указана альтернативная программа-клиент и/или альтернативный сервер. Клиентская программа должна быть первым аргументом в командной строке вызова xinit . Для того, чтобы вызвать конкретный X-сервер, добавьте двойное тире (после указания программы-клиента и ее аргументов), после которого укажите имя нужного сервера.

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

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

Вот несколько примеров командной строки вызова программы xinit .

"xinit"

Этой командой будет запущен сервер, на который указывает ссылка (линк) X , и выполнен пользовательский скрипт .xinitrc , если таковой существует, а иначе просто запущен xterm .

"xinit -- /usr/X11R6/bin/Xqdss :1"

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

"xinit -geometry =80x65+10+10 -fn 8x13 -j -fg white -bg navy"

По этой команде будет запущен сервер, на который указывает ссылка X , и запускаемой по умолчанию команде xterm будут переданы аргументы, перечисленные в командной строке. Скрипт .xinitrc будет проигнорирован.

"xinit -e widgets -- .Xsun -l -c"

В этом случае для запуска сервера используется команда .Xsun -l -c , а запускаемому по умолчанию программе-клиенту xterm будет переданы аргументы -e widgets .

"xinit /usr/ucb/rsh fasthost cpupig -display ws:1 -- :1 -a 2 -t 5"

Эта команда запускает сервер X на дисплее с номером 1 с аргументами -a 2 -t 5 . Затем будет запущена оболочка shell на удаленном компьютере fasthost , в которой будет выполнена команда cpupig , вывод которой будет возвращен на дисплей локального компьютера.

Поскольку пользователю-новичку обычно не хватает квалификации для создания собственного варианта скрипта .xinitrc , администраторы сайтов могут помочь им в вызове графического интерфейса, создав общедоступный скрипт, выполняющий эту функцию. Такие скрипты обычно называются x11 , xstart , или startx и являются удобным способом создания простого интерфейса для пользователей-новичков. Вот пример простейшего скрипта такого вида: При инсталляции стандартной версии Red Hat Linux создается более сложный вариант скрипта startx , который расположен в каталоге /usr/X11/bin (Вы можете его просмотреть). Для него существует и man-страница, в которой говорится, что этот скрипт создается просто как образец для администраторов сайтов, предназначенный для создания собственных вариантов такого скрипта.

Если просмотреть стандартный вариант скрипта startx , мы увидим, что практически он сводится к выполнению всего-навсего 3-х команд: xauth add $display . $mcookie
xauth add `hostname -f`$display . $mcookie
xinit $clientargs -- $display $serverargs То есть, в конечном итоге, startx вызывает уже рассмотренную нами команду xinit , только предварительно формирует нужные значения аргументов командной строки для нее. Первый аргумент - имя файла xinitrc, причем если в домашнем каталоге пользователя есть файл .xinitrc, то берется он (с указанием пути), а если в домашнем каталоге нет такого файла, то берется общесистемный файл /etc/X11/xinit/xinitrc, то есть "clientargs" = "/etc/X11/xinit/xinitrc".
Аналогично формируется значение переменной serverargs: если существует N8файл .xserverrc в домашнем каталоге пользователя, то переменная serverargs будет указывать на него. Если такого файла нет, то serverargs укажет на /etc/X11/xinit/xserverrc. Переменной display присваивается значение :0. Далее в скрипте startx производится анализ аргументов, которые были заданы в командной строке при его вызове (эту часть мы пока не будем детально разбирать, поскольку для начала будем вызывать скрипт без параметров) и, наконец, в конец строки вызова xinit добавляется -auth $HOME/.Xauthority. Таким образом, сразу после установки системы (пока пользователь не создал файлов .xinitrc и .xserverrc в своем домашнем каталоге) будет вызываться в следующем виде:

7.5. Выбор и настройка менеджера окон

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

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

Очень важно иметь хороший файл .xinitrc. Вот пример:

usermodmap=$HOME/.Xmodmap
xmodmap $usermodmap

rxvt -cr green -ls -bg black -fg white -fn 7x14 \
-geometry 80x30+57+0 &

Хотя это и не обязательно, можно сделать этот файл исполняемым с помощью команды

chmod +x .xinitrc .

Этот вариант .xinitrc позволяет Вам выбрать менеджер окон, попробуйте, например:

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

7.6. Графическая среда KDE

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

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

Существует уже несколько графических сред, как свободно распространяемых, так и коммерческих. Из свободно распространяемых наибольшую известность приобрели KDE и GNOME. Мне лично больше нравится KDE. Возможно, это определяется тем обстоятельством, что именно эта среда была первой, с которой я начал работать, и притом вполне успешно. В то время как первая встреча с GNOME была несколько неудачной. Говорят, что в последнее время коллектив разработчиков GNOME сделал большой шаг вперед, но я пока остаюсь приверженцем KDE.

Одним из немаловажных достоинств KDE является достаточно подробная документация на русском языке. Она была включена в состав дистрибутивного диска Black Cat 5.2, с которого началось мое знакомство с Линукс. Эту документацию Вы можете найти на русской версии сайта KDE . Там есть руководство пользователя (краткий курс и обширный курс), переводы документации по отдельным компонентам KDE, ответы на часто задаваемые вопросы. Мне очень понравился краткий курс, который в очень сжатом виде знакомит Вас с возможностями этой среды. Учитывая, что мне вряд ли удастся создать более качественное описание, я не буду продолжать этот раздел, а просто рекомендую Вам заглянуть на упомянутый выше сайт.

При установке такой файл не создается, так что создайте его сами и запишите в него одно слово: KDE
(создать такой файл можно командой cat > /etc/sysconfig/desktop ).

После перезапуска графической оболочки Вы получите желаемый результат: будет запущена ГИС KDE . А уж о том, как настроить ее, читайте на упомянутом выше русской версии сайта KDE . Некоторые рекомендации (исходя из моего личного опыта) приводятся также в разделе "Создание удобной рабочей среды".

7.7. Использование менеджера дисплея (X Display Manager)

Систему X Window можно запускать автоматически при включении компьютера, используя программу, которая называется менеджером дисплея (X Display Manager - xdm ). В этом случае пользователь сразу видит привлекательную графическую среду и нет необходимости специально запускать графический интерфейс командой startx . При этом сохраняется возможность переключиться в текстовую консоль, набрав <Ctrl>-<Alt>-<F1>, а потом вернуться обратно в графическую среду, используя комбинацию <Alt>-<F7>.

Для того, чтобы запускать xdm при загрузке ОС, надо отредактировать файл /etc/inittab заменив в нем строку "id:3:initdefault:" на строку следующего вида:

Такое изменение заставляет Linux при запуске переходить на 5-ый уровень и по умолчанию запускать xdm . Запускаемый по умолчанию менеджер дисплея определяется тоже строкой в /etc/inittab , которая располагается обычно где-то в конце этого файла и имеет примерно такой вид:

Если Вы решили запускать xdm при старте и хотите использовать, например, глубину цвета 24 бита на пиксел вместо применяемой по умолчанию 8 bpp (и Ваша видеокарта и монитор поддерживают ее), Вы должны изменить файл /etc/X11/xdm/Xservers (в нем всего одна строка) следующим образом:

:0 local /usr/X11R6/bin/X -bpp 24

Если Вы установили KDE, то вместо xdm , вероятно, запускается kdm . У меня, например, строка в /etc/inittab , определяющая менеджер дисплея, имеет вид:

а /etc/X11/prefdm есть ссылка на /usr/bin/kdm.

Очень важное примечание: Имейте в виду, что команда respawn в только что приведенной строке означает, что при попытках перезапуска системы будет происходить перезапуск менеджера дисплея. В частности, нажатие "магической" комбинации [Ctrl-Alt-Del] будет повторно запускать систему в той же конфигурации. Поэтому если Вы после установки xdm будете как-то менять системные настройки и в результате ошибочных действий нарушите хрупкое равновесие системы X Window, Вы попадете в очень затруднительную ситуацию. У меня, например, после одного из опытов с редактированием файла /etc/X11/XF86Config экран после загрузки стал черным и дальше компьютер ни на что не реагировал, кроме [Ctrl-Alt-Del], а по этой комбинации происходила просто перезагрузка и выход в ту же ситуацию.

/.xinitrc представляет собой шелл-скрипт передаваемый xinit посредством команды startx . Он используется для запуска Среды рабочего стола, Оконного менеджера и других программ запускаемых с X сервером (например запуска демонов, и установки переменных окружений. Программа xinit запускает Xorg сервер и работает в качестве программы первого клиента на системах не использующих Экранный менеджер.

Одной из основных функций

/.xinitrc является указание, какой клиент X Window System будет запущен каждому пользователю при вызове startx или xinit . Существует множество дополнительных настроек и команд, которые также могут быть добавлены в

/.xinitrc согласно вашей дальнейшей настройке системы.

Большинство DMs также используют подобный xprofile перед xinit.

Установка

Установите xorg-xinit , чтобы использовать xinit и startx.

Настройка

Если .xinitrc присутствует в домашнем каталоге пользователя, startx и xinit выполнят его. Иначе startx выполнит по умолчанию /etc/X11/xinit/xinitrc .

Примечание: Xinit имеет собственное поведение по умолчанию, вместо выполнения файла. Для подробностей,смотрите xinit(1) .

Это значение по умолчанию xinitrc запустит базовую среду с Twm, xorg-xclock и Xterm (при условии, что необходимые пакеты установлены). Поэтому, чтобы запустить другой оконный менеджер или окружение рабочего стола, сначала создайте копию по умолчанию xinitrc в вашем домашнем каталоге:

Это делается так (вместо создания с нуля) чтобы сохранить некоторое желаемое поведение по умолчанию в исходном файле, например, поиске скриптов из /etc/X11/xinit/xinitrc.d . Сценарии в этом каталоге без .sh расширения не считаются исходным кодом.

Добавьте нужные команды и удалите/закоментируйте противоречивые строки. Помните, строки, следующие после exec будут игнорироваться. Например, для запуска openbox:

Примечание: По крайней мере, убедитесь, что блок if в примере выше, присутствует в вашем файле .xinitrc для того чтобы подать скрипт /etc/X11/xinit/xinitrc.d/30-dbus.sh . Иначе сессия D-Bus не будет запущена.

Запуск

Долговыполняемые программы стартуют перед оконным менеджером, такие как заставки и обои приложения. Они должны либо сами выполняться параллельно, либо работать в фоновом режиме (добавьте знак & ). Иначе, сценарий остановится и будет ждать каждую программу, чтобы закончить перед запуском оконного менеджера. Обратите внимание, что некоторые программы не должны стартовать параллельно, во избежании потока ошибок, как в случае с xrdb. Подготовка exec заменит процесс скрипта с процессом оконного менеджера, так что Х не завершится, даже если этот процесс распараллелен в фоне.

Для запуска Xorg от имени обычного пользователя, выполните:

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

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

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

Программа xprop доступна в пакете xorg-xprop из Официальных репозиториев.

Автозапуск X при входе в систему

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

Для Bash, добавьте следующее в нижнюю часть

/.bash_profile . Если файл не существует, скопируйте шаблон-версию с /etc/skel/.bash_profile . Для Zsh, добавьте в

Автоматический вход в виртуальной консоли

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

Советы и рекомендации

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

Если у вас есть рабочий

/.xinitrc , но хотите попробовать другие WM/DE, вы можете запустить его используя startx с указанием пути к оконному менеджеру:

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

Обратите внимание что требуется полный путь. По желанию, вы можете также переопределить /etc/X11/xinit/xserverrc файл (который хранит значение по умолчанию X сервера) с пользовательскими опциями, путем добавления их после -- , например:

Создание выбора DE/WM (Окружения рабочего стола/Оконного менеджера)

Если вы часто переключаетесь между различными DEs/WMs, рекомендуется использовать Display manager или добавить код в .xinitrc . Следующий код, описанный в нескольких строчках, будет принимать аргумент и загружать желаемое окружение рабочего стола или менеджера окон.

В следующем примере

/.xinitrc показано как запустить конкретную DE/WM с аргументом:

Затем скопируйте файл /etc/X11/xinit/xserverrc в ваш домашний каталог:

После этого, вы можете легко запустить конкретный DE/WM передавая аргумент, например:

Запуск приложений без оконного менеджера

Можно запустить только определенные приложения без оконного менеджера. Хотя, это будет полезно только для одного приложения, запущенного в полноэкранном режиме. Например:

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

xterm -geometry +1+1 -n login -display :0

При этом предполагается, что в одном из каталогов, перечисленных в путях поиска, найдется программа с именем X . Имейте, однако, в виду, что сервера обычно называются Xdisplaytype , где displaytype - это тип графического дисплея, для которого предназначен данный сервер. Администратор сайта, следовательно, должен установить ссылку на подходящий сервер или создать скрипт, который запускает xinit с вызовом соответствующего сервера.

Используя скрипт .xserverrc , удостоверьтесь, что по команде ``exec'' запускается существующий X-сервер:

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

В командной строке может быть указана альтернативная программа-клиент и/или альтернативный сервер. Клиентская программа должна быть первым аргументом в командной строке вызова xinit . Для того, чтобы вызвать конкретный X-сервер, добавьте двойное тире (после указания программы-клиента и ее аргументов), после которого укажите имя нужного сервера.

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

EXAMPLES

Вот несколько примеров командной строки вызова программы xinit . xinit Этой командой будет запущен сервер, на который указывает ссылка (линк) X , и выполнен пользовательский скрипт .xinitrc , если таковой существует, а иначе просто запущен xterm . xinit -- /usr/X11R6/bin/Xqdss :1 Таким образом можно запустить какой-то конкретный сервер на альтернативном дисплее. xinit -geometry =80x65+10+10 -fn 8x13 -j -fg white -bg navy По этой команде будет запущен сервер, на который указывает ссылка X , и запускаемой по умолчанию команде xterm будут переданы аргументы, перечисленные в командной строке. Скрипт .xinitrc будет проигнорирован. xinit -e widgets -- ./Xsun -l -c В этом случае для запуска сервера используется команда ./Xsun -l -c , а запускаемому по умолчанию программе-клиенту xterm будет переданы аргументы -e widgets . xinit /usr/ucb/rsh fasthost cpupig -display ws:1 -- :1 -a 2 -t 5 Эта команда запускает сервер X на дисплее с номером 1 с аргументами -a 2 -t 5 . Затем будет запущена оболочка shell на удаленном компьютере fasthost , в которой будет выполнена команда cpupig , вывод которой будет возвращен на дисплей локального компьютера.

Ниже приведен пример скрипта .xinitrc , который запускает часы, несколько терминалов и оставляет менеджер окон в качестве "последнего" клиента. Если менеджер окон правильно сконфигурирован, то для завершения работы в X-сессии достаточно выбрать пункт ``Exit'' в меню.

Другой подход состоит в создании специального скрипта в оболочке shell, который запускает xinit . Такие скрипты обычно называются x11 , xstart , или startx и являются удобным способом создания простого интерфейса для пользователей-новичков:

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

Наберите в своей оболочке следующую команду:

На экран будут выведен список всех работающих в системе процессов. Если хотите посчитать количество процессов, наберите что-нибудь, набодобие этого:

Первое число - это количество работающих в системе процессов. Пользователи KDE могут воспользоваться программой kpm, а пользователи Gnome - программой gnome-system-monitor для получения информации о процессах. На то он и Linux, чтобы позволять пользователю делать одно и то же разными способами.

Возникает вопрос: "Что такое процесс?". Процессы в Linux, как и файлы, являются аксиоматическими понятиями. Иногда процесс отождествляют с запущенной программой, однако это не всегда так. Будем считать, что процесс - это рабочая единица системы, которая выполняет что-то. Многозадачность - это возможность одновременного сосуществования нескольких процессов в одной системе.

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

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

К каждому процессу в системе привязана пара целых неотрицательных чисел: идентификатор процесса PID (Process IDentifier) и идентификатор родительского процесса PPID (Parent Process IDentifier). Для каждого процесса PID является уникальным (в конкретный момент времени), а PPID равен идентификатору процесса-родителя. Если ввести в оболочку команду ps -ef, то на экран будет выведен список процессов со значениями их PID и PPID (вторая и третья колонки соотв.). Вот, например, что творится у меня в системе:

Надо отметить, что процесс init всегда имеет идентификатор 1 и PPID равный 0. Хотя в реальности процесса с идентификатором 0 не существует. Дерево процессов можно также пресставить в наглядном виде при помощи опции --forest программы ps:

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

6.2. Использование getpid() и getppid()

Процесс может узнать свой идентификатор (PID), а также родительский идентификатор (PPID) при помощи системных вызовов getpid() и getppid().

Системные вызовы getpid() и getppid() имеют следующие прототипы:

Рассмотрим теперь простую программу, которая выводит на экран PID и PPID, а затем "замирает" до тех пор, пока пользователь не нажмет <Enter>.

Проверим теперь, как работает эта программа. Для этого откомпилируем и запустим ее:

Теперь, не нажимая <Enter>, откроем другое терминальное окно и проверим, правильность работы системных вызовов getpid() и getppid():

6.3. Порождение процесса

"К чему такая путаница?" - спросите вы. Зачем сначала "клонировать" процесс, а затем заменять в нем образ? Не проще ли все делать одной-единственной операцией? Ответы на подобные вопросы дать тяжело, но, как правило, с опытом прихоидит понимание того, что подобная схема является одной из граней красоты Unix-систем.

Попробуем все-таки разобраться, почему в Unix-системах порождение процесса отделено от запуска программы. Для этого выясним, что же происходит с данными при "клонировании" процесса. Итак, каждый процесс хранит в своей памяти различные данные (переменные, файловые дескрипторы и проч.). При порождении нового процесса, потомок получает точную копию данных родителя. Но как только новый процесс создан, родитель и потомок уже распоряжаются своими копиями по своему усмотрению. Это позволяет распараллелить программу, заставив ее выполнять какой-нибудь трудоемкий алгоритм в отдельном процессе.

Может быть кто-то из вас слышал про то, что в Linux есть потоки, которые позволяют в одной программе реализовывать параллельное выполнение нескольких функций. Опять же возникает вопрос: "Если есть потоки, зачем вся эта головомойка с клонированиями и заменой образов?". А дело в том, что потоки работают с общими данными и выполняются в одной программе. Если в потоке произошло что-то страшное, то это, как правило, отражается на всей программе в целом. Хотя технически потоки реализованы в Linux на базе процессов, но процесс все же является более независимой единицей. Крах дочернего процесса никак не отражается на работе родителя, если сам родитель этого не пожелает.

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

Разберемся теперь с тем, как на практике происходит "клонирование" процессов. Для этого используется простой системный вызов fork(), прототип которого находится в файле unistd.h:

Если fork() завершается с ошибкой, то возвращается -1. Это редкий случай, связанный с нехваткой памяти или превышением лимита на количество процессов. Но если разделение произошло, то программе нужно позаботиться об идентификации своего "Я", то есть определении того, где родитель, а где потомок. Это делается очень просто: в родительский процесс fork() возвращает идентификатор потомка, а потомок получает 0. Следующий пример демонстрирует то, как это происходит.

Проверяем, что получилось:

6.4. Замена образа процесса

Итак, теперь мы умеем порождать процессы. Научимся теперь заменять образ текущего процесса другой программой. Для этих целей используется системный вызов execve(), который объявлен в заголовочном файле unistd.h вот так:

Все очень просто: системный вызов execve() заменяет текущий образ процесса программой из файла с именем path, набором аргументов argv и окружением envp. Здесь следует только учитывать, что path - это не просто имя программы, а путь к ней. Иными словами, чтобы запустить ls, нужно в первом аргументе указать "/bin/ls".

Массивы строк argv и envp обязательно должны заканчиваться элементом NULL. Кроме того, следует помнить, что первый элемент массива argv (argv[0]) - это имя программы или что-либо иное. Непосредственные аргументы программы отсчитываются от элемента с номером 1.

В случае успешного завершения execve() ничего не возвращает, поскольку новая программа получает полное и безвозвратное управление текущим процессом. Если произошла ошибка, то по традиции возвращается -1.

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

Итак, данная программа выводит свой PID и передает безвозвратное управление программе cat без аргументов и без окружения. Проверяем:

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

Итак, мы убедились, что теперь процесс 30150 выполняет программа cat. Теперь можно вернуться в исходное окно и нажатием Ctrl+D завершить работу cat.

И, наконец, следующий пример демонстрирует запуск программы в отдельном процессе.

Обратите внимание, что поскольку execve() не может возвращать ничего кроме -1, то для обработки возможной ошибки вовсе не обязательно создавать ветвление. Иными словами, если вызов execve() возвратил что-то, то это однозначно ошибка.

Читайте также: