Більш велика зміна, яка поставляється з Ubuntu 15.04, - це перехід від початкового до системного, як за замовчуванням для управління завантаженням та запуском системної служби.
Чи може хтось адекватно пояснити нетехнічному користувачеві, як і якщо це взагалі впливає на нас? І чому це важливо?
Відповіді:
Користувачі шарувати не повинні помічати будь-які зміни за дизайном. Це система init, а не те, з чим традиційно взаємодіють користувачі. Він повинен повністю замінити функціонал, який надає Upstart - і зробити кілька зайвих речей - але єдиний раз, коли нетехнічний користувач побачить це, коли він піде не так.
Користувачі, sysadmins та розробники, які активно використовують та розробляють для Upstart, - це люди, яким потрібно займатися питаннями. На Ubuntu Wiki є міграційний документ, який допомагає розробникам конвертувати свої init-скрипти, але користувачі та sysops можуть продовжувати користуватися Upstart, дотримуючись 14.04 (який підтримується до 2019 року).
Причина та обґрунтування змін насправді не з боку Ubuntu. Canonical були досить задоволені Upstart (їх проектом), але багато користувачів Debian хотіли перейти до сучасного двигуна init, щоб отримати кращу одночасність під час завантаження та покращити функціональність моніторингу для всіх служб.
Це означало боротьбу між різними варіантами (обґрунтуваннями) і системними в підсумку виграно.
Canonical пішов разом з Debian, тому що це найпростіше і, мабуть, найкраще. Вони можуть кинути проект і не ведуть боротьбу за течією. Це також приводить нас у відповідність до інших дистрибутивів (Red Hat, Fedora тощо), які також переходять на systemd. Більше уваги та менше дублювання зусиль.
tl; dr Для не технічної особи це зовсім не повинно впливати на вас. Для Ubuntu це повинно означати менше роботи та кращу систему init.
Чи може хтось адекватно пояснити нетехнічному користувачеві, як і якщо це взагалі впливає на нас?
Теоретично це не повинно впливати на нетехнічного кінцевого споживача, який не втягується в солодку зернистість того, як система насправді працює. На практиці є багато речей, які ти збираєшся побачити.
Ось неповний список:
init+ rcукушений тим, що systemd сумісний лише з системою 5 rc. Як і на початку, і, як і у більшості інших систем, вона не вимагає сумісності із системою 5 initта її файлом конфігурації /etc/inittab.Тож люди, які дотримувались порад 30-ти років, коли люди радили "Ну, ви можете просто відредагувати це на /etc/inittab...", або люди, які використовують програмне забезпечення, яке слідувало за цією порадою, тепер має програмне забезпечення, яке не починається під час завантаження. Приклад: https://unix.stackexchange.com/a/196197/5132
shutdown, як це було можливо і в попередніх shutdownкомандах. Крім того, що його називають режимом порятунку в системному жаргоні, режим порятунку не вважається станом вимкнення в системному світогляді. Це розглядається як стан, що працює . shutdown nowвимкне машину. Це systemctl rescueдосягти режиму однокористування в системному світі. Подальше читання: https://unix.stackexchange.com/a/196471/5132--userможливістю до systemctl. Це не стосується Ubuntu (поки що). upstart і systemd істотно відрізняються в цій області, а Ubuntu версія 15 все ще використовує instart за сеанс init, а не системний екземпляр на користувача . Тому https://superuser.com/a/860598/38062, наприклад , не застосовується. ☺Як вже зазначали інші, теоретично це не повинно впливати на нетехнічного кінцевого споживача - і в теорії немає різниці між теорією та практикою, але на практиці існує.
Я думаю, що деякі речі, розміщені тут, потребують уточнення:
Це система init, а не те, з чим традиційно взаємодіють користувачі.
Так було і з SysV init, і з Upstart, але це вже не з системою. Він робить багато речей, з якими користувачі традиційно взаємодіють:
Він повинен повністю замінити функціонал, який надає Upstart, і зробити кілька додаткових речей
Слід уточнити дві речі - спочатку про повну заміну Upstart:
Однією з проблем, з якою люди стикаються з системою, є те, що він не запускає сценарії SysV init. Отож є один приклад того, що він не повністю замінює функціонал, наданий Upstart.
Це те, на що ми могли покластися більше 30 років, і традиційно ви писали сценарії SysV init для максимальної переносимості, не повторюючи себе (написавши кілька версій одних і тих самих сценаріїв), що вже не так.
Це не повинно бути проблемою при використанні лише пакетів з офіційних сховищ, оскільки, імовірно, всі пакети, в яких раніше були або SysV init, або Upstart сценарії, повинні були переписати свої сценарії, перш ніж вони будуть упаковані.
Це буде лише проблемою для людей, які випадково використовують будь-яке стороннє або користувальницьке програмне забезпечення, яке має свої сценарії init, написані або для SysV init, або для Upstart, і тим, хто потребує сценаріїв init, буде переписано перед оновленням до системи з systemd (або отримати встановлений на початку, що також є опцією , або перейти до системи, яка не використовує systemd).
Існує systemd-sysv-генератор, який повинен автоматично переводити сценарії init SysV в системні сценарії, але є деякі помилки та довгий список явних несумісностей .
Тепер, друге уточнення - про ці кілька зайвих речей:
Ці "кілька зайвих речей", які охоплює systemd - згідно з "Перспективою для системного" - що було досягнуто, а що - перед собою презентація Lennart Poettering в 2014 році на GNOME.asia - такі:
Тож повертаємось до: "Це система init, а не те, що користувачі традиційно взаємодіють". - слід зазначити, що система init - це лише один пункт у цьому списку.
І нарешті, останнє, що я хотів би прокоментувати:
[T] він лише раз, коли нетехнічний користувач побачить це, коли йде не так.
О, яке полегшення. :)
Найбільш помітні зміни для кінцевих користувачів (крім самих сценаріїв) - це запуск та зупинка послуг та використання команд, таких як:
які більше не працюють, як очікувалося. Наприклад, nohupце команда POSIX, щоб переконатися, що процес продовжує працювати після виходу з сеансу. Він більше не працює на systemd. Також такі програми, як screenі tmuxпотрібно викликати по-особливому, або в іншому випадку процеси, які ви запускаєте з ними, загинуть (хоча не отримувати цих процесів вбиті, як правило, головна причина запуску екрана або tmux в першу чергу).
Це не помилка, це вибір дизайну, тому вона, ймовірно, не виправиться в майбутньому. Ось що сказав Леннарт Поетрінг з цього приводу:
На мою думку, UNIX насправді був досить дивним, що він за замовчуванням дозволяв довільному коду користувача залишатись без обмежень після виходу з системи. Зараз багато людей ОС обговорювали, що це може бути можливим, але, звичайно, не за замовчуванням, але поки що ніхто не наважувався перевести комутатор, щоб перетворити його з замовчування на опцію. Не прибирати користувальницькі сеанси після виходу з мережі - це не тільки некрасиво і дещо шалено, але й проблема безпеки. systemd 230 тепер остаточно переключив перемикач і, нарешті, за замовчуванням все очистить правильно, коли користувач вийде з системи.
Для отримання додаткової інформації див:
screenscreensystemd-run --user --scope screen(Примітка: поведінка "upstart" вище - це справді все, крім систематизованого, це не конкретно для початку)
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status(Дивіться мою відповідь на те, які плюси та мінуси Upstart і systemd? Для отримання більш детальної інформації, яка виходить за рамки цього питання.)
Існує також велика різниця в обробці журналів, оскільки всупереч традиції Unix, журнали systemd зберігаються у бінарних файлах у власному форматі, тож замість:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
вам потрібно використовувати спеціальні команди для доступу до ваших журналів:
sudo journalctl -u foo
sudo journalctl -u foo -f
Введення systemd спочатку в Debian, а пізніше в Ubuntu не обійшлося без суперечок і широкого протистояння, як відомо кожному, хто написав одну з наступних статей:
Офіційна позиція Debian на Systemd і в результаті полеміка призвела до декларації Вих в 2014 році і закінчилася відставкою Яна Джексона .
Ініціативи Freedom , Without-Systemd.org та Systemd-Free.org народилися з великою кількістю дискусій про Hacker News .