sudo shutdown -h now
Je ne suggère pas de faire ce qui suit si vous n'êtes pas obligé par des raisons vraiment particulières :
kill -SEGV 1 # should generate a core dumps and kernel panic
kill -ABRT 1 # should generate a core dumps and kernel panic
kill -9 1 # On old systems worked nowadays not
C'est rugueux, brutal et cela peut être considéré comme un équivalent proche du débranchement du cordon d'alimentation ...
La bonne manière est shutdown -h now
avec sudo
avant en cas de besoin.
Peut-être devrais-je dire de manière légale; voir ci-dessous ou mieux tl;dr.
Quelques mots de plus , alias L'histoire, Chapitre I
Au début était l'init et ce sera jusqu'à la toute fin.
L'ensemble de Linux dépend du soin affectueux de init . Néanmoins et non sans une certaine dose d'ingratitude, il fut un temps où l'bon Dieu utilisateur root peut trahir cet amour et soudain kill
init avec un incontournable (-9
) ordre.
(Le Livre de l'Etiquette prescrit aux comtes, ducs et marquis utilisateurs à invoquer avant un sudo
).
Ensuite, des sorciers ont créé un charme pour protéger init (du Livre de man 2 init
)
Les seuls signaux pouvant être envoyés au processus ID 1, le processus init, sont ceux pour lesquels init a explicitement installé des gestionnaires de signaux. Ceci est fait pour s'assurer que le système ne tombe pas en panne accidentellement.
cette initialisation gérera 1 HUP 6 ABRT 11 SEGV 15 TERM 30 PWR 2 INT 10 USR1 14 ALRM 17 CHLD 32)
Alors le bon Dieu utilisateur root apprendre les nouvelles et changer la commande en kill -ABRT 1
ou kill -SEGV 1
qui génèrent généralement une panique du noyau et un core dump.
Cela fonctionne parce que init est le premier processus à s'exécuter et prend le PID numéro 1 .
C'est dangereux, imprudent et vous sentez que c'est le signe d'un mauvais présage et d'une malédiction, mais si vous ne pouvez pas matériellement mettre la main dessus et le débrancher...
La malédiction :il n'écrira pas sur le journal, il ne tuera pas tous les processus et n'attendra pas leur fin, il n'écrira pas sur le disque dur en mettant correctement à jour les inodes et il ne démontera pas non plus les systèmes de fichiers ; cela ne vous dérange même pas qu'il enregistre les options des fenêtres graphiques et des historiques du shell, et bien d'autres au-delà de notre imagination... comme nous l'avons dit, cela équivaut à débrancher le câble d'alimentation ou la batterie d'un ordinateur portable.
La bonne manière
Le légitime la méthode (correcte) consiste à utiliser shutdown
sudo shutdown -h now
l'arrêt permet d'arrêter le système en toute sécurité. Tous les utilisateurs connectés sont avertis que le système est en panne et...
mais avec -h now
ils n'auront pas le temps d'en faire autant...
Quelques mots de plus , alias L'histoire, Chapitre II
Il était une fois des étapes logiques ressenties du ciel au-dessus des gens d'Unix :
Une fois que les processus système ont été tués et que les systèmes de fichiers ont été démontés, le système s'arrête/s'éteint ou redémarre automatiquement. Cela se fait à l'aide de la commande halt ou reboot, qui synchronise les modifications sur les disques, puis effectue l'arrêt/la mise hors tension ou le redémarrage proprement dit.
En effet, de nos jours, on ne fait plus confiance à l'existence des trois Moirai du monde Linux , reboot
,poweroff
et halt
:la science moderne de ls -l $(which poweroff halt reboot)
et celui de man reboot
, répand une nouvelle lumière sur cet âge sombre et nous révèle qu'il n'existe qu'une seule vraie commande qui analyse toutes leurs options afin que nous soyons enfin libres de demander des actions contredisant leurs noms de commandes ! (halt -p
ou reboot -p
pour poweroff
, shutdown -r
pour reboot
...)
Maintenant que tout semblait clair et confortable pour tous, des rumeurs prétendent que dans le monde souterrain de ensemble d'outils systemd une révolution a été accomplie en laissant inconscient tout le surmonde . Grâce à une armée de shims de rétrocompatibilité nous n'avons pas du tout remarqué que le redémarrage, la mise hors tension, l'arrêt et même telinit et l'arrêt sont tous déjà liés au nouveau roi systemctl . S'il vous plaît écoutez toute l'histoire de la voix originale de JdeBP The Bard parce que je n'ai plus de souffle.
Si vous êtes un adepte du culte Ubuntu, vous resterez peut-être encore au courant pendant un certain temps de toutes ces affirmations.
La Terre du Milieu de halt -f
, init
, telinit
, systemctl
Rechercher une solution plus rapidement que la bonne mais tout aussi sage.
systemctl --force --force poweroff # the most close to kill -9 1
systemctl --force poweroff # rough but still safe
sudo halt -f # rough
sudo telinit 0 # or 6 # safe
kill -SIGINT 1 # cause reboot as the reboot command
kill -SIGRTMIN+4 1 # cause shutdown as the halt command
Que vous soyez sous systemd ou non vous devriez pouvoir arrêter l'ordinateur sans invoquer toutes les procédures d'arrêt correctes (et donc plus rapides) :
-
halt -f
:en spécifiant l'option-f
(notez que vous avez besoin de-f
pour éviter la procédure d'arrêt) avec la commande ci-dessus, avecsudo poweroff -f
ou peut-être même avecsudo reboot -f -h
.En effet on peut lire à partir deman reboot
(et équivalents) sur la nécessité de spécifier l'option-f
pour éviter d'appeler l'arrêt :Lorsqu'il est appelé avec --force ou lorsqu'il est au niveau d'exécution 0 ou 6, cet outil invoque l'appel système reboot(2) lui-même (avec l'argument REBOOTCOMMAND passé) et redémarre directement le système .
Sinon, cela invoque simplement l'outil shutdown(8) avec les arguments appropriés sans passer l'argument REBOOTCOMMAND.
-f, --force
N'invoque pas shutdown(8) et à la place exécute l'action réelle que vous attendez du nom . -
De plus, vous pouvez utiliser
telinit
(ouinit
directement)sudo telinit 0 # or 6
dire à init de changer de niveau d'exécution... mais si oui, pourquoi ne pas le tuer directement ?
-
Sous systemd, vous pouvez utiliser la double option imprudente
--force --force
systemctl --force --force poweroff
Lecture du manuel systemctl
-f, --force
Lorsqu'il est utilisé avec enable, remplace tous les liens symboliques conflictuels existants.
Lorsqu'il est utilisé avechalt
,poweroff
,reboot
ou kexec, exécute l'opération sélectionnée sans arrêter toutes les unités. Cependant, tous les processus seront tués de force et tous les systèmes de fichiers seront démontés ou remontés en lecture seule. Il s'agit donc d'une option drastique mais relativement sûre pour demander un redémarrage immédiat. Si --force est spécifié deux fois pour ces opérations, elles seront exécutées immédiatement sans terminer aucun processus ni démonter aucun système de fichiers. Avertissement :spécifier deux fois --force avec l'une de ces opérations peut entraîner une perte de données.
Ps> Inspirez-vous des variantes de la queue JdeBP The Bard .
Vous pouvez éteindre la machine immédiatement sans synchroniser les disques en écrivant "o" dans /proc/sysrq-trigger en tant que root.
En tant que script shell, cela ressemblerait à quelque chose comme
#!/bin/sh
echo o >/proc/sysrq-trigger
Si vous avez des autorisations sur /proc/sysrq-trigger, vous n'avez pas à l'activer via sysctl. Cette option n'affecte que le déclenchement au clavier.
Je ne recommande pas de faire cela sur une machine avec un système de fichiers que vous souhaitez lire plus tard.
Je l'utilise sur Google Compute Engine pour abattre les instances modélisées juste avant la fin des dix minutes afin de maximiser la rentabilité des tâches de cluster, cela fonctionne très bien.