But et utilisation typique de /etc/rc.local

73

L'en-tête ressemble à ceci:

#!/bin/sh -e
#
# rc.local - executed at the end of each multiuser runlevel
#
# Make sure that the script will "exit 0" on success or any other
# value on error.

Quelle est la raison de ce fichier (il ne contient pas grand chose) et quelles commandes y mettez-vous habituellement? Qu'est-ce qu'un "runlevel multi-utilisateur"? (Je suppose que rcc'est "exécuter des commandes"?)

debian configuration startup

— Emanuel Berg
source

2

Je ne sais pas si c'est le but "officiel" du fichier, mais j'ai découvert que je pouvais utiliser le fichier pour ce qu'il devrait se passer au démarrage et nécessiterait un accès super utilisateur, mais sans avoir à fournir le mot de passe. Cela implique généralement les couleurs, le clavier et d’autres éléments similaires. Découvrez quelques exemples ici .

— Emanuel Berg

66

Un niveau d'exécution est un état du système, indiquant s'il est en train de démarrer, de redémarrer ou de fermer, en mode mono-utilisateur ou en cours d'exécution normalement. Le programme init traditionnel gère ces actions en basculant sur le niveau d'exécution correspondant. Sous Linux, les niveaux d’exécution sont par convention :

S lors du démarrage,
0 lors de la fermeture,
6 pendant le redémarrage,
1 en mode mono-utilisateur et
2 à 5 en fonctionnement normal.

Les niveaux d'exécution 2 à 5 sont appelés niveaux d'exploitation multi-utilisateurs, car ils permettent à plusieurs utilisateurs de se connecter, contrairement au niveau d'exécution 1 qui est destiné uniquement à l'administrateur système.

Lorsque le niveau d'exécution change, init exécute des scripts rc (sur les systèmes dotés d'un init traditionnel - il existe des alternatives, telles que Upstart et Systemd ). Ces scripts rc démarrent et arrêtent généralement les services système et sont fournis par la distribution.

Le script /etc/rc.localest destiné à être utilisé par l'administrateur système. Il est généralement exécuté après le démarrage de tous les services système normaux, à la fin du processus de basculement vers un niveau d'exécution multi-utilisateur. Vous pouvez l’utiliser pour démarrer un service personnalisé, par exemple un serveur installé dans /usr/local. La plupart des installations n'en ont pas besoin /etc/rc.local, elles sont fournies pour la minorité des cas où cela est nécessaire.

— Gilles, arrête de faire le mal
source

2

J'ai découvert aujourd'hui que sous FreeBSD, rc.local pourrait être exécuté assez tôt. Certainement pas après le démarrage de tous les services système normaux. Je voulais un bip quand un accès sshd à une machine sans tête deviendrait disponible, et rc.localne convenait pas pour cette raison. Comme la question initiale concerne Debian, ce commentaire n’est probablement pas pertinent pour le PO.

— MvG

1

@ MVG Merci pour l'information. rc.localC’était traditionnellement la dernière fois, mais je vois que FreeBSD a cessé de le faire quand ils sont passés à un système basé sur la dépendance. Remarquez, même si a rc.localété invoqué après /etc/rc.d/sshd, cela ne fonctionnerait pas parfaitement: il rc.localserait invoqué peu de temps après le début du sshdprocessus, il pourrait être invoqué avant même d' sshdavoir commencé à écouter le réseau (mais nous parlerions des dixièmes de seconde à la plupart dans une configuration typique).

— Gilles 'SO- arrête d'être méchant'

J'essaie de l'utiliser pour configurer le réseau pour les conteneurs LXC et les démarrer automatiquement. Mais ça s'arrête après iptables-apply /root/iptables. Je suis en train de déterminer ce qui ne va pas (en attente du prochain redémarrage). Mais si vous avez des suggestions, je suis tout ouïe.

— x-yuri

1

@ x-yuri Cela nécessite beaucoup plus d'informations que ce que vous avez posté ici. Je ne sais même pas ce que “ça” est dans “ça s'arrête”. Posez une nouvelle question qui explique ce que vous avez fait.

— Gilles, arrête de faire le mal

14

rc dénote "contrôle de la course",

Le multiuserniveau d'exécution serait défini comme le niveau auquel la mise en réseau est disponible et ainsi, les connexions au serveur pourraient être établies à l'aide de ces services au lieu de connexions de console câblées.

Remarquez, les serveurs sont généralement gérés par un processeur de service (sous différents noms) qui prennent en charge les connexions réseau et agissent à leur tour comme si vous disposiez effectivement d'une console câblée.

En ce qui concerne le rc.localfichier, c’est un moyen pratique de vous permettre de spécifier tous les objets "locaux" (spécifiques au site) (démons et / ou scripts uniques au démarrage) que vous souhaitez démarrer. Vous pouvez choisir d'utiliser ce paradigme ou de renseigner de manière appropriée '/etc/init.d' avec les scripts de démarrage / d'arrêt.

— JRFerguson
source

1

D'accord, mais pourquoi le fichier est-il là, et quand l'utilisez-vous généralement, et comment (par exemple, quelles commandes ont du sens à y insérer)?

— Emanuel Berg

4

Je l'utilise principalement pour deux choses:

enregistrer la date et la version du noyau de chaque redémarrage. Un one-liner simple qui peut facilement être ajouté à des systèmes sans bourrage de papier ... et beaucoup moins sujet à la corruption de l'historique de démarrage qu'à l'exécution uptimed.
faire revivre l’ancien répertoire /etc/rc.boot/ qui était dans debian il ya quelques années. J'ai encore quelques scripts simples qui ne valent pas la peine de réécrire en tant que script init.d (par exemple un script Q & D pour envoyer dmesg à root, et un autre pour utiliser hdaparm afin de désactiver idle spindown et blockdev pour définir read- à venir) et je suis heureux qu’ils soient exécutés après tous les autres scripts de démarrage.

par exemple

echo "$(date +%s),$(date),$(uname -a)"  >> /var/log/reboot.log

[ -d /etc/rc.boot ] && run-parts /etc/rc.boot

De plus, j’ai écrit des scripts /etc/rc.local plus tôt cette année pour que les centos et les distributions Debian obtiennent les métadonnées de style ec2 depuis openstack (on http://169.254.169.254/), de sorte que les machines virtuelles obtiennent leur adresse IP, leur nom d’hôte, leurs clés ssh et d’autres informations spécifiques à une instance. . cloud-init a depuis été porté sur ces distributions, les scripts sont donc obsolètes.

— cas
source

3

Le rc.localfichier sur Debian est principalement destiné à la compatibilité avec des systèmes de style non-init. Vous ne devriez pas l'utiliser.

Au lieu de cela, il est recommandé de copier /etc/init.d/Skeletondans un nouveau script init pour ce que vous voulez faire lors du changement de niveau d'exécution, puis inservde l'activer.

Mise à jour: Selon le commentaire ci-dessous, cette réponse n'est plus recommandée. Cependant, cette réponse a été postée plusieurs années avant la dépréciation du squelette, et ce squelette existait toujours dans Debian unstable depuis janvier 2019.

— bahamat
source

unix.stackexchange.com/a/480897/5132 /etc/init.d/skeleton n'est pas la solution.

— JdeBP