Чому сервер Ubuntu має за замовчуванням системну ціль graphical.target?

Я деякий час був користувачем Ubuntu, і на роботі у нас є багато серверів Ubuntu VM , усі вони запущені Ubuntu 14.04 LTSдля розгортання наших веб-додатків, баз даних та інших інструментів.

Зараз я навчаюсь Ubuntu 16.04 LTS, настільні та серверні, щоб мати можливість оновити наші виробничі сервери найближчим часом без проблем.

Так як Ubuntu 15.04, initі upstartбули замінені Systemd, так що я вчуся Systemd теж.

Я помітив, що мій комп'ютер розробки під управлінням Ubuntu 16.04 Desktop Edition є graphical.targetтиповою системою за замовчуванням, що логічно.

Але потім я помітив, що тестовий сервер під управлінням версії Ubuntu 16.04 також використовується graphical.targetяк цільова системна ціль.

$ systemctl get-default
graphical.target

Тож я розгублений. У сервера немає графічного шару, тож як це ціль за замовчуванням graphical.target?

Редагувати № 0

Як запропонував у коментарях Рінцвінд, я подивився на ціль, щоб побачити, чи є вона активна чи ні ...

і відповідь ТАК:

admin@server1604:~$ systemctl get-default
graphical.target

admin@server1604:~$ systemctl status graphical.target
● graphical.target - Graphical Interface
Loaded: loaded (/lib/systemd/system/graphical.target; static; vendor preset: enabled)
Active: active since jeu. 2016-10-13 16:03:18 CEST; 46min ago
Docs: man:systemd.special(7)

oct. 13 16:03:18 fdea systemd[1]: Reached target Graphical Interface.

Тож я трохи більше розгублений.

Редагувати №1

Відповідь Марка Стосберга вказує на той факт, що display-manager.serviceє частиною дерева залежності graphical.targetвласного сервера 16.04, і він додає, що на його машині не встановлено і не працює жоден менеджер дисплеїв. Я теж на це подивився, і справді, на моєму сервері така залежність є:

admin@server1604:~$ systemctl list-dependencies graphical.target 
graphical.target
● ├─accounts-daemon.service
● ├─apache2.service
● ├─apport.service
● ├─display-manager.service

...

І ця мета має червоне коло ліворуч, де більшість інших залежностей має зелене.

І цього разу результат є послідовним:

admin@server16.04:~$ systemctl status display-manager.service 
● display-manager.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Але тут є ще одна дивна річ: у моєму настільному виданні значення display-manager.serviceне є залежністю graphical.target:

me@desktop16.04:~ $ systemctl list-dependencies graphical.target | grep display
me@desktop16.04:~ $ 

Але я навіть знайшов альтернативу, тому що працюю Ubuntu-Gnomeіз lightdmзаміною менеджера вікон за замовчуванням:

me@desktop16.04:~ $ systemctl list-dependencies graphical.target | grep lightdm
● ├─lightdm.service

Незважаючи на назву цілі, на Ubuntu Server 16.04 нічого графічного не працює. Ви можете використовувати цю команду, щоб перевірити і порівняти її з робочим столом, якщо вам подобається:

systemctl list-dependencies graphical.target 

На моєму сервері Ubuntu 16.04 я бачу, що цілі залежать від "display-manager.service", але не встановлений або запущений менеджер дисплеїв.

Я очікую, що сервери Ubuntu налаштовані таким чином для певної послідовності, хоча я згоден, що це заплутано.

З посібника з редагування :

Наприклад, блок graphical.target, який використовується для запуску графічного сеансу, запускає такі системні сервіси, як GNOME Display Manager (gdm.service) або Accounts Service (рахунки-daemon.service), а також активує багатокористувацького користувача. цільовий блок. Аналогічно, багатокористувацький цільовий блок запускає інші основні системні послуги, такі як NetworkManager (NetworkManager.service) або D-Bus (dbus.service) і активує інший цільовий блок, який називається basic.target.

Таким чином, це не неправильно для його встановлення, оскільки він не активує диспетчер дисплеїв, коли служба, що обробляє послугу відображення, не встановлена.

Для сервера ви можете встановити його, multi-user.targetале він не потрібен. Схоже, ви переходите на рівень 4, якщо ви цього робите, а рівень 5, коли цього не робите.

Runlevel    Target Units    Description
0   runlevel0.target, poweroff.target   Shut down and power off the system.
1   runlevel1.target, rescue.target     Set up a rescue shell.
2   runlevel2.target, multi-user.target     Set up a non-graphical multi-user system.
3   runlevel3.target, multi-user.target     Set up a non-graphical multi-user system.
4   runlevel4.target, multi-user.target     Set up a non-graphical multi-user system.
5   runlevel5.target, graphical.target  Set up a graphical multi-user system.
6   runlevel6.target, reboot.target     Shut down and reboot the system. 

Детальніше перевіряючи залежність цілі від першого рівня дерева graphical.target:

admin@server1604:~$ systemctl list-dependencies graphical.target 
graphical.target
● ├─accounts-daemon.service
● ├─apache2.service
● ├─apport.service
● ├─display-manager.service              (disabled)
● ├─grub-common.service
● ├─irqbalance.service
● ├─mdadm.service
● ├─ondemand.service
● ├─sysstat.service
● ├─systemd-update-utmp-runlevel.service (disabled)
● ├─ureadahead.service                   (disabled)
● └─multi-user.target

порівнюючи його з першим рівнем multi-user.target:

admin@server16.04:~$ systemctl list-dependencies multi-user.target
multi-user.target
● ├─apache2.service
● ├─apport.service
● ├─atd.service
● ├─cron.service
● ├─dbus.service
● ├─grub-common.service
● ├─irqbalance.service
● ├─lxcfs.service
● ├─lxd-containers.service
● ├─mdadm.service
● ├─networking.service
● ├─ondemand.service
● ├─open-vm-tools.service

...

Я помітив , що , якщо ми видалимо відключені цілі в graphical.targetдереві ( display-manager.service, systemd-update-utmp-runlevel.service, ureadahead.service), майже всі з решти:

• apache2.service
• apport.service
• grub-common.service
• grub-common.service
• irqbalance.service
• mdadm.service
• ondemand.service
• і sysstat.service

вже включені до першого рівня дерева залежності multi-user.target.

Хоча, ми повинні ще раз запитати про цей факт, адже graphical.targetзалежність від цього multi-user.targetне потрібна в усіх цих речах. Це звучить досить дивно.

Але після цього зменшення це залишається однією службою, як accounts-daemon.service, як зазначив у своєму коментарі Рінцвінд .

Таким чином, ми можемо припустити, що graphical.targetнеобхідне для завантаження accounts-daemon.service.

Однак у цьому випадку це знову дивно, тому що я думаю, було б більше сенсу створити цільову ціль для цієї мети, можливо, щось подібне accounts.targetабо будь-який правильний термін, щоб описати це. У будь-якому випадку, напевно, у розробників Canonical були свої причини змусити мислити так.

Але мені цікаво знати її причини.