Pourquoi les scripts init.d sont-ils dans etc?

16

Je continue à lire / entendre /etcpour les fichiers de configuration du système. Quelqu'un peut -il expliquer / me donner une certaine intuition pourquoi ces scripts de démarrage / arrêt / redémarrage divers programmes sont généralement au /etclieu de /varou /usrou quelque chose de similaire?

filesystems directory-structure Adam Thompson
la source
Bien que la question puisse être légèrement orientée vers l'opinion, je pense que la question peut être répondue par des faits réels.
Julie Pelletier
Les questions sur les raisons historiques sont-elles "basées sur l'opinion"? Avec le recul, il y a probablement une raison factuelle pour laquelle quelque chose s'est produit. Même si c'est simplement «parce que M. Grandhacker l'a fait ainsi», ce n'est pas aux opinions de quiconque de répondre à la question maintenant.
ilkkachu
Sauf que la question disait "pourquoi devraient-ils être" ce qui est un déclencheur de "discussions colorées" basées sur l'opinion. Modifié un peu pour le rendre moins. @Adam, revenez si vous pensez que cela est contraire à votre intention.
ilkkachu
1
Parce que quand et comment les services démarrent, c'est la configuration du système.
OrangeDog
1
Pour les raisins secs hystériques.
TMN

Réponses:

22

Au début (à la fois historiquement et en cours de démarrage ...), /etcfait partie de /(le premier système de fichiers monté), alors qu'il /usrne l'était pas (jusqu'à ce que les disques soient volumineux). /varcontient des données temporaires , alors que ces scripts ne sont pas temporaires.

Ce n'est pas si simple, mais cela a commencé de cette façon et il n'y a pas de raison de retravailler la mise en page du répertoire entier.

Thomas Dickey
la source
1
Comme vous le dites, ce n'est pas si simple. Divers systèmes UNIX commerciaux avaient des exécutables binaires réels /etcà un moment ou à un autre. Au moins, init.dc'est surtout des scripts sur les systèmes modernes. Mais il n'est toujours pas possible d'avoir /etcmonté en lecture seule.
Satō Katsura
2
@SatoKatsura: Avec l'avènement des langages compilés qui ressemblent à des langages de script, j'ai commencé à remarquer que certains scripts / etc (même les scripts d'initialisation) étaient remplacés par des programmes go - exécutables binaires.
slebetman
Il est également intéressant de noter que les remplacements modernes de sysVinit utilisent en fait des fichiers de configuration simples au lieu de scripts à part entière, donc /etcpourraient finir par nettoyer les éléments non config.
GnP
/tmpcontient des données temporaires. /varcontient des données variables
Neil McGuigan
14

Les scripts de démarrage sont en fait une partie importante de la configuration du système.

Même si le processus de démarrage est beaucoup moins personnalisé qu'il y a 15-30 ans et que la plupart de la configuration de démarrage a été automatisée, tous ces choix administratifs qui déterminent la séquence de démarrage sont toujours présents /etc.

Cela représente un moyen très centralisé de maintenir et de sauvegarder la configuration du système. Sur la plupart des systèmes, la sauvegarde /etcest suffisante pour permettre une réinstallation de l'ensemble du système en toute simplicité. Vous effectuez simplement une réinstallation complète avec les programmes nécessaires et restaurez votre /etcsauvegarde.

Julie Pelletier
la source
3

M. Dickey et M. Pelletier ont tous deux acheté les locaux de la question. Mais les prémisses sont fausses.

Si vous avez lu que " /etcconcerne les fichiers de configuration du système", vous avez lu quelque chose qui ne donne pas l'image complète pour vous. Regardez le nom. C'est "et cetera". Les gens ont tout mis à côté de l'évier de la cuisine à un moment ou à un autre.

  • /etc/rc utilisé pour être (et sur certains systèmes est toujours) le programme exécuté pour tout démarrer.
  • Le fichier image du programme pour le premier processus utilisateur était /etc/inità un moment donné (dans XENIX, par exemple, bien avant que le démarrage ne soit même une idée).
  • /etc/profile,, /etc/zprofileet tout le reste sont définitivement des scripts.
  • OpenBSD /etc/netstartest un programme; tout comme FreeBSD /etc/ipfw.rules.
  • Il en va de même pour FreeBSD /etc/rc.suspendet /etc/rc.resume; et en effet /etc/rc.sendmail, /etc/rc.bsdextendedet /etc/rc.firewall.

De même, si vous avez lu que "les scripts qui démarrent / arrêtent / redémarrent divers programmes sont généralement à la /etcplace de /varou /usrou quelque chose de similaire", alors vous avez lu autre chose qui ne donne pas une image complète pour vous.

  • La convention FreeBSD / PC-BSD consiste à avoir un /usr/local/etc/rc.d/répertoire pour les rcscripts non-système d'exploitation . rcdes scripts pour toutes sortes de choses y vivent plutôt que sous /etc.
  • Vous trouverez des gens daemontools famille mettre des choses de gestion des services dans /var/sv, /var/serviceet des lieux similaires. (Mon ensemble d'outils Nosh, par exemple, fournit près d'un millier de bundles de services /var/sv. Les seuls bundles de services qui entrent /etc/service-bundlessont entre 60 et 70 nécessaires avant le /usrmontage, y compris les services qui montent et vérifient/usr si nécessaire.)
  • Les conventions du système d'exploitation systemd contiennent des éléments vivants /etc/systemd, des éléments internes /run/systemd, des éléments internes /usr/lib/systemdet ( même s'ils ne sont pas documentés pour des raisons inapplicables ) des éléments internes /usr/local/lib/systemd. Encore une fois, la majorité des «choses pour démarrer / arrêter des services» se trouvent sous /usrplutôt que sous /etc.
JdeBP
la source
2

Vous feriez bien de revoir la norme de hiérarchie du système de fichiers . Il expliquera (en détail) exactement pourquoi cela est, mais il contient également de telles informations sur de nombreux autres chemins qui pourraient vous intéresser.

La norme de système de fichiers a été conçue pour être utilisée par les développeurs de distribution Unix, les développeurs de packages et les implémenteurs de système. Cependant, il est principalement destiné à être une référence et n'est pas un tutoriel sur la façon de gérer un système de fichiers Unix ou une hiérarchie de répertoires.

draeath
la source
Cela n'explique pas le contexte historique.
Thorbjørn Ravn Andersen