Bonjour,
je fais certaines actions après chaque boot. J'ai actuellement mis ces actions dans un fichier /etc/init.d/monscript.sh avec les réglages qu'il faut. Ca fonctionne bien, mais je ne suis pas sûr que ce soit la méthode propre.
Mon script lance un sous-shell et laisse la main immédiatement. Le sous-shell fait un sleep 120 puis lance les actions que je veux.
Je fais ça pour éviter que tout se lance en même temps. Comme ce sont des actions non urgentes, ça peut attendre quelques secondes (c'est sur des serveurs).
Avant je faisais un sleep, puis j'attendais que les IO soient en dessous d'un seuil, le tout borné par une durée maxi. Mais ça n'avait pas beaucoup d'intérêt pour mon besoin.
Un avantage d'utiliser /etc/init.d/ est que je peux avoir des actions à l'extinction (ce que ne m'est actuellement pas utile).
Une autre possibilité est d'utiliser cron avec une entrée @reboot, et toujours un sleep en début de script.
Vous voyez quoi comme solutions propres pour lancer une commande quelques secondes (paramétrable) après chaque boot ?
# atd !
Posté par Marotte ⛧ . Évalué à 2.
Salut,
Utiliser cron et surtout at :
(de man at)
Au lieu de lancer directement depuis cron le script, tu lances un :
./le_script.sh | at now + 1 minutes
Après c'est pas à la seconde près mais à la minute.
Tu peux aussi regarder du coté de anacron et fcron
Et :
Quel est ton besoin réel. Que sont sensés faire les scripts et programmes que tu veux lancer après le boot ? Sauvegarde, mise à jour ?
[^] # Re: atd !
Posté par Marotte ⛧ . Évalué à 2.
voir même :
avant qu'on me fasse des remarques...
[^] # Re: atd !
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je suis dans la même situation. Par exemple, je dois envoyer des machines virtuelles qui sont sur une baie SAN. Je ne suis pas assurer à 100% que la baie soit accessible à la fin du boot du serveur, cela dépend du temps de boot de chaque équipement.
J'envoie donc les VM 5min après le boot du serveur...
[^] # Re: atd !
Posté par Marotte ⛧ . Évalué à 1.
Est-ce que ton script ne pourrait pas tester la disponibilité du SAN ? Si c'est dispo le reste du script (envoi de la VM) s'exécute, sinon le script termine et se re-planifie 1 minute plus tard (en utilisant at). Et ainsi de suite. Comme ça le traitement à lieu dès que c'est possible (modulo une minute).
[^] # Re: atd !
Posté par Michaël (site web personnel) . Évalué à 2.
<pinaillage>Modulo une minute, ça peut vouloir dire 1 heure ou 1 an après aussi … tu veux dire à une minute près.
</pinaillage>[^] # Re: atd !
Posté par Marotte ⛧ . Évalué à 1.
Mauvaise utilisation du mot modulo c'est vrai. Je savais que j'aurai pas dû mettre la fin entre parenthèses... Tu as bien compris que je voulais dire que le traitement partira au maximum une minute après la mise à disposition du SAN.
[^] # Re: atd !
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
En pratique, c'est cela que je fais. J'ai simplifié pour rester simple ;-)
[^] # Re: atd !
Posté par gremous . Évalué à 1.
Vérifier des partitions avant de les monter (sinon en cas de problème, la vérification automatique bloque le boot).
Lancer ntp (s'il est lancé lors du boot et que l'accès au réseau pose problème, il bloque le boot).
Et d'autres choses du même genre. En gros, désactiver les cochonneries qui stoppent la machine et obligent à se déplacer (450km aller-retour, non merci).
[^] # Re: atd !
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Idem pour moi ! Objectif, avoir une machine accessible via SSH, ou tout au moins sur tty0 le plus vite possible et quasiment à tous les coups.
# init.d et rc.d
Posté par Michaël (site web personnel) . Évalué à 6.
En principe les scripts de démarrage contenus dans ces dossiers ont vocation à initialiser la machine, c'est à dire la faire parvenir dans son état opérationnel: le montage des systèmes de fichiers, l'initialisation du réseau et le démarrage des serveurs correspondent à ça. Si ton script s'apparente à ce genre de tâche, il est bien à sa place dans init.d.
S'il s'agit d'une mise à jour de base de données automatique ou des routines d'hygiène diverse et variées, ma sensibilité irait plutôt vers un cron @reboot. Je ne vois pas pourquoi l'idée de faire un
sleeppour attendre un peu que le système se calme ta paraît si sale que ça …[^] # Re: init.d et rc.d
Posté par BFG . Évalué à 1.
Parce que le temps en paramètre du sleep est généralement une valeur complètement arbitraire, et qu'elle sera le plus souvent trop courte (si le système ne s'est pas "calmé", si d'autres scripts nécessaires auraient dû avoir lieu avant celui-ci mais n'ont pas eu le temps) ou trop longue (tout le reste été initialisé rapidement, mais le sleep retarde inutilement la fin de l'initialisation).
En programmation en particulier, utiliser sleep pour attendre la fin d'une autre tâche de programme est une mauvaise pratique.
[^] # Re: init.d et rc.d
Posté par Michaël (site web personnel) . Évalué à 2.
C'est aussi mon avis, mais l'OP fait ça pour éviter que tout se lance en même temps.
Dans les systèmes BSD (Free et Net, pour Open, je ne sais pas), les scripts d'initialisation sont triés par des dépendences, un peu comme les cibles d'un Makefile. Sur les systèmes GNU/Linux, il y a probablement un procédé permettant la hiérarchisation des sous-tâches de l'initialisation. Ce système peut aussi permettre d'appeler la routine à un moment opportun.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.