Документація: Архітектура Linux-сесії

Я шукаю хорошу оглядову документацію, що описує стек демонів і служб, залучених до сучасного сеансу Linux. Хоча, прочитавши різноманітну документацію про dbus, і systemd, я все ще не знаю, яка картина.

Зокрема, я шукаю відповіді на ці запитання (не відповідайте на запитання, вони повинні лише уточнити, яку саме документацію я шукаю):

• Після входу в систему, який процес є коренем сеансу користувача?

• Які процеси слід розпочати, і чому? Я шукаю відповідь на робочий стіл, незалежно від того, запускаються Gnome, KDE, FVWM чи проста оболонка.

• Яку роль відіграють усі ці демони? Хто з них біг би поодинці, а це залежало від інших? З кого слід починати кого, чому і на який термін? І хто повинен підтримувати цей зоопарк?

Я питаю, тому що я виявив , що у мене є цілий зоопарк демони працюють відразу після завантаження: systemd-journald, systemd-udevd, dbus-daemon, systemd-logind. Але мало: Крім цього, біг ультра-легкого PDF-переглядач zathura додатково заповнить мою сесію з dbus-launch, dbus-daemon, at-spi2-registrydі at-spi-bus-launcher, останнім запуском ще іншим dbus-daemon. Ніхто з них раніше не був там, нікого не запросили, але вони залишаться біля будинку, даючи мені моторошне почуття, поки я не вийду. Я впевнений, що мені чогось тут не вистачає ...

Інший приклад: після входу в систему systemdя працюю з UID моїх користувачів, але я не маю уявлення, що він повинен робити (оскільки версію 206 я думаю, я не повинен використовувати це як менеджер сеансів, правда?). У ньому є дочірній процес (sd-pam), про який я не зміг знайти документацію.

Що вони роблять? Яка ідея цього налаштування?

Для уточнення моєї точки зору: «У старі часи» було достатньо знати, що loginзапустить мою оболонку входу ( bashвиконуючи виконання ~/.profile), і з цього моменту я можу продовжувати будувати сеанс, залежно від обставин, можливо, запуск screenабо startx.

Мене настільки захоплює ваше запитання, що я відповів на нього на linuxintro . Ось відповідь, пристосована до вашого запитання:

Коли типовий ПК із Linux, наприклад Fedora, SUSE або Ubuntu, завантажується, такі дії будуть такими:

1. BIOS запускає самоперевірку
2. BIOS завантажує завантажувальний сектор та виконує його
3. Виконується завантажувач типу grub або lilo
4. Показано завантажувальне меню (необов’язково)
5. Ядро завантажується
6. Завантажується початковий диск RAM
7. Ядро виконується
8. Ядро виконує init

9. init виконується в залежності від вашого дистрибутива, версії та конфігурації

   • SysV init скрипти або
   • systemd або
   • вискочити

Сенс усіх цих програм полягає в тому, щоб запускати такі послуги

• dbus, що дозволяє зв’язок між додатками, щоб один додаток міг викликати функції з іншого запущеного додатка. Це звичайно не видно користувачам, наприклад, програма, яка закликає менеджер вікон поставити власне вікно у фокус
• вхід, який дозволяє користувачам входити в термінали CTRL_ALT_F *. Процес входу, як його бачить ps -A, у випадку systemd буде systemd-logind (може знову змінюватися залежно від поширення)
• udev , у якого багато імен, наприклад, для мене я знаходжу це з ps -A як systemd-udevd. Він призначає, наприклад, пристрій обробляє в / dev / пристрої, до яких ви підключаєтесь, наприклад, USB-диск
• cron, який буде виконувати команди на основі таблиці часу в / etc / crontab, а також має функцію "@reboot" для запуску команд під час завантаження.

10) процес входу, оброблений systemd, буде чекати входу у віртуальний термінал, який, як правило, доступний натисканням CTRL_ALT_F1

11) зазвичай і за замовчуванням процес init тепер запустить диспетчер дисплеїв, наприклад, kdm (менеджер дисплеїв KDE) або xdm

12) диспетчер дисплеїв тепер запустить графічну систему. Графічної системи практично немає, але Xorg (hildon призначений для вбудованих пристроїв).

13) диспетчер дисплеїв порадить серверу Xorg відобразити екран входу

Тепер запуск завершено, і комп'ютер чекає, коли користувач увійде в систему.

14) у вході користувача в диспетчер дисплеїв запуститься середовище робочого столу типу KDE, GNOME або XFCE4. Кореневий процес для сеансу KDE користувача буде називатися startkde, кореневий процес для GNOME буде називатися gnome-сесія, кореневий процес для XFCE4 буде називатися xfce4-сесія

15) KDE зазвичай запускає всі виконувані файли з ~ / .kde / Autostart і файлів .desktop з / etc / xdg / autostart (див. Завдання планування ).

16) Коли користувач виконав графічний вхід і натисне на піктограму, щоб відкрити консоль, зазвичай виконується баш. Спочатку Bash виконає .bashrc

17) Коли користувач відкриває оболонку входу, це означає, що він повинен увійти через пароль або авторизований ключ. Він може це зробити на консолі CTRL_ALT_F1 або через ssh'ing до комп'ютера, наприклад, localhost. Тоді сценарії .sh з /etc/profile.d та .bashrc будуть виконані.

Відповідь - 42. Торстен Старк пояснив вже головну проблему в коментарях.

Щоб допомогти вам отримати широку картину, вам потрібно знати, що програмне забезпечення Linux та Open Source написано та підтримується мільйонами добровольців та компаній. Отже, нелегко йти в ногу з ростом.

З іншого боку, є багато документації: довідкові сторінки для кожного програмного забезпечення, добре пояснення, що таке D-Bus , розсилки розсилок розробників, Google тощо. Отже, знайдіть кілька років і прочитайте всі документи пакунків, які вас цікавлять. Якщо вам це потрібно швидше, просто задайте кілька хороших запитань в Unix & Linux .

Удачі.

Перш ніж я надам свою версію відповіді, дозвольте почати з пари визначень

Linux == 'Ядро операційної системи "Linux System ==" Якась система, побудована навколо ядра Linux "Сесія в системі Linux ==" Деякий набір пов’язаних програм користувача, що працюють в системі Linux "

Чим далі ви відходите від ядра, тим менше ймовірність будь-яких двох "систем" насправді матиме щось спільне. Що означає, що насправді немає жодного розумного визначення "сучасної сесії Linux"

Відверто кажучи, сподівання, що має існувати якась загальна системна документація, яка дає вам всі компоненти, - це сподівання, яке просто не буде виконано у більшості частин світу з відкритим кодом. Розробники з відкритим кодом пишуть програми для вирішення (або повторного вирішення!) Конкретних проблем, які їх хвилюють - вони просто документують цю частину, якщо це - якщо це! :-)

Можливо, вам пощастить з посібниками, доступними для комерційних дистрибутивів Linux, проте, враховуючи консервативний характер більшості з них, ви можете стверджувати, що їх випуски не є "сучасними"!

Основна порада, яку я б дав, - це те, що системи UNIX / Linux дуже загального сенсу є герахічними. Я говорив людям, що мені подобаються nix системи, тому що я можу почати з init, а звідти зрозуміти все, що відбувається в системі. Systemd та друзі це трохи змінили, але основний принцип той самий - почніть з верху і працюйте вниз - "програми, що складають сеанс", - це, як правило, ті, що почалися з моменту, коли ви входите в спадщину. Отже, якщо ви входите в ssh, ви, ймовірно, отримаєте будь-яку оболонку за замовчуванням, оскільки так працює ssh. Якщо ви ввійдете в систему за допомогою графічного інтерфейсу, ви отримаєте все, що розпочато вашим менеджером входу, оскільки саме так працює ваш менеджер входу.

Багато рамок робочого столу роблять це трохи складніше, запускаючи різні демонстраційні служби користувачів або системного рівня - а іноді вони запускаються на вимогу, коли запускається перша програма, яка потребує їх - подивіться параметри командного рядка програм, які ви запускаєте, є цілком ймовірні варіанти зупинити таку поведінку та запустити додаток у режимі "голий".

На жаль, це означає, що "читання документації про окремі програми" - це єдиний спосіб зрозуміти це все, і що для сеансу не існує "мінімального набору демонів" - існує лише спосіб, яким заданий дистрибутив працює для даної задачі метод входу / доступу та специфічний метод розподілу, робочий стіл та метод входу.