Forum Linux.général Désactiver poweroff

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
12
avr.
2013

Salut,

J'ai un dédié qui ne dois surtout pas être mis hors tension, sous peine de nécessiter l'intervention d'un technicien pour appuyer sur le bouton power :p J'en au fait accidentellement l'expérience ce matin.

Pour l'instant j'ai modifié l'init-script d'arrêt pour faire un reboot à la place du halt, mais ça reste possible à contourner avec halt -pf.

Je sait que désactiver l'ACPI réglerais mon problème (le serveur s'arrêterait, sans se mettre hors-tension), mais si je peux éviter, y'a moyen de désactiver précisément seulement cette partie de l'ACPI ?

Y'a quoi comme autre moyen de prévenir une mise hors tension accidentelle ?

  • # Set up BIOS ?

    Posté par  (site web personnel) . Évalué à 1.

    Salut,

    Ca ne résout pas totalement ton problème mais il y a un moyen de régler l'action en cas de coupure de courant :
    - remettre dans le même état qu'avant la coupure de courant
    - laisser arrêté

    Sinon, il ne devrait y avoir que root qui peut utiliser la commande halt.

    • [^] # Re: Set up BIOS ?

      Posté par  . Évalué à 2.

      Oui y'a que root, ce qui ne m'a pas empêché de me dire à 4h du matin: bon j'ai fini, j'éteins ce container maintenant.

      Seul problème je me suis dit ça deux fois, la première fois j'ai bien éteins le container, la seconde, le container avait rendu la main dans mon terminal root :p

      Pour la première solution c'est une option du bios non ? Et j’imagine que ça ne concerne que les coupures de courant dues au réseau électrique, pas un arrêt via ACPI.

      • [^] # Re: Set up BIOS ?

        Posté par  (site web personnel) . Évalué à 1.

        Il y a moyen de faire un alias pour root sur les commandes halt et halt -pf vers la commande echo "Cette machine ne doit pas etre eteinte !".

        Oui, c'est une option du BIOS. C'est toujours bon de l'avoir configurer pour ce genre de machine qui doit rester allumer mais c'est vrai que si tu arrête la machine avec halt, elle ne devrait pas redémarrer même avec cette configuration.

        • [^] # Re: Set up BIOS ?

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 12 avril 2013 à 22:16.

          Il y a moyen de faire un alias pour root sur les commandes halt et halt -pf vers la commande echo "Cette machine ne doit pas etre eteinte !".

          Je viens de tester et ça ne fonctionne pas. La commande halt est interprétée avant l'alias…

          Il y a la solution un peu plus bourrin, c'est renommer /sbin/halt.
          Il me semble que ça reste un peu moins bourrin que de désactiver l'ACPI.

          D'un autre côté, quand on utilise l'utilisateur root on est sensé faire attention à ce que l'on fait ;)

          • [^] # Re: Set up BIOS ?

            Posté par  . Évalué à 3.

            Je viens de tester et ça ne fonctionne pas. La commande halt est interprétée avant l'alias…

            C'est étrange. Tu n'as pas mis l'alias dans ton bashrc/profile et oublié de réouvrir un shell pour qu'il soit pris en compte ? Ou n'aurais tu pas un autre alias redéfini quelque part, du style alias halt='telinit 0' ?

            Sinon, si tu as /usr/local/sbin dans le PATH de root avant /sbin, tu peux faire un bête script /usr/local/sbin/halt qui fait un echo 'Ne fait pas ça malheureux !'
            En revanche, si tu lances /sbin/halt, c'est foutu.

            • [^] # Re: Set up BIOS ?

              Posté par  . Évalué à 2.

              Je vais rajouter des "wrappers" pour shutdown, halt, reboot, init et telinit dans /usr/local/sbin mais faut que je vérifie avant que les paths complets pour ces commandes sont bien hardcodés dans les scripts d'init, s'agit de ne pas casser le fonctionnement normal du système non plus.

              • [^] # Re: Set up BIOS ?

                Posté par  . Évalué à 4.

                La roue a été inventé aux environs de 3500 av. J.-C. et il se trouve encore des gens pour la réinventer aujourd’hui.

                Pour les flemmards, comme moi, il y a molly-guard.

                • [^] # Re: Set up BIOS ?

                  Posté par  (site web personnel) . Évalué à 1.

                  Pour les flemmards, comme moi, il y a molly-guard.

                  Sympa cette solution ! Merci.

                • [^] # Re: Set up BIOS ?

                  Posté par  . Évalué à 2.

                  Intéressant, mais pas packagé pour CentOS et de toutes façons ça semble assez Debian specific, ça doit-être basé sur dpkg-divert ou autres fonctionnalités équivalente qui fait cruellement défaut à rpm :/

                  Je vais télécharger le paquet quand-même pour m'en inspirer.

                  • [^] # Re: Set up BIOS ?

                    Posté par  . Évalué à 2.

                    C’est basé sur « je balance des binaires dans /usr/sbin et faut espérer que le PATH soit bon », rien d’autre.

                    Personnellement, j’utilise des alias parce que mon PATH est structuré à ma manière.

            • [^] # Re: Set up BIOS ?

              Posté par  (site web personnel) . Évalué à 1.

              C'est étrange. Tu n'as pas mis l'alias dans ton bashrc/profile et oublié de réouvrir un shell pour qu'il soit pris en compte ?

              J'ai bien réouvert le shell mais c'était une session ouverte puis réouverte avec "su". Je n'ai pas pris le temps de vérifier avec une session ouverte autrement…

              Ou n'aurais tu pas un autre alias redéfini quelque part, du style alias halt='telinit 0' ?

              En tous cas, ce ne serait pas moi qui l'aurait mis… Et je ne penses pas que l'équipe Debian fasse quelque chose d'aussi brutal.

              Sinon, si tu as /usr/local/sbin dans le PATH de root avant /sbin, tu peux faire un bête script /usr/local/sbin/halt qui fait un echo 'Ne fait pas ça malheureux !'
              En revanche, si tu lances /sbin/halt, c'est foutu.

              Oui, ça c'est une très bonne idée ! En tout cas, moins bourrin et plus subtil que mon idée de renommer /sbin/halt ;)

  • # programmer le redémarrage

    Posté par  . Évalué à 9.

    Il est généralement possible de programmer le redémarrage automatique d'un ordinateur via la RTC.
    Cela se passe dans le fichier /sys/class/rtc/rtc0/wakealarm (voir le fichier rtc.txt de la documentation du noyau, suivant le matériel il est possible qu'il y en ai plusieurs).
    On peut soit lire ce fichier pour voir si le réveil est programmé et pour quand, ou écrire dans ce fichier pour programmer le réveil.
    On peut écrire dans deux formats différents, soit un temps absolu en secondes depuis l'epoch (timestamp unix), soit un nombre de secondes précédé d'un + pour indiquer das combien de secondes dans le futur il faut se réveiller.
    Donc dans ton cas, il suffirait d'ajouter un script à l'extinction qui fait un
    /bin/echo +120 > /sys/class/rtc/rtc0/wakealarm
    pour que la machine se réveille deux minutes après (il faut laisser assez de temps pour qu'il soit effectivement éteint).

    Attention que, de mon expérience (c'est peut-être dépendant du matériel), s'il y a déjà une date de réveil programmée il faut le mettre à 0 (echo 0) avant de pouvoir en affecter une nouvelle.

    • [^] # Re: programmer le redémarrage

      Posté par  . Évalué à 4.

      Génial !

      Je vient de tester sur mon PC perso, ça marche, j'ai pas testé sur le serveur, mais c'est du matos plus récent donc y'a pas de raisons. Du coup j'ai rajouté un job upstart dans /etc/init/ (c'est un serveur CentOS) :

      # autoboot - program rtc for automatic power on after 120 seconds
      #
      # This task is run on runlevel 0 and program rtc for automatic power on after 120 seconds
      # 
      
      start on runlevel [0]
      
      task
      
      script
      
      if [ -e /sys/class/rtc/rtc0/wakealarm ] ; then
          [[ -n $(cat /sys/class/rtc/rtc0/wakealarm) ]] && echo 0 > /sys/class/rtc/rtc0/wakealarm
          echo "+120" > /sys/class/rtc/rtc0/wakealarm
      fi
      
      end script    
      
      

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.