web-dev-qa-db-fra.com

Comment envoyer un correctif pour réparer tous les dommages causés par LP: # 600941?

Quelle est la meilleure façon de soumettre un patch pour réparer tous les dégâts causés par LP: # 600941 ?

Je demande parce que LP: # 600941 a été mis dans toutes les versions d'Ubuntu toujours prises en charge à ce moment. Dois-je choisir une version particulière et exécuter ubuntu-bug dessus? Cette version doit-elle être le LTS ou Oneiric ou Precise (comment puis-je obtenir Precise si j'en ai besoin?)

L'histoire est qu'après sa sortie, tous nos systèmes ont commencé à subir des échecs de redémarrage de Nagios nrpe.

Des commandes comme /etc/init.d/nagios-nrpe-server restart

entraînerait l'arrêt de nrpe mais pas son redémarrage.

J'ai suivi cela jusqu'à la façon dont le /etc/init.d/nagios-nrpe-server le script appelle start-stop-daemon.

Le problème est que la strophe "stop" dans le /etc/init.d/nagios-nrpe-server le script appelle d'abord le démon start-stop qui envoie SIGTERM à nrpe puis n'attend qu'une seconde.

Si nrpe n'est pas sorti à ce moment-là, le fichier pid existera toujours et le /etc/init.d/nagios-nrpe-server le script le supprimera.

Pire si /etc/init.d/nagios-nrpe-server restart est utilisé non seulement le fichier pid sera supprimé, la tentative de redémarrage de nrpe échouera à condition que le démon nrpe soit toujours en retard dans l'arrêt.

La tentative de démarrage dans ces circonstances échouera car nrpe sera toujours lié à un socket et la deuxième tentative de liaison entraînera l'abandon du démarrage de nrpe.

Ils auraient dû se demander pourquoi il y avait un commentaire sur "parfois le fichier pid n'est pas supprimé".

Ils auraient dû tester sur des systèmes qui ont une forte charge et donc des temps de réponse nrpe lents.

Le correctif consiste à ajouter --retry 10 ou tel à l'invocation de start-stop-daemon ... --stop ...

Merci

9
nutznboltz

Tout d'abord merci pour tout le travail sur les bugs que vous avez fait jusqu'à présent. C'est génial que vous souhaitiez vous impliquer dans la correction de ce bogue!

La meilleure façon est de signaler un nouveau bogue contre précis, et de préciser qu'il s'agit d'une régression causée par LP: # 600941. Donnez-lui la balise "regression-updates". Il serait également bon de le mentionner dans les commentaires de LP: # 600941, afin que les utilisateurs le voient lorsqu'ils enquêtent eux-mêmes sur la régression. La balise de mise à jour de régression garantira que votre bogue est trié et réagit rapidement. Alors oui, commencez d'abord par ceci:

ubuntu-bug nagios-nrpe-server

Comme cela affecte toutes les versions, peu importe où vous faites cela (mieux vaut le faire sur une plate-forme que vous pouvez laisser seule pour vérifier les correctifs).

À l'heure actuelle, les ISO précis ne sont probablement pas installables, mais vous pouvez les essayer ici:

http://cdimage.ubuntu.com/daily/current/

Vous pouvez également prendre une machine oneiric sur precise en éditant les sources dans /etc/apt/sources.list* et en changeant oneiric en precise, puis en faisant apt-get update && apt-get dist-upgrade. Cependant, il y a des transitions et de grands changements, alors ne faites pas cela sur un système de production!

Pour soumettre le correctif, le meilleur moyen consiste à utiliser Ubuntu Distributed Development. Attribuez-vous le bogue, puis procédez comme suit:

bzr branch lp:ubuntu/nagios-nrpe
cd nagios-nrpe
<edit files that need editing>
dch -D precise -i 'Fixing regression caused by bug 600941. (LP: #XXXXXX)'
debcommit
bzr Push lp:~nutznboltz/ubuntu/precise/nagios-nrpe/fix-lpXXXXXX
bzr lp-propose

XXXXXX est votre nouveau bogue #

Vous pouvez en savoir plus sur la façon de le faire sur https://wiki.ubuntu.com/DistributedDevelopment

N'hésitez pas à venir demander également dans # ubuntu-devel et/ou # ubuntu-server sur Freenode.

14
SpamapS