Discussion :

[Jipété]

Bonjour,

Par contre, je ferais attention si il y a un sda2, normalement dd devrait s'arrêter à la fin de sda1, mais prudence.

et si pas hasard par malheur il y a plusieurs disques dans la machine, par exemple 2, je ferais triplement attention au fait que si la machine est pilotée par systemd, des fois le premier disque va s'appeler sdb et le second disque sda ! J'ai eu le cas, alors méfiance...

Il faut le savoir.

[A3gisS3c]

Hello,

J'ai l'impression que Systemd est aussi diabolisé que le front national.

Restons sérieux 30 secondes Systemd n'a rien à voir avec des problèmes de dd ou autres.

[Jipété]

Restons sérieux 30 secondes Systemd n'a rien à voir avec des problèmes de dd ou autres.

C'est vrai, mais encore une fois, les soucis peuvent se manifester avec dd comme avec gparted ou comme avec les retours d'info de fdisk ou autre, mais le plus criant est bien avec dd, quand on veut faire dd if=/dev/sda of=/dev/sdb et qu'on ne s'est pas rendu compte que sda est vide et sdb plein, ce jour-là...

https://askubuntu.com/questions/7952...from-systemctl
This excellent question (and its answers) is an interesting example of how systemd violates the long-standing (and brilliant) design principles of Unix & Co... (most experienced users will just consider that complete bloat). I begin to see more clearly why Linus Torvalds is so vehemently critical of systemd.

https://superuser.com/questions/1538...-until-success (avril 2020)
Unfortunately, network-online.target is inconsistently implemented and otherwise unreliable. It's best not to rely on it.

Lecture pour se détendre : https://suckless.org/sucks/systemd/
systemd is the best example of Suck.
There is a menace which is spreading like a disease throughout the Linux world, it is called systemd.
et tout en bas, Practical systemd

J'ai l'impression que Systemd est aussi diabolisé que le front national.

C'est pire parce que le FN est stable, lui.

[A3gisS3c]

Tous nos serveurs (plusieurs centaines) de productions tournent sur Systemd et aucun problème. (Juste un bug léger de logind sous Debian 9, connu).

Sysv-init? Complètement dépassé c'est un init préhistorique et impropre a des serveurs de production (il ny a qu'à check les scripts bidons que l'on peut retrouver dans init.d).

On peut parler autant que l'on veut sur Systemd, c'est un gestionnaire de processus professionnel.

Systemd est stable et oui je suis contre le fait que Systemd s'occupe de toutes les tâches d'un serveur... mais il faut le reconnaître init est complètement dépassé.

Si toutes les distributions (dont Debian ) l'ont adoptés (même au prix de l'abandon d'Upstart) il faut se demander pourquoi et savoir se remettre en question.

[Jipété]

On peut parler autant que l'on veut sur Systemd, c'est un gestionnaire de processus professionnel.

Il n'y a pas que moi qui parle, mais surtout, je me contente de faire des recherches, exemple :

[papajoker]

mais surtout, je me contente de faire des recherches

Ne fait pas l'enfant , je peux facilement me convaincre que le terre est plate avec des recherches web
# débat dépassé depuis très longtemps ! comme systemd d'ailleurs

Il y a 10ans, ok c'était les débuts et oui il y avait des choses à paufiner. Normal pour toutes nouvelles appplications.
Il y a surtout eu une énorme compagne trollesque faite par les administrateurs flemmards
- qui ne voulaient pas reconfigurer leurs machines
- et/ou apprendre une nouvelle techno
- qui pensaient (à tort) perdre en compétences (anciennes)
# oui, on trouve sur le web, encore des personnes avec des problèmes, mais le véritable problème en général vient de l'utilisateur et pas de l'application

Moi, qui suis avec archlinux, je l'utilise depuis 10 ans et ce n'est que du bonheur et totale confiance...
Ok, comme linux ou ton bureau, systemd n'est pas parfait. Mais, donnes-tu un gros crédit aux trolls anti-linux ? Pourquoi donnes-tu un crédit imperfectible aux trolls anti systemd

Pourquoi, selon toi, les principales distributions sont passées à systemd ? c'est pour le plaisir de transformer leur linux en une chose instable voir dangereure ? Un peu de sérieux, les responsable des distributions sont des personnes plus compétentes que toi ou moi.
Si tu n'en veux pas, ok c'est ton droit. Rien ne t'oblige à utiliser gnome, si tu es alergique, tu utilises un autre bureau ! Avec linux, tu peux faire la même chose, a toi de choisir une distribution sans systèmed si cela te permet de travailler plus sereinement. Et pas besoin de le critiquer (sans connaitre: forcément ton cas vu tes commentaires), je ne me permetrrais jamais de critiquer un utilisateur qui utilise une autre distribution que la mienne et que je ne connais pas

[Christophe]

Je préférais init, qui permettait de plus facilement suivre le processus de chargement. Et je trouve que Systemd ne respecte pas le principe KISS. Mais ça n'engage que moi. Je suis ouvert au débat tant qu'il est constructif.

Systemd a un avantage pour gérer la dépendance de processus lors du démarrage, et la parallélisation. Créer un Unit est pas si compliqué que ça.

A noter que udev fait partie de systemd depuis un moment.

De toute façon, toutes les distros (enfin quasiment) sont passé dessus, donc il faut s'y mettre ou se limiter à des distros de type Devuan qui seront peu rependues et difficile à utiliser/mettre à jour de par la difficulté à faire fonctionner des applis s'appuyant sur systemd.

Il faut aussi prendre en compte que la plupart des personnes se plaignant de Systemd n'ont pas lues la doc (moi le premier), après elle est dense.

Par rapport au prob. d'origine, pour éviter les problèmes, il ne faut pas utiliser des devices type /dev/sda mais plutôt des UUID. (voire des /dev/disk/by-label éventuellement).

Et le problème ne vient pas de systemd je pense.

[Jipété]

Et je trouve que Systemd ne respecte pas le principe KISS.

On est bien d'accord.
Sans compter la longueur des lignes de messages d'erreur, des fois -- Au quotidien c'est du foutage de gueule, sauf pour ceux qui ont un écran ultra-vraiment-très-large.
Et sans compter la longueur des lignes de commande, genre systemctl list-unit-files --jesaisplusquoi --autreflag --jailamemoryquiflanche --ingerable.

Sans compter que le produit n'est pas fini ! Combien de fois on a pu lire (exemple au hasard du web)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
..... systemd[1]: myservice.service: Main process exited, code=exited, status=1/FAILURE
..... systemd[1]: myservice.service: Failed with result 'exit-code'.

Entre code=exited et result 'exit-code' on est bien renseignés !
Bon, on l'a tous fait, on écrit dans le code le nom de la variable en attendant le bout de code qui mettra là la bonne donnée mais avec systemd on attend encore...

De toute façon, toutes les distros (enfin quasiment) sont passées dessus, donc il faut s'y mettre ou se limiter à des distros de type Devuan qui seront peu répandues et difficile à utiliser/mettre à jour de par la difficulté à faire fonctionner des applis s'appuyant sur systemd.

Et c'est bien pour ça que j'en suis là, tout en pataugeant dans la gadoue.
Enfin, un peu moins depuis mon noyau tip-top, mais ça m'a pris un temps dément (machine neuve achetée en juin 2020, en prod' depuis un mois).

n'ont pas lu la doc (moi le premier), après elle est dense.

et moi le second car elle est juste tout simplement illisible, c'est une abomination ultra dense (avec cette manie anglo-saxonne de toujours répéter "pour plus d'informations allez voir là-bas" qui coupe le fil d'une lecture) sur laquelle on s'endort.

il ne faut pas utiliser des devices type /dev/sda mais plutôt des UUID. (voire des /dev/disk/by-label éventuellement).

J'ai bien sûr suivi ce conseil, qui n'a pas été payant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
note : curieusement, le sdc et ses 2 partoches sont toujours corrects, alors je supprime leurs trois lignes, ça allègera :
TOUTVABIEN						| TOUTVAMAL
by-id :							|
ata-KINGSTON_SA400S37240G_50026B7782FAC2F1 	 sda	| ata-KINGSTON_SA400S37240G_50026B7782FAC2F1 	   sdb
ata-KINGSTON_SA400S37240G_50026B7782FAC2F1-part1 sda1	| ata-KINGSTON_SA400S37240G_50026B7782FAC2F1-part1 sdb1
ata-KINGSTON_SA400S37240G_50026B7782FAC2F1-part2 sda2	| ata-KINGSTON_SA400S37240G_50026B7782FAC2F1-part2 sdb2
ata-ST2000DM008-2FR102_WFL1V0FK 		 sdb	| ata-ST2000DM008-2FR102_WFL1V0FK 		   sda
ata-ST2000DM008-2FR102_WFL1V0FK-part1 		 sdb1	| ata-ST2000DM008-2FR102_WFL1V0FK-part1 	   sda1
ata-ST2000DM008-2FR102_WFL1V0FK-part2 		 sdb2	| ata-ST2000DM008-2FR102_WFL1V0FK-part2 	   sda2
							|
by-path :						|
pci-0000:01:00.1-ata-1 	      sda			| pci-0000:01:00.1-ata-1 	sdb
pci-0000:01:00.1-ata-1-part1  sda1			| pci-0000:01:00.1-ata-1-part1  sdb1
pci-0000:01:00.1-ata-1-part2  sda2			| pci-0000:01:00.1-ata-1-part2  sdb2
pci-0000:01:00.1-ata-2        sdb			| pci-0000:01:00.1-ata-2 	sda
pci-0000:01:00.1-ata-2-part1  sdb1			| pci-0000:01:00.1-ata-2-part1  sda1
pci-0000:01:00.1-ata-2-part2  sdb2			| pci-0000:01:00.1-ata-2-part2  sda2
							|
avec /proc/partitions :	comparez les tailles !		|
major minor  #blocks  name				|
   8        0  234431064 sda				|   8        0 1953514584 sda
   8        1  204800000 sda1				|   8        1 1748713472 sda1
   8        2   29627488 sda2				|   8        2  204800000 sda2
   8       16 1953514584 sdb				|   8       16  234431064 sdb
   8       17 1748713472 sdb1				|   8       17  204800000 sdb1
   8       18  204800000 sdb2				|   8       18   29627488 sdb2
							|
avec swaplabel :					|
LABEL: swap						| swaplabel: /dev/sda2*: pas une partition d''échange valable
UUID:  272a029e-4d4a-40e2-a3b7-51bf1ac7b0d0	        |

Et le problème ne vient pas de systemd je pense.

Toujours eu plusieurs disques à plusieurs partitions, première fois que je vois ça. Et si j'ai bien compris le film, systemd était déjà présent dans Debian Wheezy (circa 2013) mais pas fully opérationnel.

[Jipété]

Bonjour,

Tiens, rions un peu

Moi, qui suis avec archlinux, je l'utilise depuis 10 ans et ce n'est que du bonheur et totale confiance...

Tous nos serveurs (plusieurs centaines) de productions tournent sur Systemd et aucun problème. (Juste un bug léger de logind sous Debian 9, connu).
On peut parler autant que l'on veut sur Systemd, c'est un gestionnaire de processus professionnel.

avec un peu d'eau à mon moulin :

Au passage pour ceux que ça intéresse, les failles découvertes sont dans systemd, pas dans le kernel Linux.

Et sinon, j'en ai parlé ailleurs, j'avais constaté que des fois au démarrage de la machine je n'avais pas l'exécution d'un script qui me joue un son, et plus tard au lancement d'une machine virtuelle XP la musiquette du démarrage était toute pourrie, hachurée, incomplète (oui oui, fichier corrompu dans le lecteur audio ou autre embrouille), bref, j'ai fait des recherches, pour la non-exécution je n'avance pas (j'ai d'autres tests à faire), pour le son du démarrage je voulais l'enregistrer pour vous le faire écouter, donc avant de démarrer la VM je lance Audacity dans le host, qui met un certain temps à "monter", puis je lance la VM, puis l'enregistrement du son et là, magie, le son de la VM est toujours parfait !
Comme si le fait de lancer Audacity avant la VM faisait "monter" des choses dans le monde de l'audio du host.

C'est du Debian 11.2 de base et moi je trouve ça vraiment pas fini.

[papajoker]

re bonjour JiPetroll

avec un peu d'eau à mon moulin :

Et hier c'était linux, avant hier sudo, avant ssh ... donc en fait tu n'utilises pas linux ?

Difficile de voir que tu es aussi un développeur, comment peux-tu imaginer qu'un soft soit parfait ? puisque cela n'existe pas, dire que windows est nul parceque l'on vient de trouver une faille n'est qu'un troll contre ce système. Je t'avais bien écrit que systemd n'était pas parfait, mais tu désires alimenter le troll.

j'avais constaté que des fois au démarrage de la machine

bien sûr , c'est la faute du méchant systemd alors que justement tu ne l'utilises pas pour lancer ton script (surprise: il faut faire un .service comme dit par une personne dans ton sujet)

sans compter la longueur des lignes de commande, genre

Tiens, un monsieur qui découvre le terminal. Sa conclusion: une application console devrait avoir très peu d'options, ce qui faciliterai la vie de l'utilisateur ! Pas grave si cela implique que l'application devient simpliste au point de ne plus faire grand chose... et pas grave si cette commande est pour les administrateurs en particulier.

le produit n'est pas fini ! Combien de fois on a pu lire (exemple au hasard du web)

Merci pour l'exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 bash[13176]: Traceback (most recent call last):
..... bash[13176]:   File "/home/myself/script.py", line 33, in <module>
..... bash[13176]:     files_number = next(os.walk(files_path))[2]
..... bash[13176]: StopIteration

Comme souvent, des gens qui codes leurs scripts et ne sont pas capables de le déboguer, ni de gérer les erreurs (voir mon exemple à la fin). Heureusement qu'il existe systemd pour leur faire croire que la faute ne vient pas d'eux
- sans voir son code et 10 secondes de réflexion... il fait un glob("images/*.*"), normal qu'il fonctionne depuis sont terminal mais les services systemd ont (heureusement) un contexte différent (droits, pwd, env), cherchez l'erreur.
Les gens qui ne peuvent lancer une tâche cron vont systèmatiquement accuser cron à la place de leur script ?

Il faut lire une doc(fr) pour comprendre un minimum, sinon critiquer sans savoir ne fait pas avancer les chose et va même rendre la critique désuète.

bien sûr suivi ce conseil, qui n'a pas été payant :

Ce n'est pas un conseil, c'est la réalité. Le changement de nom de la partition disque existait bien avant systemd.
Sans doute plus un problème bios (le premier qui répond/est alimenté, est sda) : il n'y a pas un changement entre grub et linux/systemd donc accuser systemd , c'est

Si les noms persistants existe, c'est entre autre pour palier ce défaut
wiki

Si votre machine possède plus d'un contrôleur de disque SATA, SCSI ou IDE, l'ordre dans lequel leurs nœuds de périphérique correspondants sont ajoutés est arbitraire. Cela peut entraîner des noms de périphériques tels que et basculer à chaque démarrage, aboutissant à un système non démarrable, à une panique du noyau ou à la disparition d'un périphérique de bloc. La dénomination persistante résout ces problèmes.

https://www.debian.org/releases/stab...apcs04.fr.html

Notez que si vous avez deux adaptateurs SCSI (c.-à-d. des contrôleurs SCSI), l'ordre de nommage des disques peut-être embrouillé.

https://doc.ubuntu-fr.org/uuid_et_la..._est_mieux_non

plus sûres qu'une appellation comme /dev/sdb6 qui risque fort d'être périmée si votre bios est de ceux qui changent l'ordre des disques sans prévenir, et qui sera certainement périmée le jour où vous supprimerez sdb5. Il faut aussi savoir que dans certaines circonstances, testdisk ou l'éditeur de partitions de Windows remettent dans l'ordre les numéros de partitions (de sda1, 2, 4, 3 vers sda1, 2, 3, 4).

-------------------

Si tu désires tester un service systemd qui plante (oh joie), changer le path ligne ExecStart

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
# installer comme ~/.config/systemd/user/tester.service
[Unit]
Description=je teste systemd
 
[Service]
Type=oneshot
#ExecStart=/bin/ls /toto/tata/maman/  # plante aussi ?
ExecStart=/home/JIPETE/.config/systemd/user/tester.sh
 
[Install]
WantedBy=graphical-target

Tu peux voir un .service comme un .desktop que tu connais. Systemd ne fait que lancer "ce lanceur" (et donc ne connais que sont code retour)

Mon application enreguistrée comme ~/.config/systemd/user/tester.sh

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/bash
 
dir="/toto/tata/maman/papa/"
/bin/ls "$dir"
retour=$?
if [ $retour -ne 0 ]; then
  if [ -f /bin/systemd-cat ]; then
    echo "Oups, pas possible de lister le répertoire $dir, erreur bash: $retour" | systemd-cat -t tester -p err
    echo "On double (pour rien/juste démo) une erreur avec $dir ..."   | systemd-cat -t systemd -p warning
  fi
  exit $retour
fi
[ -f /bin/systemd-cat ] &&  echo "Service est ok" | systemd-cat -t tester -p 5    # risque pas c'est du SYSTEMD ;)

Maintenant on peut faire mumuse

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
chmod +x  ~/.config/systemd/user/tester.sh      # premiere fois
systemctl --user daemon-reload     # des que je modifie les fichiers
systemctl start tester --user       
journalctl -t tester --no-pager    # surprise, mon truc bash retourne une erreur claire !
journalctl -p0 -p7 --since="5 min ago" --no-pager    # même erreur dans les logs généraux