[gull] init scripts ne démarrent pas

[Daniel Cordey]

On Wed, April 18, 2012 14:58, Leopoldo Ghielmetti wrote:
> Personnellement je n'aime pas du tout ce nouveau système.

Sentiment un peu partagé :-) Mais... je crois qu'il faut faire avec (comme toujours). IL est vrai que GNU/Linux souffre toujours du
syndrome du dévelopeur qui àcrit de très belles chose mais est un profond incapable lorsqu'il s'agit d'écrire une documentation ou des
outils de gestion de son application. GNU/Linux a maintenant 21 ans et toujours une méthode archaïque de gestion du système. Certains
estiment qu'il est plus glorieux de se faire ch... a modifier des dizaines de fichiers de config avec un éditeur (aux syntaxes toutes plus
débiles les unes que les autres), plutôt que de'avoir un GUI... Qui plus est, ces même personnes méprisent ceux qui utilisent des GUI sous
prétexte que l'on ne comprend pas ce que l'on fait avec une souris. Il y a bien eu, un temps, 'webmin', mais ça semble être un peu
abandonné. Certaiens distros offernt des outils de gestion des généralité, mais, bizarrement, rien pour gérer ce qui a justement besoin
d'être géré proprement; tel que DNS, mail, upstart, apache, etc. Donc, ces 'outils' ne font que le plus facile et laisse le plus
compliqué... Cela donne une fausse illusion de maîtrise de ce que l'on fait ! Pourquoi fausse ? Parceque, à moins d'avoir
consciensieusement éxaminé le code source, on ne connait pas vraiment la portée d'utilisation de certains paramètres. Ce n'est pas
parceque l'on a mis une variable à '1' qu'elle va faire ce que l'on pense. EN général oui, mais pas toujours ! Ce n'est donc pas plus sûre
qu'un GUI.

ET donc... en effet, il n'exsiet pas de GUI pour gérer et vérifier que son fichier 'upstart' est bien écrit et va effectuer le travail au
bon moment. Non, il faut se taper une immense doc pour analyser les subtilités des changements apportés par 'upstart'. C'est seulement
après cette lecture que l'on est censé atteindre la "lumière". Oui, car utiliser GNU/Linux se mérite et la "souffrance nous rapproche de
la vérité"... super programme :-)

> J'ai par exemple des machines virtuelles kvm qui tournent sur ma machine
> et il faut que je les arrête manuellement avant de rebooter mon serveur
> car il est impossible d'instruire upstart d'arrêter correctement les taches.

Ah là... tu tentes le diable... tu investis une zone encore mal défrichée... :-) On se gargarise de multi-threading et de virtualisation,
mais lorsque l'on aborde la partie gestion du système, tout le monde part en courant en disant "j'ai un sanglier sur le feu". J'ai dû
m'écrire tout un système de gestion des onteneurs et routage des adresses IP pour OpenVZ, car il n'existe rien... Je ne connais pas KVM et
j'aurais tendance a dire qu'il devrait exister un process 'upstart' qui devrait arrêter tout les noeuds actifs, avant d'arrêter
complètement la machine. Au moins OpenVZ fait ça, mais je ne sais pas s'il existe ce genre d'outil pour des config KVM.

> Le script d'arrêt que j'ai fait refuse de lancer la tache qui signale
> l'arrêt aux machines kvm car il s'agit de lancer une nouvelle tache à
> l'arrêt, chose qu'on ne peut pas faire avec upstart. En plus, même si
> j'arrive en forçant un peu a envoyer un signal d'arrêt, upstart kille
> automatiquement mes machines kvm car pour le shutdown elles prennent un
> temps non nul. Et il est impossible de placer des sleep ou autre
> commande dans les taches d'arrêt upstart.

Oui... mais upstart peut lancer un shell script standard... Ne serait-ce pas la solution ? Je sais, c'est un peu lourd et pas très logique
mais peut-être la seule solution pour le moment :-(

> En plus l'arrêt de squid ne marche jamais correctement et du coup il
> n'arrive pas a démonter les disques (la aussi je pense qu'il s'agit d'un
> problème de temporisation). Le résultat c'est un check complèt des
> disques au redémarrage si jamais j'oublie d'arrêter squid à la main.

Comment une machine KVM peut-elle faire un 'shutdown' ? Ne peut-on effectuer un 'shutdown -h' dans chacune des machines ?

> Pratiquement upstart à été un vrai pas en arrière par rapport au scripts
> sysinit. Ils sont aussi plus difficiles à configurer et à maitriser.

Oui, et en plus tu dois te taper plein de doc pour faire la mêmem chose qu'avant... sans être plus avancé. En plus, si tu râles tu es pris
pour un rétrograde... Maintenant que tu soulèves ce problème, je vais me pencher un peu plus sur cette nouvelle infrastructure. A priori,
ce genre d'outil n'est pas changé à la légère et plein de gens ont participé a son élaboration. Je me dis que tout ces gens compétents
n'ont pas pu passer à côté de l'essentiel. Peut-être a-t-on mal lu la doc, ou pas assez ? Je vais voire.

> J'aimerais bien pouvoir le supprimer du système et rétablir l'ancien
> système, mais du coup il me faudrait changer de distribution.

C'est un peu comme l'eau qui monte. Changer de plage ne va faire que retarder l'échéance.

dc