Forum

Bonjour la communauté,

Après une mise à jour automatique (exemple : un "urpmi --auto-update" lancé par "cron"), comment savoir si un reboot est nécessaire (mise à jour "kernel" ou "glibc" ou "systemd "par exemple)?
"urpmi" donne cette info quand il est invoqué à la main ou via MCC. Je n'arrive pas à récupérer cette info dans le cas d'une mise à jour en tâche de fond.

Tu peux envoyer le résultat dans un fichier :


Et là, ton fichier /root/maj.reboot contient l'information avec reboot. Tu l'effaceras alors le fichier /root/maj et /root/maj.reboot après avoir vérifié leurs informations et rebboté.

Trop marrant !
Au lieu de faire la mise à jour à partir de l'applet et de regarder s'il faut rebooter, lancer un script, on ne sait pas quand, et aller voir dans un fichier s'il faut rebooter.
Je ne sais pas pourquoi, cela me rappelle les shadocks !

Salut,

Étrange cela ...
Si une MàJ est en cours, par exemple un kernel et qu'il recompile les modules, et que par malheur tu redémarres le PC à ce moment là ... c'est le drame ...

Néanmoins tu peux récupérer "facilement" la valeur avec grep



Voila, sinon, la notification de notify-send, j'utilise su - $USER car sinon, la commande est envoyée sur le bureau de root ... tu ne la verras donc pas.
La commande wall quant à elle diffuse partout, même en console !!!

Les remarques étaient pour mon script ?



Je pense que l'intérêt de cette manipulation, c'est sur un serveur où on n'a pas de session. On vérifie par ssh ce qu'il en est.

Par contre, je ne comprends pas la remarque

En effet, urpmi ne rendra la main que lorsque toutes les recompilations qu'il effectue seront achevée non ?



Et pour finir, j'aime bien (c'est lui que je regarde) les lignes suivantes :

C'est un historique des mises à jour qu'il faut bon de temps en temps de regarder.

Non, c'était pour les mises à jours en automatique en cron, car on ne sait pas ce qu'il fait et quand ...



En aucunement, mon message ne t'étais destiné Troumad



Je n'ai pas rafraichi le sujet avant d'écrire, je n'ai pas vu les deux réponses précédentes

Bonsoir à tous,

Merci tout d'abord pour vos propositions. Je vais cependant ajouter un peu d'entropie dans le système : je ne maîtrise pas la langue par défaut des systèmes concernés. Une grande partie est située en Amérique du Sud.
Ma question va être plus précise : dans un RPM, où se situe l'information qui déclenche le message d'avertissement de demande de reboot?
En effet, cela concerne des serveurs (projet ALCASAR). J'ai des retours de sites ayant un 'uptime' de plus de 16mois (sans reboot, autant dire que le noyau actif n'était pas d'une grande fraîcheur). Cela prouve au moins que la robustesse de Mageia n'est pas qu'une légende.

Édité par rexy Le 04/03/2015 à 21h21

Me parait plus qu'hasardeuse ton idée de script mise a jour + reboot en automatique sans aucun contrôle manuel, une mise a jour douteuse et paf tout est planté et après va trouver de quoi ça viens, et comment remettre en route

perso je verrais plus une solution de gestion de pc a distance ...

Comment dire.... un reboot lancé à distance qui plante = plus de PC à distance ...

Édité par rexy Le 05/03/2015 à 23h39

je pensais a un contrôle au niveau de la mise a jour a distance, et éventuellement OpenSSH pour une gestion par shell, maintenant si le pc il foire au boot distant ou pas c'est chaud mais au moins d'avoir eu un oeil sur la mise a jour te donnera une idée du soucis, puis de toute façon il y a des problemes qui ne pourront jamais se régler distance



maintenant je ne suis pas un pro du pc distant, mais de mon avis quand tu as un/des pc avec aucun ou peu d’accès physique dessus bah tu installes un systeme super stable et tu évites autant que possible les mise a jour au moins celle qui ne sont pas de securité