Question dans une question (du wiki Debian ):
Dois-je utiliser Sid sur mon bureau?
Si vous pensez que vous pouvez gérer un système Debian cassé, bien sûr. Savez-vous quoi faire si libpam0g se casse, empêchant toutes les connexions? Savez-vous quoi faire si grep se casse, entraînant un blocage permanent du processus de démarrage? Ces choses se sont produites. Ils se reproduiront.
Ma question est, comment un brisé greppeut-il bloquer définitivement le processus de démarrage?
Réponses:
Il est courant que les scripts de démarrage appellent grepà un moment donné. Si se grepbloque en raison d'un bogue, le premier de ces scripts de démarrage qui appelle grepse bloque. Ou, plus communément, si l'un de ces scripts est cassé et appelle grepsans fournir d'argument de nom de fichier et sans rediriger l'entrée, greprestera indéfiniment en attente d'entrée de la console (ce n'est pas si mal si vous êtes devant la console et pouvez type Ctrl+D). Si un script est cassé et fait appel grepà un tube ou un périphérique où personne n'écrit… tant pis.
Eh bien, la façon évidente serait "grep se bloque pour toujours, donc quelque chose qui utilise grep se bloque pour toujours, et quelque chose dans le processus de démarrage fait cela".
Le texte est susceptible d'illustrer plutôt que d'exemples littéraux de problèmes, mais ce n'est pas impossible.
Pour vraiment comprendre, commencez à lire à /etc/init.d/rcet /etc/init.d/rcS- ce sont les scripts shell qui exécutent tous les bits qui font apparaître votre système.
grepestgrep -r pattern . > pattern.grep. Puisque le shell crée le fichier de sortie avant l'appelgrep, lagrepcommande recherche le fichier de sortie, qui grandit jusqu'à ce que le disque se remplisse. Je n'ai aucune idée si cela est lié à quelque chose qui pourrait entraîner le blocage du processus de démarrage pour toujours.