Question de procédure, de manière de faire, etc., pour arrêter un script

Version imprimable

Voir 40 message(s) de cette discussion en une page

09/03/2021, 12h54
Jipété

Question de procédure, de manière de faire, etc., pour arrêter un script

Bonjour,

Pour des besoins ponctuels de tests, j'envisage de mettre en place un script qui va analyser la sortie de mount (filtrée sur "/dev/sd" pour voir l'ordre des disques car systemd sur ce coup-là c'est du grand n'importe quoi.)
J'ai une piste pour forcer une certaine régularité dans le nommage des disques mais il faut que je teste ça intensément, d'où le script.

Et dans le script il y a un contrôle :
- disques en vrac --> on loggue et on arrête le script -- facile.
- disques ok --> on loggue et on reboote -- comment arrêter le script si besoin ?

Parce que si ma combine de forçage des noms est bonne, la machine ne va plus s'arrêter de rebooter et ça, non ! Faut quand même que je puisse reprendre la main, de temps en temps. :mrgreen:

J'avais donc pensé à un appui sur une touche pendant la séquence de boot (qui va activer mon script), mais est-ce qu'une touche peut être prise en compte alors qu'il n'y a pas encore d'utilisateur loggué ?
C'est la question qui me turlupine -- oui, je sais, je n'ai qu'à tester, mais si de base la réponse est négative, à quoi bon passer du temps dessus ?

Vous feriez comment, vous ?
Merci pour les retours,
09/03/2021, 13h18
N_BaH

Bonjour,

Citation:

([...]voir l'ordre des disques car systemd sur ce coup-là c'est du grand n'importe quoi.)

il me semble que systemd fait avec ce que lui donne "le BIOS", sinon ça ferait ça sur toutes les machines.

pour ton script , utilise les UUID, ou des labels (ces derniers pouvant être définis après formatage)
09/03/2021, 13h33
Jipété

Citation:

Envoyé par N_BaH

il me semble que systemd fait avec ce que lui donne "le BIOS", sinon ça ferait ça sur toutes les machines.

il fait avec ce que le bios lui donne, oui, mais il fait ça en parallèle (c'est le but) et à quelques poullièmes de nanosecondes près je me retrouve des fois avec sdb1 monté sur / alors que ça devrait être sda1.
Et le plus dément, c'est que si df ou parted ou mount ou d'autres remontent n'importe quoi, ls / va m'afficher les bons fichiers de la racine, que la partition qui y est montée soit sda1 ou sdb1 -- un mystère complet.

Et ça doit faire ça sur toutes les machines multi-disques, c'est connu sur le web (pas de liens sous la main). Je propose qu'on ne fasse pas une digression vers systemd, je pense avoir trouvé une manière de rédiger les fichiers .mount qui devrait convenir, d'où le test intense.

Citation:

Envoyé par N_BaH

pour ton script, utilise les UUID, ou des labels (ces derniers pouvant être définis après formatage)

Même remarque que précédemment.

La question porte bien sur la manière d'arrêter un test lancé au boot, par un utilisateur pas encore loggué.
09/03/2021, 13h47
disedorgue

Perso, la piste que je suivrais, c'est de me baser sur la séquence de boot:
2 boot possible, le défaut, fait le test intensif, l'autre ne le fait pas et me donne la main pour pouvoir débrancher le test.
09/03/2021, 14h04
N_BaH

sur de nombreuses de mes machines, il y a plusieurs disques, et ce désordre erratique n'est apparu qu'une seule fois.
donc, ça existe. c'est décrit sur le net. mais ça ne concerne pas toutes les machines.
tu le sais, les manifestations de l'existence d'un événement, qui nous touche aussi, provoque un effet loupe, qui donne l'impression de masse et de proximité. Mais ce n'est qu'une impression. :whistle: « it's just an illusion » :whistle: :)

si, finalement, le montage est correct, alors quel est le problème ?
si tu as des scripts qui se réfère au nommage des disques (sda sdb ...) réécris-les en les faisant se référer aux UUID; ils sont disponibles dans l'absolu (càd même après transfert d'une machine à une autre).

dans le brouillard, je n'avance pas.
09/03/2021, 14h47
Jipété

Citation:

Envoyé par disedorgue

Perso, la piste que je suivrais, c'est de me baser sur la séquence de boot:
2 boot possible, le défaut, fait le test intensif, l'autre ne le fait pas et me donne la main pour pouvoir débrancher le test.

Je ne vois pas bien ce que tu veux dire. Ce que je pense, moi, c'est de ne rien changer, juste rajouter un script qui se lance au boot et qui va regarder qui est monté sur / puis test : c'est sda1 (= ok) alors reboot, et comme ça ad vitam æternam ou tout au moins, jusqu'à un test en erreur (sdb1 monté sur /), tout ça dans une machine virtuelle, avant de passer à la vraie vie.

Mais si ma correction est bonne, il n'y aura plus d'erreur et ça serait bien que je puisse prendre la main histoire d'arrêter proprement la machine avant d'aller au dodo.

Et donc mon interrogation c'est comment prendre la main s'il n'y a pas d'erreur. L'idée d'appuyer sur une touche, c'est pour signaler au test qu'il ne doit pas rebooter,

Citation:

Envoyé par N_BaH

mais ça ne concerne pas toutes les machines.

si tu as des scripts qui se réfèrent au nommage des disques (sda sdb ...) réécris-les en les faisant se référer aux UUID; ils sont disponibles dans l'absolu (càd même après transfert d'une machine à une autre).

D'accord.
Mais la mienne est concernée, et je ne voudrais pas qu'un jour, voulant remettre à zéro un disque de données je me retrouve à le faire sur le disque système avec pourtant dd if=/dev/zero of=/dev/sdb juste le jour où systemd a croisé sdb et sda, loi de Murphy oblige, tu vois le truc ?
Et je ne sais pas comment faire travailler dd ou parted ou tout un tas d'autres outils avec des uuid quand leur man spécifie /dev/sdx…

Donc il me faut bosser et étudier et tester jusqu'à ce qu'il n'y ait plus ce genre d'inversion.
09/03/2021, 17h00
N_BaH
Code:

$ maPartition=55E7-5D21
Code:

1 2 $ readlink -f /dev/disk/by-uuid/"$maPartition" /dev/sda1
Code:

1 2 $ findmnt -n -S UUID="$maPartition" -o source /dev/sda1
il daoit ty avoir d'autres solutions...
les disques, eux, n'ont pas d'UUID. mais, bon, si tu connais l'UUID de la première partition du disque, c'est jouable. un peu contraignant, mais jouable. ;)

sinon, il faut trouver une vraie solution (que je ne connais pas :( ), pas un bricolage à base de redémarrage.
09/03/2021, 18h44
Jipété
Citation:

Envoyé par N_BaH

[…] pas un bricolage à base de redémarrage.

Le(s) redémarrage(s) n'est (ne sont) pas un bricolage : jusqu'à présent je m'en suis servi pour "avoir le problème" car je voulais vérifier des commandes, leurs résultats, etc., étant entendu que le changement de nom ne se produit pas toujours. Et effectivement, quand le problème est présent, les résultats de df (ou d'autres outils) sont plus que curieux :

Mais comme je pense avoir trouvé un fix à ce souci (en tout cas, en machine virtuelle je ne l'ai plus constaté), maintenant il me faut des redémarrages en permanence, étant entendu que le changement de nom ne devrait pas se produire. Donc démarrage, le test teste les noms des disques, si c'est bon il redémarre la machine et ça recommence.

Si mon fix est correct, ça va faire ça longtemps, ce que j'aimerais éviter pour ne pas laisser la machine sans surveillance.
Et la question est donc : comment arrêter cette boucle infernale de reboot sur bon résultat du test ?

Un exemple du problème, sachant que sda est un petit disque système et que sdb et sdc sont deux gros disques identiques, pour les data et leur sauvegarde :
quand tout va bien :
Code:

1 2 3 4 5 6 $ cat /sys/block/sda/size 468862128 $ cat /sys/block/sdb/size 3907029168 $ cat /sys/block/sdc/size 3907029168
quand ça va mal :
Code:

1 2 3 4 5 6 $ cat /sys/block/sda/size 3907029168 $ cat /sys/block/sdb/size 468862128 $ cat /sys/block/sdc/size 3907029168
Mais encore une fois, le problème n'est pas systemd, le problème c'est de pouvoir arrêter le script, entre le boot et la fenêtre de lancement du login de X
09/03/2021, 18h53
N_BaH

rebooter, c'est déjà pas terrible, mais rebooter jusqu'à ce que l'ordre des disques soit "stabilisé"... :/

et comment dire ? si mon système reboot sans que je lui ai rien demandé, il va être rapidement benné.

et je ne vois pas où est le problème avec ton "fix"* :
si c'est pas bon, alors ça redémarre
et, si c'est bon, pourquoi ça devrait redémarrer ?

--
* un "fix" qui consiste en un redémarrage, n'est pas un "fix", c'est, au mieux, un sparadrap, si tu préfères. pour moi, c'est du bricolage.
09/03/2021, 19h32
Jipété

Ah la la…

Je recommence depuis le début : systemd gère en parallèle le mount des disques quand il y en a plusieurs, résultat, des fois sda1 est le petit disque système (ce qui est correct) et des fois sda1 est un gros disque de data (comment ça boote ensuite est un mystère pour moi).

Pour stabiliser ce fonctionnement aléatoire, foutraque et pifométrique, chacun y va de ses combines sur le web, entre les bidouilles dans fstab et la création de fichiers .mount, paramétrés avec des flags "after", "before", "requires", bref, la cuisine (imbouffable !) de systemd.

En ce qui me concerne, je pense qu'avec mes fichiers .mount je suis bon. Mais avant de crier victoire, il faut tester, tester, et encore tester.
Et comme le nom des disques est déterminé au boot (ou reboot), ben c'est ce que je dois faire, un grand nombre de fois.

Si par exemple un boot prend 15 secondes, je pourrai en faire 4 par minute, soit 240 à l'heure. Et si au bout de 4 heures aujourd'hui, de 4 heures demain et pareil après-demain et le jour qui suit, je n'ai pas eu de changement de nom, je considérerai que mon fix (mes fichiers de mount) est correct : plus qu'à le mettre en prod' dans la machine de la vraie vie.

Mais pour rebooter la machine 240 fois en une heure, autant faire tourner un script, prévu pour démarrer au boot, tester le nom des disques et s'arrêter si un changement de nom apparaît par rapport à ce qui est prévu ou faire rebooter la machine si les noms sont corrects.

Le question est : comment arrêter ce script s'il ne s'arrête pas tout seul (sur détection d'un défaut), étant entendu qu'il n'y a pas de user loggué pendant le boot ?
09/03/2021, 19h54
Christophe

La solution est l'utilisation des UUID ou des labels, comme déjà indiqué. En général ce problème survient plutôt avec les périphériques USB. Si comme tu le dis, systemd gère en parallèle le montage, c'est pas surprenant que tu es ce problème. systemd doit prendre le 1er device libre, et si il met un temps différent à faire ses traitements parallèles pour x raisons, tu te retrouve avec cette situation de devices dont l'ordre a changé.

Tu pars dans une mauvaise direction. Utiliser les UUID ou les labels est sûr et rapide, utiliser ta solution va te prendre un temps inconnu et un résultat inconnu.
10/03/2021, 11h08
Jipété

Citation:

Envoyé par chrtophe

Utiliser les UUID ou les labels est sûr et rapide,

Sauf quand ça part en vrac -- ne me demandez pas pourquoi, mais c'est comme ça, je l'ai constaté. Et je vous l'ai montré : des fois sdb1 est monté sur /, là où devrait être monté sda1, dont la connexion par fstab n'a pas bougé depuis l'installation de la machine.

Alors peut-être que les manières de les connecter ont été écrites par des singes et avec les pieds, et que google m'a remonté celles-là en premier, toujours est-il que ce que j'ai mis en place n'est pas fiable à 100 %.

À partir de cette constatation, j'en ai conclu qu'il me fallait agir autrement, et mine de rien, ça fait des mois que je suis là-dessus, pas à temps complet je vous rassure, mais les études des tutos du web et leur compilation pour synthèse vers quelque chose de compréhensible, reproductible et maintenable n'est pas une mince affaire.

---
et pour mon script, j'ai pensé qu'en fin d'exécution, si les disques sont correctement nommés (et donc reboot à venir pour re-test), je lui rajoute 15 secondes à ne rien faire, ce qui me permettra de me logguer en ssh depuis la machine à côté et hop !, kill du process du script par son id remontée par une ligne en plus dans le .bashrc et ça ira bien.
10/03/2021, 13h18
N_BaH

Citation:

des fois sdb1 est monté sur /, là où devrait être monté sda1, dont la connexion par fstab n'a pas bougé depuis l'installation de la machine.

montre-le nous ton /etc/fstab.
10/03/2021, 13h44
disedorgue

Et avec aussi le résultat de la commande:

Code:

systemctl status *mount | sed -n '/\/etc\/fstab/,/Where:/p'

Citation:

Envoyé par N_BaH

montre-le nous ton /etc/fstab.

Le voici, mais il est plein de commentaires car je ne l'utilise plus pour les gros disques -- ceci étant dit, j'ai conservé les lignes, comme ça on peut voir ce que j'ai tenté :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
cat /etc/fstab
# info moi : "discard" pour trimmer les ssd -- présent d'origine, et probablement 
# pas une bonne idée, voir https://www.spinics.net/lists/raid/msg40924.html, donc zappé
 
### ssd
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
#UUID=99dc8d6c-8674-4c7d-b27f-7cd860bdd63f /              ext4    defaults,noatime,discard 0 1
UUID=99dc8d6c-8674-4c7d-b27f-7cd860bdd63f /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
 
 
#### premier dd, sdb -- les datas
##/dev/sdb1 : 1,6 To
##/dev/sdb1	/data_large	ext4	relatime,rw,auto,users,exec	0	2
## 11-10/2020, suite conseils Alain suite micmac sda1<>sdb1, passage aux uuid.
## 11/11/2020 : mais ça ne change rien... Création d'un nouveau noyau avec 6 modifications, à suivre...
#UUID=83452e91-8384-45c3-b2c7-4315904d03fa	/data_large	ext4	relatime,rw,auto,users,exec	0	2
 
#### second  dd, sdc -- les sauvegardes des datas
##/dev/sdc1 : 1,6 To
##/dev/sdc1	/dbck_large	ext4	relatime,rw,auto,users,exec	0	2
#UUID=0e65ae8e-d816-4ffc-a210-e616717de2fe	/dbck_large	ext4	relatime,rw,auto,users,exec	0	2
 
## lsblk -f
## |--sdb1 ext4   data        83452e91-8384-45c3-b2c7-4315904d03fa    1,5T     1% /data_large
##
## |--sdc1 ext4   backup      0e65ae8e-d816-4ffc-a210-e616717de2fe    1,5T     0% /dbck_large
 
# (désolé, le forum accepte les codes des caractères semi-graphiques dans la fenêtre de saisie mais pas à l'affichage)
 
# 25/12/2020 :
### premier dd, sdb -- les datas ##########################################################
##/dev/sdb1 : 1,6 To
#####/dev/sdb1	/data_large	ext4	relatime,rw,x-systemd.requires-mounts-for=/,auto,users,exec	0	2
 
### second  dd, sdc -- les sauvegardes des datas ############################################
##/dev/sdc1 : 1,6 To
#/dev/sdc1	/dbck_large	ext4	relatime,rw,x-systemd.requires-mounts-for=/data_large,auto,users,exec	0	2
#####/dev/sdc1	/dbck_large	ext4	relatime,rw,x-systemd.requires-mounts-for=/,auto,users,exec	0	2
 
# /                                     /dev/sda1        ext4       rw,noatime
# |-/data_large                         /dev/sdb1        ext4       rw,nosuid,nodev,relatime
# |-/dbck_large                         /dev/sdc1        ext4       rw,nosuid,nodev,relatime
#
# mais pâté le 27/12 ! c'est sdc1 qui est monté sur "/" ! 
# et le 28 au soir c'est sdb1 qui est monté sur / 
# en fait c'est le ssd qui est nommé sdb1 (vu grâce à df) et systemd n'en a rien à foutre de l'uuid...
# et l'option x-systemd.requires-mount-for est inefficace, on dirait bien.
#
# 26/02/2021 : toujours aussi merdique -- ce matin encore, sdb1 est monté sur /

Ce qui est intéressant, c'est cette dernière ligne car en février j'avais basculé en mode service_qui_lance_un_script_de_montage
Vous voulez voir ce script ? Y a qu'à demander :

Code:

1
2
3
4
5
6
7
8
9
#!/bin/bash
 
### premier dd, sdb -- les data
##/dev/sdb1 : 1,6 To
mount -t ext4 -o rw,nosuid,nodev,relatime LABEL=data /data_large
 
### second  dd, sdc -- les sauvegardes des data
##/dev/sdc1 : 1,6 To
mount -t ext4 -o rw,nosuid,nodev,relatime LABEL=backup /dbck_large

Citation:

Envoyé par disedorgue

Et avec aussi le résultat de la commande:

Code:

systemctl status *mount | sed -n '/\/etc\/fstab/,/Where:/p'

Code:

1
2
3
4
5
6
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 3h 51min ago
    Where: /
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 3h 51min ago
    Where: /tmp

Et dans la foulée, je propose ça :

Code:

1
2
3
4
5
6
7
8
9
$ systemctl status *mount | sed -n '/\/etc\/fstab/,/What:/p'
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 4h 0min ago
    Where: /
     What: /dev/sda1
   Loaded: loaded (/etc/fstab; generated)
   Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 4h 0min ago
    Where: /tmp
     What: tmpfs

Maintenant, plus qu'à attendre que lors d'un reboot ça soit sdb1 qui soit monté sur "/", et je relancerai ces deux commandes…

10/03/2021, 17h02
N_BaH

Citation:

# (désolé, le forum accepte les codes des caractères semi-graphiques dans la fenêtre de saisie mais pas à l'affichage)

Code:

$ lsblk --fs --ascii

mais ça fait longtemps que ça fait ça, ou c'est depuis que tu as tripoté ton noyau ? ou tu as tripoté le noyau à cause de ça ?
10/03/2021, 18h52
Jipété

Citation:

Envoyé par N_BaH

mais ça fait longtemps que ça fait ça, ou c'est depuis que tu as tripoté ton noyau ? ou tu as tripoté le noyau à cause de ça ?

Quoi ? Le problème de mauvais rendu du graphisme de la sortie de lsblk ? Perso je m'en contre-fiche, je l'avais inclus en commentaire dans mon fstab comme un rappel.

Ou bien tu parles du changement de nom des disques ? Ça, ça le fait depuis l'install d'une Debian Buster backportée en 5.7 à cause de non-support du gpu du proc AMD 3200 dans la distro officielle, soit fin septembre / début octobre, je ne sais plus trop.

Ah ben tiens, voilà, après une après-midi jardinage, j'allume la babasse et paf !, c'est sdb1 qui est monté sur / alors hop !, les commandes de disedorgue :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 $ systemctl status *mount | sed -n '/\/etc\/fstab/,/Where:/p' Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Wed 2021-03-10 18:55:43 CET; 3min 21s ago Where: / Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Wed 2021-03-10 18:55:43 CET; 3min 21s ago Where: /tmp $ systemctl status *mount | sed -n '/\/etc\/fstab/,/What:/p' Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Wed 2021-03-10 18:55:43 CET; 3min 36s ago Where: / What: /dev/sdb1 Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Wed 2021-03-10 18:55:43 CET; 3min 36s ago Where: /tmp What: tmpfs
et je résume ça comme ça, sans le tmpfs :
Code:

1 2 3 dans un cas | dans l''autre Where: / | / What: /dev/sda1 | /dev/sdb1
et moi, je ne trouve pas ça normal, la preuve avec un script écrit il y a des années et des années, et jamais pris en défaut, machines physiques comme virtuelles, et dont voilà le résultat :
Code:

1 2 3 4 5 espace occupé "=", espace libre "|" sdb1 : 191 Gb [=|||||] sda2 : 191 Gb [||||||] lol ! sda2 c''est la partoche de swap, normalement sda1 : 1640 Gb [========|||||||||||||||||||||||||||||||||||||||||||||||||] sdc1 : 1640 Gb [======|||||||||||||||||||||||||||||||||||||||||||||||||||]
Note curieuse : les première et deuxième lignes indiquent une taille identique de 191 Gb, c'est normal.

Quand tout va bien, le script donne :
Code:

1 2 3 sda1 : 191 Gb [=|||||] sdb1 : 1640 Gb [========|||||||||||||||||||||||||||||||||||||||||||||||||] sdc1 : 1640 Gb [======|||||||||||||||||||||||||||||||||||||||||||||||||||]
Le cœur du script c'est l'analyse de df | grep "/dev/sd" par awk.

Et ce qui est bizarre, c'est que dans ce contexte que je considère comme foireux, ls -Al / me remonte les bonnes données de la racine, tout comme ls -Al /data_large et ls -Al /dbck_large.

À n'y rien comprendre.

10/03/2021, 20h08
N_BaH

Citation:

mauvais rendu du graphisme de la sortie de lsblk

non. ce n'est pas ça. c'est toi qui ne sais pas choisir la bonne option.

1 pièce(s) jointe(s)

Citation:

Envoyé par N_BaH

non. ce n'est pas ça. c'est toi qui ne sais pas choisir la bonne option.

Quoi ???????????????????,

Mais je ne savais même pas qu'elle existait, cette option !

Et d'ailleurs (venant d'une autre machine), voilà un test simple :
Code:

1 2 3 4 5 6 7 8 9 10 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 9,3G 0 part [SWAP] ├─sda2 8:2 0 83,8G 0 part / ├─sda3 8:3 0 9,3G 0 part /var └─sda4 8:4 0 829,1G 0 part /datas sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 821,2G 0 part /media/sdb1 └─sdb2 8:18 0 110,4G 0 part /media/sdb2
Pourquoi est-ce que j'aurais besoin d'une option quand dans l'éditeur c'est correct ? C'est l'affichage du forum qui a un souci, c'est tout :
Pièce jointe 593111

Voir 40 message(s) de cette discussion en une page