LINUX.ORG.RU
решено ФорумAdmin

systemd: services wanted by multi-user.target

 ,


0

4

UPDATE: systemd норм, я лох; btrfs диски долго монтируются, но про это отдельно. Тема закрыта.


systemd-хейтеров прошу пройти мимо, не засирать тему.

Решил я ускорить загрузку системы. Для начала посмотрел что её тормозит:

# systemd-analyze critical-chain
graphical.target @18.585s <<<=== LOOK AT THIS <<<===
└─multi-user.target @18.585s
  └─apcupsd.service @18.576s +7ms
    └─network-online.target @18.575s
      └─NetworkManager-wait-online.service @11.740s +6.833s
        └─NetworkManager.service @11.694s +44ms
          └─network-pre.target @11.693s
            └─firewalld.service @10.930s +762ms
              └─polkit.service @11.225s +152ms
                └─basic.target @10.926s
                  └─dbus-broker.service @10.991s +139ms
                    └─dbus.socket @10.922s
                      └─sysinit.target @10.916s
                        └─systemd-update-utmp.service @10.906s +9ms
                          └─auditd.service @10.861s +41ms
                            └─systemd-tmpfiles-setup.service @10.786s +72ms
                              └─local-fs.target @10.782s
                                └─mnt-.transmission.mount @2.362s +8.418s <<<=== LOOK AT THIS <<<===
                                  └─local-fs-pre.target @2.360s
                                    └─systemd-tmpfiles-setup-dev.service @874ms +32ms
                                      └─kmod-static-nodes.service @829ms +11ms
                                        └─systemd-journald.socket
                                          └─system.slice
                                            └─-.slice

Менюшка логина появляется на 19-той секунде, не слишком быстро. Почти 7 секунд NetworkManager ждал когда интернет появится, но сейчас не об этом. В данный момент меня интересует mnt-.transmission.mount, который съел 8 секунд. Вот этот юнит:

# systemctl cat mnt-.transmission.mount
[Unit]
Description = Transmission storage disk
Before      = transmission-daemon.service
[Mount]
Type  = btrfs
What  = /dev/disk/by-uuid/84ebf9fc-dbd0-4a29-a38f-109e71957dee
Where = /mnt/.transmission
[Install]
RequiredBy = transmission-daemon.service

Монтирование двухтерабайтного диска и вправду занимает 8 секунд:

# time systemctl start mnt-.transmission.mount
real    0m8.389s
user    0m0.008s
sys     0m0.005s

Ладно, пробую сделать ленивое монтирование, авось поможет. Добавляю .automount:

# systemctl cat mnt-.transmission.automount
[Unit]
Description = Transmission storage disk
Before      = transmission-daemon.service
[Automount]
Where = /mnt/.transmission
[Install]
RequiredBy = transmission-daemon.service

Далее:

# systemctl disable mnt-.transmission.mount
# systemctl enable mnt-.transmission.automount
# reboot

Результат:

# systemd-analyze critical-chain
graphical.target @14.081s
└─multi-user.target @14.081s
  └─transmission-daemon.service @3.493s +10.586s <<<=== LOOK AT THIS <<<===
    └─mnt-.transmission.mount @3.681s +8.283s
      └─mnt-.transmission.automount @2.300s
        └─local-fs-pre.target @2.299s
          └─systemd-tmpfiles-setup-dev.service @879ms +34ms
            └─kmod-static-nodes.service @833ms +13ms
              └─systemd-journald.socket
                └─system.slice
                  └─-.slice

На 4 секуднды быстрее, но всё равно как-то не быстро. Пробую убрать из mnt-.transmission.mount строчку

Before      = transmission-daemon.service

Не помогает, всё те же 14 секунд, 10 из которых сожрал transmission-daemon.service. Не он сам, конечно, это всё то же монтирование /mnt/.transmission, только теперь неявное.

Но вот вопрос: почему multi-user.target ждёт готовности transmission-daemon.service? multi-user.target про transmission ничего не знает, но transmission-daemon.service в курсе про multi-user.target:

# systemctl cat transmission-daemon.service
[Unit]
Description=Transmission BitTorrent Daemon
After=network.target
[Service]
User=transmission
Type=notify
ExecStart=/usr/bin/transmission-daemon -f --log-error
ExecReload=/bin/kill -s HUP $MAINPID
[Install]
WantedBy=multi-user.target <<<=== LOOK AT THIS <<<===

WantedBy указывает что при старте multi-user надо запустить transmission-daemon, но, вроде бы, не говорит что надо ждать его готовности… Однако:

# man systemd.target
...
Target units will automatically complement all configured dependencies of 
type Wants= or Requires= with dependencies of type After=...

Вот в чём засада: multi-user.target ждёт готовности всех сервисов, которые к нему навязавлись через WantedBy=multi-user.target.

Однако:

...unless DefaultDependencies=no is set in the specified units.

Ok, пробую добавить DefaultDependencies=no в transmission-daemon.service:

# systemctl cat transmission-daemon.service 
[Unit]
Description=Transmission BitTorrent Daemon
DefaultDependencies=no <<<=== LOOK AT THIS <<<===
After=network.target
[Service]
User=transmission
Type=notify
ExecStart=/usr/bin/transmission-daemon -f --log-error
ExecReload=/bin/kill -s HUP $MAINPID
[Install]
WantedBy=multi-user.target

Результат:

# systemd-analyze critical-chain
graphical.target @10.684s <<<=== LOOK AT THIS <<<===
└─multi-user.target @10.684s
  └─apcupsd.service @10.676s +6ms
    └─network-online.target @10.674s
      └─NetworkManager-wait-online.service @3.681s +6.992s
        └─NetworkManager.service @3.635s +43ms
          └─network-pre.target @3.633s
            └─firewalld.service @2.834s +798ms
              └─polkit.service @3.177s +144ms
                └─basic.target @2.823s
                  └─dbus-broker.service @2.921s +158ms
                    └─dbus.socket @2.806s
                      └─sysinit.target @2.785s
                        └─systemd-update-utmp.service @2.776s +8ms
                          └─auditd.service @2.728s +41ms
                            └─systemd-tmpfiles-setup.service @2.655s +67ms
                              └─local-fs.target @2.645s
                                └─run-user-1001.mount @13.492s
                                  └─local-fs-pre.target @2.445s
                                    └─systemd-tmpfiles-setup-dev.service @910ms +44ms
                                      └─kmod-static-nodes.service @858ms +20ms
                                        └─systemd-journald.socket
                                          └─-.mount
                                            └─systemd-journald.socket
                                              └─...

Опять вылез NetworkManager-wait-online.service, но transmission-daemon.service пропал! Бинго!?

Вопросы:

  1. 8 секунд на монтирование двухтерабайтного диска — это нормально? Это btrfs такой быстрый или диск медленный?

  2. Чисто теоретически: Зачем .target ждёт готовности всех сервисов, которые к нему навязались через WantedBy?

  3. Есть ли способы запустить сервис, но не дожидаться его готовности без использования DefaultDependencies=no? Хз что там ещё было в этих зависимостях по умолчанию, мне кажется, что DefaultDependencies=no — слишком грубо.

★★★★★

Последнее исправление: debugger (всего исправлений: 1)

Чисто теоретически: Зачем .target ждёт готовности всех сервисов, которые к нему навязались через WantedBy?

Так группировка стандартная

Есть ли способы запустить сервис, но не дожидаться его готовности без использования DefaultDependencies=no? Хз что там ещё было в этих зависимостях по умолчанию, мне кажется, что DefaultDependencies=no — слишком грубо.

Service.Type=exec. Оно тебе надо?

DllMain
()

8 секунд на монтирование двухтерабайтного диска — это нормально?

Нет, это очень не нормально. Я бы посмотрел SMART этого диска.

dexpl ★★★★★
()
[Install]
RequiredBy = transmission-daemon.service

разве это нужно в automount-юните?

Вообще, в systemd рекомендуют не писать mount-юниты руками, а редактировать /etc/fstab. Лично я бы монтировал эту шару с флагами noauto, nofail, и x-systemd.automount, и запускал бы торрент-клиент в пользовательской сессии (зачем ему права рута или отдельный юзер?).

Lrrr ★★★★★
()

Проходил мимо и решил сказать, что у меня система загружается за 2 секунды, полторы из которых это опрос USB и получение айпишника. И кто теперь хейтер системд после этого? Ахахаха то есть пук.

anonymous
()
Ответ на: комментарий от anonymous

у меня система загружается за 2 секунды, полторы из которых это опрос USB и получение айпишника

Proof or GTFO.

intelfx ★★★★★
()

Решил я ускорить загрузку системы. Для начала посмотрел что её тормозит:

# systemd-analyze critical-chain

Ты неправильно пользуешься critical-chain. Надо смотреть critical-chain до твоего DM (systemd-analyze critical-chain display-manager.service). Что там стартует параллельно с ним, волновать в принципе не должно.

Тред и остаток шапки не читал. Алсо, как уже сказали, писать .mount/.automount-юниты руками не рекомендуется. Правь fstab.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Нотариусы, к сожалению, сейчас не работают. Но после карантина — обязательно. Пока можешь просто поверить, если хочешь, конечно.

А у тебя сколько?

anonymous
()
Ответ на: комментарий от Lrrr

разве это нужно в automount-юните?

Нужно:

# systemctl enable mnt-.transmission.automount 
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Вообще, в systemd рекомендуют не писать mount-юниты руками…

Не один ли хрен, написан юнит руками или сгенерирован из fstab?

и запускал бы торрент-клиент в пользовательской сессии (зачем ему права рута или отдельный юзер?).

?? Торрент-качалка работает как пользователь transmission, рут ей не нужен. Равно как и пользовательская сессия.

По существу вопроса что-нибудь есть?

debugger ★★★★★
() автор топика
Ответ на: комментарий от dexpl

Нет, это очень не нормально. Я бы посмотрел SMART этого диска.

Посмотрел. Криминала не нашёл. Smart очень похож на smart другого такого же диска (были куплены одновременно, долго работали вместе, потом один я оставил, а второй снял).

Запустил Gnome disk benchmark, скрости чтения, записи и поиска тоже похожи.

Создал на втором диске btrfs. Монтируется быстро. Но второй диск пустой, в то время как первый — забит почти под завязку.

Запускал на первом btrfsck, ошибок не обнаружено.

При втыкании в компьютер что первого, что второго в логах только вот это:

[ 2099.401599] ata5: link is slow to respond, please be patient (ready=0)
[ 2100.961642] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2100.962428] ata5.00: ATA-8: ST2000VM003-1CT164, SC23, max UDMA/133
[ 2100.962430] ata5.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[ 2100.963332] ata5.00: configured for UDMA/133
[ 2100.963468] scsi 4:0:0:0: Direct-Access     ATA      ST2000VM003-1CT1 SC23 PQ: 0 ANSI: 5
[ 2100.963815] sd 4:0:0:0: [sdd] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[ 2100.963818] sd 4:0:0:0: [sdd] 4096-byte physical blocks
[ 2100.963832] sd 4:0:0:0: [sdd] Write Protect is off
[ 2100.963834] sd 4:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[ 2100.963855] sd 4:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2100.964059] sd 4:0:0:0: Attached scsi generic sg3 type 0
[ 2101.026526]  sdd: sdd1
[ 2101.027160] sd 4:0:0:0: [sdd] Attached SCSI removable disk
[ 2101.238564] BTRFS: device fsid 9e83cb55-06be-46f2-80cd-1289ce181598 devid 1 transid 10 /dev/sdd1 scanned by systemd-udevd (9797)
[ 2101.439749] BTRFS info (device sdd1): disk space caching is enabled
[ 2101.439750] BTRFS info (device sdd1): has skinny extents

У разных дисков fsid и transid разные, всё остальное один-в-один.

Разве что скопировать барахло с первого диска на второй и посмотреть как скажется это на времени монтирования…

debugger ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Ты неправильно пользуешься critical-chain. Надо смотреть critical-chain до твоего DM…

Да, тут я лажанулся. Если выкинуть диски, то gdm появляется уже на четвёртой секунде:

# systemd-analyze critical-chain gdm.service
gdm.service +11ms
└─systemd-user-sessions.service @3.560s +10ms
  └─remote-fs.target @3.559s
    └─remote-fs-pre.target @3.559s
      └─iscsi-shutdown.service @3.556s +86us

Значит, надо менять название темы на «Почему btfrs разделы долго монтируются». Двухтерабайтный диск у меня монтируется 8 секунд, а десятитерабайтный — около 15. Это нормально?

debugger ★★★★★
() автор топика
Ответ на: комментарий от debugger

Значит, надо менять название темы на «Почему btfrs разделы долго монтируются»

…и добавлять тэг btrfs в надежде призвать спецов по оному.

dexpl ★★★★★
()
Ответ на: комментарий от anonymous

В биосе SATA Mode какой стоит?

AHCI.

debugger ★★★★★
() автор топика
Ответ на: комментарий от anonymous
# lshw -class storage
  *-sata
       description: SATA controller
       product: 6 Series/C200 Series Chipset Family 6 port Desktop SATA AHCI Controller
       vendor: Intel Corporation
       physical id: 1f.2
       bus info: pci@0000:00:1f.2
       logical name: scsi0
       logical name: scsi1
       logical name: scsi2
       logical name: scsi4
       version: 05
       width: 32 bits
       clock: 66MHz
       capabilities: sata msi pm ahci_1.0 bus_master cap_list emulated
       configuration: driver=ahci latency=0
       resources: irq:28 ioport:f090(size=8) ioport:f080(size=4) ioport:f070(size=8) ioport:f060(size=4) ioport:f020(size=32) memory:fe725000-fe7257ff
debugger ★★★★★
() автор топика
Ответ на: комментарий от debugger

Это материнка с третьеми сата значит, подумалось что режим

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.