Un message mural a averti d'un redémarrage ou d'un arrêt imminent, mais j'ai raté les détails. Comment puis-je les obtenir?

Pendant qu'une certaine sortie était en cours d'écriture sur mon terminal, un message mural est passé. C'est allé trop vite pour moi de le lire. Tout ce que je pouvais dire, c'était

Broadcast message from

The system is going down for

Et même la plupart de cela est une supposition éclairée.

Surtout, j'ai raté quand ça descend. 20 minutes? 2 heures? 24 heures?

Puis-je relire le message du mur ou rechercher des arrêts / redémarrages planifiés quelque part? Je suis juste un utilisateur ordinaire sans root.

reboot messaging

— gerrit
source

une vérification rapide (centos7) montre que / var / log / messages a un enregistrement que l'utilisateur a envoyé un message sur le mur, mais pas le contenu dudit message. je ne suis pas sûr que 'wall' ou 'write' enregistre réellement le contenu des messages n'importe où ...

— 0xSheepdog

Même si le mur ne fonctionne pas, peut-être que l'arrêt / redémarrage a un journal des arrêts planifiés accessible au public? Je suis sûr à 99% qu'il s'agissait d'un message d'arrêt; Je veux juste savoir quand. Dans tous les cas, je n'ai pas d'autorisations de lecture pour /var/log/messages.

— gerrit

nologinn'existera que dans les cinq minutes avant l'arrêt, il n'est donc pas très utile si l'administrateur système a utilisé shutdownpour planifier un arrêt ou un redémarrage du système dans trois semaines. Cependant, d'autres avis périodiques seront de plus en plus fréquents à mesure que l'horizon de fermeture approche. Les pages de manuel pour shutdown, wallet mesgn'indiquent pas que le contenu de ces messages est conservé n'importe où. La présence de /var/run/nologinvous indique qu'il vous reste au plus cinq minutes.

— DopeGhoti

@gerrit Si vous démarrez xconsole sur un hôte distant, il s'exécute sur l'hôte distant. S'il ouvre un fichier, c'est un fichier sur l'hôte distant. Cela signifie que xconsole lit / dev / console sur l'hôte distant. Votre serveur X local affiche uniquement la sortie et s'assure que vos événements de clavier et de souris locaux sont envoyés à xconsole s'exécutant sur l'hôte distant.

— ceving

S'il y a un arrêt imminent en cours d'exécution, alors (pour l'écrire à nouveau) il y a un processus d'arrêt en cours, afin d'attendre et d'envoyer des diffusions régulières avant de lancer l'arrêt réel. Si les paramètres système permettent à un utilisateur normal de voir tous les processus, faites-le ps -ef|grep -w shutdownet vous devriez voir le processus d'arrêt, avec ses arguments, y compris le paramètre de temps (qui pourrait être absolu ou relatif)

— AB

Si vous avez le transfert X et la possibilité d'installer (ou de compiler) vos propres programmes, essayez d'exécuter xwrited pour transformer les wallmessages en notifications de bureau.

Si votre box UNIX exécute un init traditionnel (System V ou BSD), vous pouvez rechercher le processus d'arrêt en utilisant ps:

ps aux | grep shutdown

Cependant, lors de l'exécution systemd, le minuteur est implémenté dans le logind.service, donc psn'aidera pas. Vous pourrez peut- être savoir s'il y a un arrêt planifié en consultant le fichier /run/systemd/shutdown/scheduled:

$ cat /run/systemd/shutdown/scheduled 
USEC=1511457755542032
WARN_WALL=1
MODE=poweroff
WALL_MESSAGE=System going down for scheduled maintenance

Pour convertir des microsecondes en une date raisonnable, vous pouvez utiliser gawk:

$ awk -F= '/USEC/ {print strftime("%c", $2/1E6)}' < /var/run/systemd/shutdown/scheduled
Thu 23 Nov 2017 10:03:21 AM CET

Cependant, notez que certaines versions de systemd ne suppriment pas le fichier lorsqu'un arrêt est annulé. (La version que j'ai essayée, 232, laisse le fichier traîner après shutdown -c).

— hackerb9
source