Ubuntu: system halted ou le poste ne s’éteint pas

L’ordinateur ne s’éteint pas

J'ai dit halte!
Depuis ubuntu 11.04 ((il me semble)), un problème récurent se produit: lors d’une demande d’arrêt, le poste reste sous tension et un message indique laconiquement:

*Will now halt
[...] System halted

C’est d’autant plus embêtant que parfois la commande entrée manuellement dans un terminal fonctionne sans provoquer ce problème, mais que dans un script ou avec certains logiciels, le système ne se coupe pas. Et si le système n’est pas coupé, impossible de démarrer les postes par wake on lan!

J’avais écrit à ce sujet en donnant une solution de contournement qui ne fonctionnais pas systématiquement non plus…

A noter que ce problème apparait lors d’une mise à jour ou d’une installation neuve, quelle que soit la distribution basée sur ubuntu (voyager, mint, Xubuntu, …)

Je suis tombé sur l’explication de Steve Langasek (vorlon) sur bugs.launchpad qui éclaire ce problème:

Ok, j’ai travaillé à ma façon sur toutes les formes de ce bug maintenant, et je dois conclure que ce comportement ne peut pas / ne devrait pas changer.

– La commande «shutdown» a trois options: « -h » (arrêt ou mise hors tension), ‘-H’ (arrêt), et «-p» (hors tension).
– La commande «halt» fait référence à -H,  par défaut.
– La commande «poweroff» fait référence à -p, par conception.
– La configuration de /etc/default/halt affecte *uniquement* le comportement lorsque ni -H ni -P n’a été spécifié.
– Il n’y a pas moyen de faire «halt» correspondre par lui-même à «poweroff», sans qu’il soit impossible de faire un véritable «arrêt».
– Ce sont toutes des options standard qui ne devraient pas être changé.

Donc, je ferme ce rapport de bug comme «wontfix». Le comportement actuel est incompatible avec le comportement arriviste précédent, mais ce comportement était bogué. Le comportement actuel est correct, et je crains que les gens vont juste devoir apprendre que «halt» ne signifie pas ce que vous avez été amené à croire que cela signifie.

Si vous voulez que le système se coupe, vous avez besoin pour fonctionner soit de « shutdown -h now», «halt -p», ou «poweroff». Toutes ces trois commandes fonctionnent. «halt -p» est la plus courte et probablement la plus compatible avec la mémoire musculaire existante.

Même si le ton est un peu hautain à mon goût ((pour les pauvres utilisateurs perturbés que nous sommes, et vraiment nombreux au vu des pages complètes de google à ce sujet)) , il est logique de comprendre que « halt » arrête le système informatique ((ce qu’il fait d’ailleurs très bien comme le prouve le message « system halted »)) et que « poweroff  » coupe l’alimentation matérielle.

Le problème est que pendant des années nous avons appris à utiliser « halt » plutôt que « shutdown -h » ou « poweroff » et qu’il nous semble que ce nouveau comportement est un bug, alors que c’est l’ancien comportement qui était anormal. Il va falloir commencer à changer certaines habitudes…

On peut contourner ce comportement en modifiant les aliases (alias halt= »halt -p ») mais c’est à faire pour tous les utilisateurs et ne fonctionne pas pour les scripts ou programmes qui ne lancent pas un shell.

De plus, sur la 10.04, vous constaterez que « halt » est un lien vers la commande « reboot »… D’autant plus surprenant que « reboot » fonctionne…

Eteindre ubuntu ET l’ordinateur

Note: la solution proposée par chmd dans les commentaires est en effet plus propre et conseillée.

Je me trouve confronté à des logiciels écrits il y a quelques années qui font appel à la commande halt et à qui je peux difficilement expliquer ((pour diverses raisons…)) que c’est une mauvais habitude, mais une solution de comportement existe en interceptant la commande halt et en la renvoyant vers poweroff

  • renommez la commande halt en autre chose

sudo mv /sbin/halt /sbin/haltorig

  • Créez un programme /sbin/halt qui fera appel à « poweroff » ou « shutdown -h now »

#!/bin/sh
/sbin/poweroff

puis sudo chmod +x /sbin/halt

On retrouve ensuite un comportement « normal » ((le comportement attendu, à savoir une coupure propre, même s’il vaudrait mieux prendre la bonne habitude immédiatement)) du système.

Depuis quelques jours que je teste cette modification, je n’ai remarqué aucun effet de bord, ni graphiquement, ni sur le fonctionnement des autres programmes. À part que c’est un bonheur de pouvoir à nouveau éteindre ses machines par cron ou ssh et de pouvoir les relancer par WOL.

J’ai pensé que vous trouveriez cet article utile ;oD

Articles en relation:

7 réflexions sur « Ubuntu: system halted ou le poste ne s’éteint pas »

  1. « Même si le ton est un peu hautain à mon goût »
    Il n’est pas hautain, il est juste méprisant et indigne.

    Par ailleurs, quel est l’intérêt essentiel de seulement arrêter le système? A part éteindre l’ordinateur ensuite, que pourrait-on faire d’autre? Contempler le « System halted » comme s’il s’agissait d’une œuvre majeure du génie informatique? L’interrogation qui en découle me semble plus que légitime.

    Espérons que ce Steve Langasek ne soit qu’une déplorable exception, sinon on est mal barrés pour faire avancer le Libre dans un monde bi-polaire divisé entre ceux qui savent et ceux qui cherchent à savoir, les premiers se contentant de rire à la gueule des seconds.

  2. C’est pas super joli de changer l’executable de place. Mais bon j’imagine que si les scripts en question appellent directement /sbin/halt via le chemin absolu, alors c’est la seule solution. En revanche, si ça n’est pas le cas, il suffit de créer le script dans un path plus prioritaire. /usr/local/bin est fait pour ce genre de chose.

    Par ailleurs, le script pourrait rediriger sur l’ancien halt si des arguments sont présents:

    #!/bin/sh
    if [ -z « $@ » ]; then
    /sbin/poweroff
    else
    /sbin/halt $@
    fi

    Voilà!

  3. Je ne trouve pas le ton spécialement hautain, il ne fait que dire la vérité. C’est juste pas agréable de s’entendre dire que ce qu’on considère comme un bug est en fait normal et que du coup c’est nous le problème.
    Personnellement je ne me sert jamais de halt, les gens l’apprennent par flemme parce que c’est la plus courte, mais c’est aussi la moins expressive. Poweroff est celle qui à ma préférence, le nom de la commande dit clairement ce qu’elle fait. Sinon shutdown, parce qu’elle est utilisée également sous Windows, c’est pratique quand les commandes ont le même nom sur les deux systèmes, plus simple à s’en souvenir.

    Au passage, stopper le système sans arrêter la machine peut tout à fait avoir du sens. Par exemple dans le cas d’un système sous hyperviseur, on cherche bien à stopper un système, pas le matériel qui héberge d’autres systèmes toujours actifs. Ou bien quand on cherche à faire du débug, on peut être amenés à faire tourner le système dans un environement particulier et du coup on cherche bien à éteindre le système et non le matériel, etc…

    Bref, ce n’est clairement pas les cas des utilisateurs lambdas, mais ce n’est pas une raison pour supprimer ces commandes en les faisant correspondre à une mauvaise utilisation de leurs part. Même si ça c’est déjà vu. Je pense notamment au ctrl+alt+backspace qui reboot xorg et qui à été désactivé par défaut parce que les utilisateurs lambdas faisaient trop souvent la manip « accidentellement » (j’ai du mal à voir comment on peut faire cette combinaison sans faire exprès…). C’est un gros manque à mes yeux, je ne compte plus le nombre de fois où on m’a demandé de corriger un problème sur un poste et que flash, un pilote graphique ou autre, fasse gauffrer xorg. Et à ce moment, bah c’était foutrement pratique de le rebooter comme une grosse brute, sauf que pas de bol, c’est pas activé sur le poste en question.

    Enfin bon, je m’égare, tout ça pour dire qu’il vaut mieux se mettre à utiliser les bonnes commandes plutot que de passer par un script pour « proxyfier » la commande qu’on voulait réellement taper. En effet, le coup du script ça peut très bien marcher chez toi, mais demain un client t’appel et te demande de rebooter ses machines à distances, tu vas faire un halt par habitude, sauf que chez lui, halt ça fera halt, pas poweroff. Et comme tu auras plus la mains sur le système faudra se déplacer. Et quand tu voudra expliquer à ton client pourquoi ça à pris 3h au lieu de 3 minutes, je suis pas sur qu’il rigolera…
    Le problème est toujours le même, on peut se dire « bah je m’en fou, je travail pas dans ce monde la, c’est juste mon poste à moi », mais bon, un jour ou l’autre on change de linux, de poste, on utilise la bécanne d’un pote, d’un client, etc… et la les mauvaises habitudes nous pourrissent la vie.

  4. ctxnop : Je suis entièrement d’accord avec toi, « halt » ne veut rien dire. Pour ma part, je suis habitué à shutdown, car il existe aussi sous windows et donc c’est plus pratique en environnements hétérogènes.

    manuberro : Je ne vais pas faire une dissertation de 3 pages sur ce que je pense de ton article, mais quand même.

    1 – Renommer un exécutable système est une des PIRES choses à faire sur un système en fonctionnement. Penses-tu aux scripts utilisant des options de « halt » (que tu ne renvoie pas à poweroff) ?

    Franchement, si tu veux éclater un système, va chez un armurier et achète un fusil et quelques cartouches, c’est plus rapide (ou va chez castorama et achète un sledgehammer, c’est moins cher et moins procédurier).

    2 – Critiquer le ton de Steve Langasek est assez facile, mais sûrement adapté à ton niveau (tu vois, la critique infondée, c’est facile). Mais il ne fait que paraphraser la manpage (tu sais, le truc en ligne de commande, j’pense pas que tu l’ai déjà utilisé vu ton article). Si tu veux taper sur quelqu’un d’autre, va voir Miquel van Smoorenburg, auteur de la manpage en question.

    3 – Si t’es pas foutu de comprendre que halt != poweroff, ben je ne peux rien faire pour toi…

    ++

  5. J’ai du mal à voir en quoi la réponse de Steve Langasek est hautaine, elle a par contre le mérite d’être explicite.
    Oui dans ce cas le problème est l’utilisateur … ce bug est clairement un PEBCAK, que certains n’apprécient pas de l’entendre est classique, mais aller jusqu’à traiter d’hautain la personne qui prend le temps de l’expliquer, c’est un peu fort de café.

    « le problème est que pendant des années nous avons appris à utiliser « halt » »
    Il y a parfois^wsouvent des erreurs d’apprentissage, et ce n’est pas parce que l’on a appris et reproduit quelque chose de faux pendant des années qu’il faut nécessairement s’amuser à continuer le jour où l’on s’en rend compte … je ne sais pas qui a enseigné et indiqué « pendant des années » que halt==poweroff, mais il se trompait.

    La bonne approche dans le cas présent est de patcher les scripts concernés … un script ça se maintient, si l’on est pas l’auteur il suffit de lui envoyer un rapport de bug en joignant le patch … un sed -i s/halt/poweroff/ doit même suffire à corriger se comportement dans les scripts bugués (oui dans le cas présent, ce n’est pas l’OS qui a un souci, mais le script qui est bugué).

    Il est probable que ces scripts aient fonctionné par le passé car l’acpi est tellement mal géré par design … le fait que ces scripts buguent est juste révélateur que le support de l’acpi s’améliore, c’est donc une bonne nouvelle.

    Enfin, si on souhaite continuer à utiliser un halt non conforme, il est préférable de ne pas patouiller dans /sbin avec ses menottes … ça évitera de casser apt et de planter la prochaine migration … autant utiliser des alias, ce sera un peu plus propre.
    Mais ça reste beaucoup moins propre que de patcher des scripts bugués.

  6. Respirez, les gars, je suis d’accord avec vous ;o)
    Ce comportement est normal et correct
    ET
    Il ne faut pas modifier les commandes du système

    Toujours est il que le problème d’extinction est répandu et que le fonctionnement des deux commandes a été identique pendant des années, ce qui entraine forcément une confusion logique dans l’esprit des gens.
    Mon article n’était là que pour indiquer que maintenant il faut utiliser poweroff ou shutdown parce que halt n’est pas destiné à ça, mais que, des fois, on n’a pas le choix, les logiciels font appel à la mauvaise commande et qu’il faut trouver une solution de contournement.
    Les binaires qui me posent problème, et dont je n’ai pas les sources, développés spécifiquement pour mes clients par des boites qui n’existent plus pour certaines ou dont les mails des devs n’existent plus, fonctionnaient bien avant la mise à jour, mais plus après. C’est déjà une chance qu’ils tournent sur linux!
    En dernière extrémité, modifier la commande permet d’éviter de retourner sur windows parce que la dernière version d’ubuntu pose problème.

    Quand au ton employé, c’est peut être seulement la 50e fois qu’il donne la réponse, et c’est peut être le man, ça ne m’empêche pas de penser que les gens qui appellent à l’aide sur le rapport de bug attendent une réponse et une solution, pas une leçon. Mais j’ai indiqué qu’il était clair dans sa réponse.

    Ce changement de comportement de la commande halt m’obligeait à aller tous les lundi rebooter un serveur chez un client sans pouvoir lui expliquer pourquoi, vu que linux s’améliore, ça ne marchait plus alors que sur le vieux système ça fonctionnait. Maintenant, ça refonctionne, même si c’est pas l’idéal, et j’ai plus de temps pour trouver à remplacer son logiciel par quelque chose de plus moderne.
    J’ai bien sûr testé toutes les autres possibilités (alias, commande plus haute dans la path, …) mais seule la dernière à fonctionné.

    Je me suis sans doute mal exprimé, je ne donnais pas d’infos pour retrouver le bug auquel on était habitué, mais juste comment arriver à faire fonctionner des programmes qui en tiraient parti.

  7. Je suis d’un naturel calme, et énervé ça ne me viendrait pas à l’idée d’écrire … je respire très bien, merci, même si je trouve l’interpellation « les gars » particulièrement désobligeante, n’étant pas dans une cour de récré, et n’ayant pas gardé de vache en compagnie de quiconque par le passé.

    Il ne faut pas confondre critique sur le fond et la forme avec énervement.

    Je ne dirai pas ce que je pense sur le fait d’utiliser des solutions logicielles non maintenues … de surcroît en milieu professionnel.

    Je trouve plus que limite d’insulter Steve Langasek en le traitant d’hautain. Et je ne vois toujours pas où dans son post il a pu le paraître, car il reste tout du long sur du factuel.
    Cette phrase : « I’m afraid people will just have to learn that ‘halt’ doesn’t mean what you were led to believe it means » est la seule où l’on trouve un minimum de subjectif … et je ne vois pas comment on peut interpréter ça comme hautain.
    Par ailleurs, un rapport de bug n’est ni un forum, ni une ML de support, ce n’est pas là pour aider ceux qui postent dans le fil du bug, c’est là pour améliorer les versions futurs du logiciel, il ne faut pas tout confondre.
    Et quelqu’un qui prend le temps de d’expliquer pourquoi ce bug n’a pas lieu d’être, j’appelle ça une réponse pertinente et efficace. Je ne vois pas ce qu’il y a d’hautain là dedans.
    Je vois comme beaucoup plus problématique les personnes qui abusent des rapports de bug en considérant ça comme des plateformes de support.

    De tout ce que j’ai lu sur le rapport de bug et sur ce blog, la seule remarque désobligeante envers les utilisateurs, c’est celle-ci: « pour les pauvres utilisateurs perturbés que nous sommes, et vraiment nombreux au vu des pages complètes de google à ce sujet » … et ce n’est pas Steve Langasek qui l’a rédigée.

    Il faut faire très attention au ton que l’on pense lire à l’écrit.

Les commentaires sont fermés.