Comment accélérer le démarrage avec systemd ?

Support Debian
#1

Si mes connaissances sont suffisantes, un démarrage avec systemd a remplacé l’ancien boot avec init.d .
Ce qui à priori m’est égal, du moment que ça démarre.

Avec le nouveau démarrage, on a au début du boot deux instructions du type suivant :
(je ne trouve pas dans les différends /var/log/ les lignes exactes qui s’affichent à l’écran, alors je recopie)

[ x.xxxxxx]systemd-fsck[xxx] : /dev/sda1e : propre etc (suit le nombre de blocs)
[ x.xxxxxx]systemd-fsck[xxx] : /dev/sda6e : propre etc…

puis le démarrage passe à la suite.

C’est à dire qu’il y a un long temps d’attente avant l’arrivée de l’interface graphique, sans affichage à l’écran, plus de 1 mn.

En mode réparation on peut voir ce qui se passe.
Une tâche se lance en toile de fond :

A start job is running for dev-disk-by\x2duuid-7dxxxxxxxxxxxx.device

(les xxxxxxxxx représentant une série de chiffres ou caractères, des étoiles qui défilent accompagnent le déroulement de ce processus)

Questions :

  • que fait cette tâche

  • est elle vraiment indispensable et peut-elle être désactivée ?

#2

[quote=“taureau89_9”][ x.xxxxxx]systemd-fsck[xxx] : /dev/sda1e : propre etc (suit le nombre de blocs)
[ x.xxxxxx]systemd-fsck[xxx] : /dev/sda6e : propre etc…[/quote]Il semblerait que ton/tes partitions aient besoin d’être vérifiées et/ou réparées (fsck <=> File System ChecK) avant de pouvoir être utilisées.
Peut-être est-ce un problème(s) de disque(s), ou/et un/des problème(s) avec une/des applications qui se “ferment” mal ?

[quote=“taureau89_9”]… long temps d’attente avant l’arrivée de l’interface graphique, sans affichage à l’écran, plus de 1 mn …[/quote]Je constate aussi que l’initialisation du mode graphique prends beaucoup de temps (c’est pas nouveau), et rêve qu’un jour les informations sur tous les composants pourront êtres disponibles pour tous, ce qui permettra aux développeurs de régler ce genre de problème, mais une minute, ça me semble vraiment très long.

[quote=“taureau89_9”]- que fait cette tâche

  • est elle vraiment indispensable et peut-elle être désactivée ?[/quote]Pour répondre à ces questions, il faudrait d’abord savoir de quelle tâche il s’agit, et qu’est-ce qui la déclenchée, mais là, je vois pas…

EDIT: Ceci dit, une fois le problème de disque/partition réglé, il est fort possible que tout rentre dans l’ordre.
Tu pourrais essayer en réinstallant, juste pour tester, sur un autre disque (après avoir déconnecté et éloigné ceux qui causent le problème),
et/ou tester les disques suspects (un après l’autre) sur une autre machine, rien que pour voir si leur lecture peut se faire sans un “fsck” au préalable.

#3

Quelle est la nature de ce support de stockage ? Partition plate ? Volume logique ? Composant d’un RAID ?
Quel système de fichiers ?
Serait-ce une partition swap ? Serait-elle mobilisée par une hibernation ?resume=???
Voir arguments au démarrage

Regarde si ce support de stockage est correctement référencé en /etc/fstab.
En /etc/fstab,les partitions peuvent être référencées par leur uuid (UUID=???), par leur label (LABEL=???) ou,à l’ancienne, par /dev/sd??.
Généralement, les debian contemporaines s’appuyent sur les UUID.
Compare les UUID de /etc/fstab à celles de

En /etc/fstab, à la ligne intéressante, voir aussi la valeur du sixième champ .

$ man -L fr fstab

Le sixième champ (fs_passno) Ce champ est utilisé par le programme fsck(8) pour déterminer l'ordre de vérification des sys‐ tèmes de fichiers au démarrage. Le système de fichiers racine doit avoir un champ fs_passno de valeur 1, et les autres un champ fs_passno de valeur 2. Les systèmes partageant le même contrô‐ leur seront vérifiés à la suite, mais ceux utilisant différents contrôleurs seront vérifiés simultanément pour profiter du parallélisme offert par le matériel. Si le sixième champ est absent ou vaut zéro, fsck ne vérifiera pas ce système de fichiers.

#4

[quote=“MicP”][quote=“taureau89_9”][ x.xxxxxx]systemd-fsck[xxx] : /dev/sda1e : propre etc (suit le nombre de blocs)
[ x.xxxxxx]systemd-fsck[xxx] : /dev/sda6e : propre etc…[/quote]Il semblerait que ton/tes partitions aient besoin d’être vérifiées et/ou réparées (fsck <=> File System ChecK) avant de pouvoir être utilisées.
Peut-être est-ce un problème(s) de disque(s), ou/et un/des problème(s) avec une/des applications qui se “ferment” mal ?[/quote]
Non, tout est normal ici, l’état des partitions est vérifiée au démarrage même s’il n’y a pas eu de problème avec.

#5

si tu enlèves le “quiet” de la commande de boot dans le grub , le lancement sera plus bavard.

#6

Juste pour expliquer pourquoi j’ai suggéré cette éventualité de panne:

Que [mono]/dev/sda1[/mono] ou [mono]/dev/sda6[/mono] soient vérifiés, ok, mais là, cela fait déjà deux partitions.
En fait, a moins d’avoir spécifié dans [mono]/etc/fstab[/mono] (6ème champ) de vérifier chacune des partitions,
normalement, seule la partition racine (si pas [mono]/boot[/mono], [mono]/usr[/mono], etc… séparé) est vérifiée à chaque démarrage.

Bon, il pourrait très bien s’agir d’un LVM, ou d’un autre système de fichiers utilisé pour la racine et utilisant plusieurs partitions,
mais quand je vois (en plus) qu’en mode réparation:
[mono]A start job is running for dev-disk-by\x2duuid-7dxxxxxxxxxxxx.device[/mono]
Je me dis (conscient que je n’ai pas assez de renseignements) qu’il est possible que ce soit un problème de disque,
qui pourrait aussi expliquer cette longue minute d’initialisation du mode graphique.

#7

Oui et non, misaine.
Car lorsque je lance le démarrage en mode réparation, je les ai, toutes ces lignes.
C’est ce qui m’a permis de déceler ce processus de “a start job is running for dev-disk-by\etc…”.
Mais ta remarque est intéressante quand même, car entre les deux “systemd-fsck” du début de boot et l’apparition de ce “a start job…”, il faut que je précise qu’une foule conséquente de processus sont lancés, et le “a start job…” n’a plus rien à voir avec les deux “systemd-fsck” du début de boot (qui sont d’ailleurs déclarés comme propres).
D’ailleurs avec l’ancien système de démarrage avec init.d, mes partitions ont toujours été clean.

J’aimerais donc en savoir plus sur la nature de ce “a start job is running …”.

J’ai bien installé le paquet bootlogd, mais je n’ai toujours rien dans /var/log/boot , pour pouvoir recopier proprement les lignes de boot (j’ai pourtant suivi les conseils de ce wiki.

Je vais essayer aussi de zieuter sur ce que me demande exteberrizahar (ouf, dur à recopier, le pseudo !)

#8

Salut,

Les délais d’attente de genre 1 minute, 30 secondes, etc. correspondent à des timeout de systemd. Une opération échoue et il réessaye pendant ce temps.

Typiquement, cela arrive quand le fstab contient un montage qui ne peut pas être monté au démarrage, sans que l’option «nofail» soit précisée.

Une commande pratique (mais pas parfaite) pour voir où le temps est perdu est systemd-analyse.

Indique quelles opérations font perdre du temps.

Et

Te génère un graph complet du temps de boot :slightly_smiling:

Voilà qui devrait te donner quelques pistes !

#9

exteberrizahar, voici l’image de mon système :

C’est une installation que j’ai faite il y a plus de deux ans, lorsque je me suis refait une configuration matérielle neuve.
Avec un /home séparé de mon système.
Et en testing, toujours restée en testing depuis, sans jamais changer de sources.list et de preferences (c’était déjà bien avany que wheezy ne passe en nouvelle stable).
Installation mise à jour fréquemment.

andre@990FX6100:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 root=UUID=7333f23d-d8d4-449d-a302-b024af27408e ro

[code]andre@990FX6100:~$ cat /etc/fstab

/etc/fstab: static file system information.

Use ‘blkid’ to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).

proc /proc proc defaults 0 0

/ was on /dev/sda1 during installation

UUID=7333f23d-d8d4-449d-a302-b024af27408e / ext4 errors=remount-ro 0 1

/home was on /dev/sda6 during installation

UUID=3cc10bd9-3b44-40b2-9fb0-2148c379c686 /home ext4 defaults 0 2

swap was on /dev/sda5 during installation

UUID=7d0bb58e-55c4-4366-9dc4-f1008302f69c none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/sdb1 /media/usb0 auto rw,user,noauto 0 0 [/code]

andre@990FX6100:~$ ls -l /dev/disk/by-uuid total 0 lrwxrwxrwx 1 root root 10 août 3 08:27 3cc10bd9-3b44-40b2-9fb0-2148c379c686 -> ../../sda6 lrwxrwxrwx 1 root root 10 août 3 08:27 7333f23d-d8d4-449d-a302-b024af27408e -> ../../sda1 lrwxrwxrwx 1 root root 10 août 3 08:27 edb8d291-004c-436a-9868-9c072d8ef772 -> ../../sda5

Pour le sixième champ, j’ai pas trop pigé, je vois pas de fs_passno…

Je regarde aussi les suggestions de captnfab.

#10

[quote=“MicP”]En fait, a moins d’avoir spécifié dans [mono]/etc/fstab[/mono] (6ème champ) de vérifier chacune des partitions,
normalement, seule la partition racine (si pas [mono]/boot[/mono], [mono]/usr[/mono], etc… séparé) est vérifiée à chaque démarrage.[/quote]
Tu es sûr de ça ? Il me semble pas avoir bidouillé mon fstab depuis la dernière install, et mon /home est vérifié également.

#11

Je suis exactement dans la même situation (ancienne testing mise à jour hebdomadairement), et rencontre le même problème. Je vais faire les vérifs d’UID des disques, mais dans mon cas, il est possible que ce soit d’anciens montages de disques qui n’existent plus qui posent probléme.
Je vais instiguer de mon coté et essayer d’apporter des pistes.

Je constate déja que ce qui prends le plus de temps:

ntp.service @1min 49.635s +1min 17.612s systemd-tmpfiles-clean.timer @1min 48.909s console-screen.service @1min 48.490s +275ms
et un montage qui n’existe plus (à virer du fstab) : 1 mn 30 s

J’utilise systemd sur une Arch, et ça décoiffe (en plus avec disque ssd).

#12

[quote=“taureau89_9”]… Pour le sixième champ, j’ai pas trop pigé …[/quote]Pas de problèmes avec le sixième champ: tu as une partition [mono]/home[/mono] et une [mono]/[/mono] séparées.

[mono]fs_passno[/mono] (autrement dit: 6ème champ) à:
1 => première à être vérifiée (normal: c’est la racine dans ton [mono]/etc/fstab[/mono])
2 => à vérifier après ([mono]/home[/mono] dans ton [mono]/etc/fstab[/mono])
0 => pas de vérification (car non indispensable au démarrage et fonctionnement du système)

Et tout cela explique pourquoi:

[quote][ x.xxxxxx]systemd-fsck[xxx] : /dev/sda1e : propre etc (suit le nombre de blocs)
[ x.xxxxxx]systemd-fsck[xxx] : /dev/sda6e : propre etc…[/quote]Ce qui est donc tout-à fait normal.

#13

Sur la capture de gparted nous remarquons la partition swap /dev/sda5. Nous remarquons aussi sa taille,près de 32 Go, de quoi swapper jusqu’à plus swap …
Voyons l’uuid de la partition swap /dev/sda5 :

Retenons [mono]UUID=edb8d291-004c-436a-9868-9c072d8ef772[/mono]
et comparons cet uuid à celui de swap en /etc/fstab.

[quote]# swap was on /dev/sda5 during installation UUID=7d0bb58e-55c4-4366-9dc4-f1008302f69c none swap sw 0 0[/quote]

L’uuid de swap en /etc/fstab ne colle pas. /etc/fstab référence un uuid qui ne correspond pas (|| qui ne correspond plus) à /dev/sda5.
Remplace [mono][strike]UUID=7d0bb58e-55c4-4366-9dc4-f1008302f69c[/strike][/mono] par [mono]UUID=edb8d291-004c-436a-9868-9c072d8ef772[/mono] en /etc/fstab.

#14

Yeah! super bien vu :023 , d’autant que le message est: [mono]A start job is running for dev-disk-by\x2duuid-7dxxxxxxxxxxxx.device[/mono]

#15

Un grand merci à toi, exteberrizahar.

Les UUID, faudrait bien qu’un jour je regarde ce que c’est et à quoi ça sert !

Même problème, même solution pour toi, peut-être piratebab … :115

#16

[quote=“piratebab”]
J’utilise systemd sur une Arch, et ça décoiffe (en plus avec disque ssd).[/quote]
je confirme , juste une poignée de secondes 8)

#17

Dans mon cas, c’est un montage nfs qui n’existe plus mais qui est toujours dans le fstab.
Mais pour les autres temps indiqués, c’est relativement long pour un systemd je trouve.

#18

[quote=“etxeberrizahar”]Sur la capture de gparted nous remarquons la partition swap /dev/sda5. Nous remarquons aussi sa taille,près de 32 Go, de quoi swapper jusqu’à plus swap …[/quote]Pour la petite histoire, ce n’est pas moi qui ai déterminé la taille du swap, mais l’installeur Debian, qui m’a automatiquement dimensionné les partitions (il y a sûrement moyen de lui imposer les tailles).

Malheureusement si le swap était pléthorique, il s’est vite avéré que le système était lui trop petit, il faisait dans les 10 Gio et s’est vite trouvé saturé.

Qu’ai-je fait ?

J’ai booté sur un disque UBCD.
Puis j’ai rapetissé /dev/sda6 de 20 Gio, toujours avec gparted.

Opération qui n’est sûrement pas sans risque (et qui prend du temps), car elle déplace les données contenues dans le /home, pour les poussotter 20 Gio plus loin !
Mais tout s’est bien passé.

Puis j’ai augmenté le swap, donc /dev/sda5 , d’autant.

A ce moment là je n’avais aucune idée de la taille que doit avoir un swap, je n’ai donc pas prélevé dessus.

Enfin, j’ai transféré les 20 Gio de /dev/sda5 à /dev/sda1 , d’où sa taille actuelle.

Bref, quand on ne sait pas, on arrive quand même à se débrouiller !

#19

pour les UUID, c’est assez simple:

Dès qu’une partition est formatée, son système de fichier est “taggé” avec ce fameux Universal Unique IDentifier.

Alors que l’on peuplait à la main (il y a bien longtemps) le répertoire [mono]/dev[/mono],
ce serait extrêmement laborieux à faire de nos jours car le nombre de périphériques possibles a considérablement augmenté.

C’est donc [mono]udevd[/mono] qui réponds au signaux du noyau (quand il détecte qu’un périphérique viens de se connecter et/ou s’initialise),
et qui va créer le fichier de périphérique dans le répertoire [mono]/dev[/mono].

Ce faisant, certains disques (ou autres périphériques) peuvent être plus ou moins rapides à l’initialisation,
ce qui fait que la référence au nom du fichier de périphérique pourrait très bien changer d’un démarrage à l’autre, mais PAS l’UUID, puisqu’il est un identifiant unique à chaque partition.

Finalement, on remplace tout simplement, dans [mono]/etc/fstab[/mono], les références [mono]/dev/sdxx[/mono] par l’[mono]UUID[/mono] du système de fichier de la partition correspondante.

Voir :
ls -l /dev/disk/by-uuid

et les "man"s
man udevd
man udev
man blkid