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

Ce matin, l'esprit clair, je boote la machine capricieuse et sda1 est bien monté sur "/", alors je reboote et c'est pareil, alors je reboote encore et c'est toujours pareil, alors je reboote encore un coup et bingo !, sdb1 remplace sda1 sur "/", et la commande de disedorgue adaptée par mes soins (remplacement de Where par What, et j'enlève tmpfs qui ne sert à rien ici) montre tout ça :

Code:

---

1 2 3 4 5

systemctl status *mount | sed -n '/\/etc\/fstab/,/What:/p' Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Thu 2021-03-11 09:56:41 CET; 1min 8s ago Where: / What: /dev/sdb1

---

Hier quand ça m'a été demandé, j'ai eu

Code:

---

1 2 3 4

Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Wed 2021-03-10 10:53:01 CET; 4h 0min ago Where: / What: /dev/sda1

---

Je synthétise en résumant :

Code:

---

1 2 3

normal | pas normal Where: / | Where: / What: /dev/sda1 | What: /dev/sdb1

---

Alors si quelqu'un veut s'amuser dans ce contexte à remettre sdb à zéro avec dd if=/dev/zero of=/dev/sdb, je lui souhaite bon courage au reboot...

Code:

---

1 2 3 4 5

lsblk --ascii NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 223,6G 0 disk |-sdb1 8:17 0 195,3G 0 part / `-sdb2 8:18 0 28,3G 0 part

---

Note : en examinant les tailles du disque et des partoches, je confirme qu'il s'agit bien du disque système, celui qu'on a vu dans le fstab, monté avec l'uuid, :marteau:

J'ai vaguement suivi le problème, mais j'aimerai faire une hypothèse : et si les deux disques contiennent tous les deux, deux systèmes parfaitement opérationnels. Par contre, c'est au niveau du BIOS/GRUB (dans mon hypothèse, il y a un GRUB sur chaque disque), il prends le premier qu'il "trouve" et ce n'est pas un truc stable (dans le sens, cela dépend peut être du temps de démarrage pris par le disque).

Bonsoir,

Citation:

---

Envoyé par LittleWhite

et si les deux disques contiennent tous les deux, deux systèmes parfaitement opérationnels.

---

Ben non, lors de l'install de la machine, je n'ai partitionné et formaté que le ssd sda, les deux autres (disques durs mécaniques de 2 To) je les ai laissés de côté, le temps de faire l'install de Debian.

Et c'est une fois ce disque opérationnel que je me suis préoccupé des deux gros disques, qui sont réservés aux données et à leur sauvegarde.

Mais merci d'avoir participé, ça me donne l'occasion de faire le point de là où j'en suis : je continue mon idée de script lancé à la fin du démarrage de la machine pour tester qui est monté sur / et agir en conséquence. Et c'est bientôt fini, d'autres infos dans pas longtemps (mais je ne suis pas là-dessus 24/24, heureusement).
:coucou:

Citation:

---

sont réservés aux données et à leur sauvegarde.

---

Du coup ta sauvegarde est bootable ?

Au niveau du BIOS, tu devrais pouvoir fixer l'ordre de boot des disques. Mais il est aussi possible qu'un grub installé sur le disque 1, qui boote en premier, ai une entrée sur un disque2. Ca peut être le cas si tu as fait une modif grub après ajout d'un second disque. Grub travaille aussi avec les UUID.

Citation:

---

Envoyé par chrtophe

Du coup ta sauvegarde est bootable ?

---

Euh, non, pas que je sache. Pourquoi cette question ?
Rappel : j'ai 3 disques, un petit ssd bootable qui contient l'OS, un gros mécanique qui contient les données et un autre identique qui contient les sauvegardes du précédent.

Citation:

---

Envoyé par chrtophe

Au niveau du BIOS, tu devrais pouvoir fixer l'ordre de boot des disques.

---

C'est fait depuis le début.

Citation:

---

Envoyé par chrtophe

Mais il est aussi possible qu'un grub installé sur le disque 1, qui boote en premier, ait une entrée sur un disque2. Ca peut être le cas si tu as fait une modif grub après ajout d'un second disque.

---

Et comment le vérifier, et comment l'annuler, si jamais il y avait un 'blème de ce côté ?
Ceci étant dit, ça ne change rien au fait que la plupart du temps j'ai sda1 monté sur / mais que parfois j'ai sdb1.

Citation:

---

Envoyé par chrtophe

Grub travaille aussi avec les UUID.

---

Je peux tenter les labels, mais tu vas me dire que Grub travaille également avec les labels ? :mouarf:

Comme déjà dit, dans ton fstab, utilises les UUID ou les labels. ça devrait régler le problème.

Citation:

---

Je peux tenter les labels, mais tu vas me dire que Grub travaille également avec les labels

---

Il utilise les UUID dans l'entrée "root=" qui devrait être le même que dans ton fstab.

Yep !

Citation:

---

Envoyé par chrtophe

Comme déjà dit, dans ton fstab, utilises les UUID ou les labels. ça devrait régler le problème.

---

Comme déjà dit, déjà tenté et rien réglé.

Bon, maintenant, peut-être que je m'y suis mal pris, faut dire aussi que la doc est épouvantable et que je n'ai jamais trouvé de tuto expliquant bien et simplement cette jungle de systemd qu'on nous impose sans nous demander notre avis, :roll: :furax:

Bonjour,

des nouvelles (bonnes pour l'instant) de l'avancement du projet : il est en prod', :ccool:

Depuis hier, j'ai mis en place dans la machine virtuelle prévue pour ça un service systemd qui est activé vers la fin du boot (pas moyen d'être plus précis, merci systemd, :furax:) et lance un script qui vérifie que sda1 est bien monté sur / :

• si oui, le script appelle reboot après quelques secondes ;
• si non, le script s'arrête (et donc la machine ne reboote pas et donc je peux prendre la main pour voir ce qui se passe).

Et pendant les quelques secondes de délai quand c'est ok, j'ai le temps de me logguer en ssh depuis une autre machine et là, .bashrc lance un second script qui me permet d'arrêter le script principal si c'est le moment (dodo, promenade, etc.) d'arrêter la machine.

Quand ce bazar aura tourné pendant plusieurs jours sans aucun arrêt sur erreur de mount, j'en conclurai que ma manière de monter les disques est correcte (j'utilise fstab pour sda1 et des fichiers .mount pour les deux autres) et il sera temps de transférer tout ça dans la machine physique (puisque c'est sur elle que les mounts ont toujours cafouillé) + retests.

Présentement, j'en suis à 400 reboots entre hier et ce matin (pas h24) et 0 erreur, c'est bon signe.

À pluche,
:coucou:

Bonjour,

Citation:

---

Envoyé par Jipété

des nouvelles (bonnes pour l'instant) de l'avancement du projet : il est en prod', :ccool:
…
Présentement, j'en suis à 400 reboots entre hier et ce matin (pas h24) et 0 erreur, c'est bon signe.

---

Vous voulez des nouvelles, au bout de 5 jours ? Hé bien c'est une catastrophe...

Tout avait commencé mardi par la mise en place des scripts de contrôle et des fichiers .mount, et tout avait bien tourné, puis j'ai arrêté, c'était l'heure de la promenade.
Le mercredi, je lance vers 11 h la machine virtuelle sans toucher à rien et tout fonctionne bien, à tel point que je vous poste ce que vous avez pu lire dans le post précédent, puis je passe à table, tranquille.

Sauf qu'au café vers 14 h je constate que la mv est plantée de chez planté ! Complètement figée. L'incident s'est produit vers 13 h 35, au bout de 300 itérations, et il n'y a aucun log pour m'indiquer ce qui a pu se passer, tout ce que j'ai c'est l'écran de la console qui m'indique "Freeing unused kernel memory: 1600 K" mais ça, c'est un message présent dans les logs quand tout se passe bien, alors ça ne va pas faire avancer l'affaire.

J'étudie les logs, les compare, y passe un temps dément sans rien trouver, alors je modifie un peu les fichiers .mount et le script de contrôle, je relance le bazar on est vendredi et là, ça plante tout pareil mais au bout d'une cinquantaine d'itérations seulement.

Bon, je me dis que c'est mes fichiers ou la machine qui sont moisis, alors je décide de changer de machine virtuelle et là, ce n'est pas la machine qui plante, c'est le test qui détecte que sda1 n'est pas monté sur / et donc s'arrête, comportement normal.
Le .mount de sdb1 (sdc1 c'est quasiment la même chose sauf le RequiresMountFor=/data, l'uuid et le Where=/dbck) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

$ cat data.mount [Unit] Description=mount disk2 part1 (sdb1) RequiresMountsFor=/   [Mount] What=/dev/disk/by-uuid/85c917d7-a099-470f-9f4b-83ebd4f5f43b Where=/data Type=ext4 Options=defaults,rw,noatime   [Install] WantedBy=graphical.target # dessous merdique, alors test dessus mais pas mieux #WantedBy=multi-user.target

---

Je passe le week-end à étudier des fichiers .mount, des .service, et tout me semblant correct, je repars avec ce site où tout a l'air bien clair et bien expliqué sur une configuration toute simple de fstab, elle est là :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

# <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=68af45f1-c305-4ebe-9007-bd583e78edac / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=dc5da9c8-be3e-4392-82c1-d622563afbfb none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 # #2 ajouts le 29/03/2021 # sdb1 UUID=85c917d7-a099-470f-9f4b-83ebd4f5f43b /data ext4 defaults,x-systemd.requires-mounts-for=/ 0 0 # # sdc1 UUID=7fd84165-6367-4e21-bcb4-a8e90c52eb77 /dbck ext4 defaults,x-systemd.requires-mounts-for=/data 0 0

---

Et à la 64^e itération, "Partition sda1 pas montée sur /, arrêt du script." :aie:

J'en suis là et ne sais absolument plus quoi faire. :weird:
Juste vous raconter la blagounette suivante : dans le script j'utilise une variable TIMEOUT=20 qui me sert pour laisser le temps à une console de se logguer en ssh pour arrêter le script, en cas de besoin. Et si je tombe à 15, alors c'est quasi immédiat, "Partition sda1 pas montée sur /, arrêt du script."

En résumé l'utilisation de fstab est une catastrophe, et la mise en place de fichiers .mount c'est pas mieux. Qu'est-ce qu'il me reste ?

In fine j'ai ça

Code:

---

1 2 3

/dev/sdc1 on / /dev/sda1 on /data /dev/sdb1 on /dbck

---

au lieu de ça

Code:

---

1 2 3

/dev/sda1 on / /dev/sdb1 on /data /dev/sdc1 on /dbck

---

Bien sûr les données renvoyées par df sont à la rue…

Merci pour les pistes et les idées qui me sortiront de ce pétrin.

Bonsoir,

Bonne, très bonne nouvelle : j'ai réussi à avoir un fichier fstab (pour sda1, monté sur /) et deux fichiers .mount (pour sdb1, monté sur /data, et sdc1, monté sur /dbck) sans plus de problèmes, la preuve c'est que depuis hier mes tests de reboot si sda1 est bien monté sur / en sont à 867 itérations et 0 (zéro, oui oui !) erreur si je fais abstraction des deux boulettes qui m'ont mis des bâtons dans les roues :

1^re boulette, le contrôleur de disque où était connecté sda était un "contrôleur IDE" quand les deux disques complémentaires étaient branchés sur un "contrôleur SATA". Le fait de mettre tout ce petit monde sur SATA a réglé le souci des montages aléatoires, hé ouais :ccool:

2^e boulette, mais je n'en ai pas parlé car ça date d'hier, ça a été réglé aujourd'hui et ça dépend de VirtualBox, qui permet des choses engendrant des catastrophes : voulant gagner du temps et de l'espace disque, j'ai eu la mauvaise idée de partager les 2 gros disques de test entre plusieurs machines mais si ça fonctionne le temps de la configuration, ça ne survit absolument pas à un simple arrêt de l'interface de VB, qui se relance en déclarant "inaccessible" la machine qui tente d'accéder aux disques d'une autre machine.
VB pourrait le dire avant de nous laisser faire ce genre de bêtise, enfin, de bêtise : il me semble que ça fonctionne dans les vieilles versions de VB, et tant qu'il s'agit de disques de données et qu'une seule machine est allumée à la fois, pourquoi n'est-ce pas possible ? Bah…

Il y a un point qu'il faudra que je creuse : ça fonctionne donc parfaitement bien avec une Debian/Xfce, alors que j'ai eu de gros soucis avec une Debian/Lxde pourtant correcte au niveau du contrôleur de disques. Je vais un peu fouiner ces jours-ci, ça a peut-être un rapport avec les fichiers .mount, et comme j'en tiens deux bons, hé hé hé !

Bon, je parle, je parle, et les itérations en sont maintenant à 915 -- je crois que je tiens le bon bout.
Parce que le temps de poster et d'éditer ce post, le compteur est à 935.
:coucou:

Cool, si on suppose un reboot par jour, tu as environ dans les 3 ans avant de rencontrer le problème si tu dois le rencontrer :mrgreen:

Citation:

---

Envoyé par disedorgue

Cool, si on suppose un reboot par jour, tu as environ dans les 3 ans avant de rencontrer le problème si tu dois le rencontrer :mrgreen:

---

:ptdr: :ptdr: :ptdr:

Et ce matin, démarrage sans aucun souci et le compteur de reboot de la machine virtuelle pour tests en est à 1147 ! Encore deux ou trois jours comme ça pendant lesquels la machine vit sa vie et moi la mienne dans le host et je pourrai considérer que c'est gagné !

Me restera plus qu'à mettre ça (pas le test, hein, juste les fichiers .mount) en prod dans la machine physique.

Yep !

Citation:

---

Envoyé par Jipété

Il y a un point qu'il faudra que je creuse : ça fonctionne donc parfaitement bien avec une Debian/Xfce, alors que j'ai eu de gros soucis avec une Debian/Lxde pourtant correcte au niveau du contrôleur de disques. Je vais un peu fouiner ces jours-ci, ça a peut-être un rapport avec les fichiers .mount, et comme j'en tiens deux bons, hé hé hé !

---

Ce que je me suis empressé de faire, en espérant vous annoncer une bonne nouvelle mais hélas, le sort s'acharne sur LXDE : j'avais réussi à réparer la machine en utilisant les .mount de la XFCE et, ma foi, les deux tournaient ensemble tip-top dans le host depuis 14 h environ, jusqu'à ce que cette Lx me refasse le coup de son caca nerveux :

Pièce jointe 594742

et là, il n'y a rien d'autre à faire à part power off. EDIT : petit oubli, on est là au 72^e reboot. /EDIT

Vu qu'on est au tout début du boot, il n'y a rien dans les logs, donc à part faire tourner les tables pour en savoir plus, je n'ai pas d'autre idée... À moins que quelqu'un ici en ait une ?
Je précise que la machine doit être bien à jour puisqu'au premier démarrage de ce matin, le système des unattended upgrades a pris le contrôle et ce pendant bien une heure-une heure et demie.

Ce qui n'a pas empêché ce misérable plantage, :cry:

Et pendant ce temps la Xfce continue sa vie, à l'instant 1848 reboots depuis hier.

Je laisse l'autre un peu allumée en l'état, des fois qu'une réponse lumineuse survienne…

En retournant tout internet, je suis tombé sur une discussion chez VirtualBox d'où il ressortirait que ce problème pourrait être lié à une non-installation des Guest Additions. Bizarre mais pourquoi pas ? Je ne me souviens plus si je l'ai fait ou pas, en tout état de cause, passer par le menu Machine / Informations de session prouve qu'elles n'y sont pas,

Pièce jointe 594756

alors en avant pour une install, qui est curieuse quand même (première et troisième lignes du blanc) :

Pièce jointe 594757

Peut-être qu'elles étaient mal installées ? Ça peut exister, ça, quand on n'a aucun contrôle dessus ?
Bref, tout ça pour dire que ça re-tourne comme cet aprème et que la 1^re image ne me dit plus qu'elles ne sont pas là mais maintenant c'est l'heure de l'apéro et d'arrêter tout ce fourbi, alors à suivre demain…
:coucou:

Bonjour,

Depuis ce matin les deux mv's tournaient comme des horloges suisses, et puis en début d'après-midi, la capricieuse Lxde a décidé de me refaire le coup du plantage au reboot, toujours sur le même "Freeing unused kernel image memory: 1600K".

Mais hélas, ça n'a strictement rien à voir avec les guest additions dont j'ai causé hier : quand la machine est plantée, à ce stade les GA n'ont pas encore été lancées, donc ne sont pas détectées par l'ihm de contrôle de la machine : j'ai pu le constater sur l'autre machine, toujours vaillante et où on peut lire que les GA ne sont pas installées et puis d'un coup ça affiche des graphiques et comme ça en boucle selon le stade de la machine. Comme quoi, hein, on ne peut se fier à rien.

Alors j'ai décidé de comparer ligne utile à ligne utile les informations des fichiers .vbox concernés, et j'ai relevé 2 petites différences :

Code:

---

1 2 3

| mv ok | mv kc syst. accél. interf. 2 paravirt.| none | KVM affichage / accélération 3d | activée | non activée

---

J'ai reporté ces deux réglages dans la config de la machine kc, reboot, et c'est reparti pour 5 heures de test…

Bonsoir,

aujourd'hui fut une belle et bonne journée : démarrage des 2 mv's à 10 h, arrêt à 16 h sans aucun cahot entretemps soit 6 h non-stop de reboots, ce qui signifie que ma façon de monter les disques est correcte, et ça fait plaisir.
Bientôt en prod', tout ça. :ccool:

Des détails ?
Chaque machine à la fin du démarrage lance un service qui se contente de lancer un script, et celui-ci commence par patienter 5 secondes, ayant remarqué que systemd parfois donne la main alors que le démarrage n'est pas terminé, :furax: !
Ensuite le script vérifie que le montage des disques (rappel : 1 petit disque système et 2 gros pour les data et backups) est correct, histoire de ne pas avoir d'embrouilles avec d'autres scripts qui s'appuient sur df par exemple.

• Si le montage est correct, le script loggue tout ça et attend 20 secondes pour laisser le temps de se logguer en ssh depuis ailleurs pour pouvoir l'arrêter en cas de besoin (et je réalise maintenant que tout est fini et que ça fonctionne comme une horloge suisse, que j'aurais pu faire autrement, par exemple poser un témoin nominatif dans un dossier partagé où le script vérifiera sa présence = arrêt ou son absence = reboot), puis reboot, et le cycle recommence.
• Si le montage est incorrect, log des infos puis arrêt du script.

Des remarques, des commentaires ?

:resolu: dans 2 ou 3 jours, histoire d'être sûr.

Citation:

---

Envoyé par Jipété

Des remarques, des commentaires ?

:resolu: dans 2 ou 3 jours, histoire d'être sûr.

---

Bonjour,

pas de remarques ni de commentaires, alors, après la journée d'hier et 7 h de travail sans incident sur les deux mv's, soit 420 reboots chacune, ce petit post juste pour confirmer mon :resolu: