Lua-resty-auto-ssl: Problème de verrouillage

Owch, désolé d'apprendre que cela a conduit à une panne !

Je n'ai malheureusement rien vu de tel dans notre installation qui reçoit un trafic décent (depuis l'incident de mars dernier auquel vous avez fait référence). Cependant, il y avait un autre problème quelque peu similaire à celui-ci signalé dans #29, où nous avons corrigé un problème qui aurait pu être lié, mais il n'a peut-être pas totalement expliqué le problème. Mais ce problème peut également ne pas être lié (il était spécifique au moment où les enregistrements ont eu lieu).

Merci pour l'offre d'aider à déboguer cela, cependant, il serait certainement bon d'aller au fond des choses. J'ai quelques questions initiales :

• Quelle version de lua-resty-auto-ssl utilisez-vous ?
• Exécutez-vous OpenResty ou nginx avec le module lua installé manuellement ?
• Quelles versions d'OpenResty ou de nginx+lua utilisez-vous ?
• Quel mécanisme de stockage utilisez-vous avec lua-resty-auto-ssl (Redis, système de fichiers, autre chose) ?
• À quelle fréquence les choses se bloquent-elles ? Cela semble-t-il se produire uniquement lorsque de nouveaux certificats sont enregistrés ou que des renouvellements ont lieu, ou est-ce apparemment aléatoire ?
• Rechargez-vous nginx (en envoyant un SIGHUP au processus maître et en générant de nouveaux travailleurs au lieu de redémarrer complètement le processus maître) ?
• Combien de nœuds de calcul nginx avez-vous en cours d'exécution (paramètre worker_processes dans la configuration de nginx) ?
• Avez-vous d'autres plugins nginx installés (au-delà de ceux fournis par défaut avec OpenResty si vous êtes sur OpenResty) ?

lua-resty-auto-ssl est 0.10.3-1 de luarocks
Nous utilisons OpenResty 1.11.2.2.

nginx version: openresty/1.11.2.2
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.0.2h  3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/usr/local/openresty/nginx --with-cc-opt=-O2 --add-module=../ngx_devel_kit-0.3.0 --add-module=../echo-nginx-module-0.60 --add-module=../xss-nginx-module-0.05 --add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.31 --add-module=../form-input-nginx-module-0.12 --add-module=../encrypted-session-nginx-module-0.06 --add-module=../srcache-nginx-module-0.31 --add-module=../ngx_lua-0.10.7 --add-module=../ngx_lua_upstream-0.06 --add-module=../headers-more-nginx-module-0.32 --add-module=../array-var-nginx-module-0.05 --add-module=../memc-nginx-module-0.17 --add-module=../redis2-nginx-module-0.13 --add-module=../redis-nginx-module-0.3.7 --add-module=../rds-json-nginx-module-0.14 --add-module=../rds-csv-nginx-module-0.07 --with-ld-opt=-Wl,-rpath,/usr/local/openresty/luajit/lib --with-http_ssl_module --with-http_perl_module --with-http_v2_module --with-http_secure_link_module --add-module=/nginx-build/openresty-1.11.2.2/../testcookie-nginx-module --add-module=/nginx-build/openresty-1.11.2.2/../lua-upstream-cache-nginx-module --add-module=/nginx-build/openresty-1.11.2.2/../nginx-module-vts --with-openssl=/openssl

Système de fichiers pour le moment, car les sous-domaines traités par chaque serveur sont séparés.
Semble être complètement aléatoire lorsqu'un crash se produit, de 3 heures à 3 bons jours.
Ne pas recharger nginx atm, juste redémarrer, mais je vais essayer cela et voir si cela fonctionne aussi.
Au départ, j'utilisais 1 ouvrier, mais j'ai essayé d'augmenter ce nombre à 2 lorsque les problèmes sont survenus pour voir si cela ferait une différence.
En utilisant les modules non OpenResty suivants :

• nginx-module-vts https://github.com/vozlt/nginx-module-vts
• lua-upstream-cache-nginx-module https://github.com/cloudflare/lua-upstream-cache-nginx-module
• testcookie-nginx-module https://github.com/kyprizel/testcookie-nginx-module
  et --with-http_v2_module --with-http_secure_link_module

Je n'utilise pas d'autre Lua dans le code de configuration que ce projet.

Désolé pour le retard de suivi ! Après avoir cherché un peu plus, j'ai quelques théories sur ce qui pourrait se passer:

• Le fait que vous voyiez des erreurs "sorti au signal 9" peut indiquer que vous rencontrez des erreurs de mémoire insuffisante et que le système tue agressivement les processus : http://raspberrypi.stackexchange.com/questions/40883 /nginx-out-of-memory-kill-process
• Lorsqu'un processus se bloque ou est tué de force de cette manière, cela peut amener nginx à penser que la mémoire partagée est toujours verrouillée par le processus de travail mort. Par exemple, dans votre exemple initial, il semble que le processus de travail 501 soit tué en premier, mais il pense ensuite que la mémoire est verrouillée par le pid 501, ce qui entraîne ce blocage.
  
  
  
  • Il semble que nginx soit censé déverrouiller la mémoire partagée en cas de plantage, donc je ne sais pas exactement pourquoi cela pourrait ne pas se produire. Mais si les travailleurs sont tués avec SIGKILL (9), alors tous les paris pourraient être annulés (puisque sigkill signifie généralement tuer de force le processus et il n'y a aucune chance de nettoyer).
  
  

Alors, voyez-vous quelque chose dans vos journaux au niveau du système concernant un manque de mémoire ou un oom-killer ? Avez-vous une autre surveillance sur ces serveurs qui pourrait indiquer une croissance de la mémoire ou une fuite de mémoire dans nginx ? Je ne pense pas que nous ayons vu de fuites de mémoire dans aucune de nos installations lua-resty-auto-ssl, donc je me demande si certains des autres modules nginx pourraient également jouer un rôle (il y a cette mention d'un fuite de mémoire dans le module lua-upstream-cache-nginx).

Désolé - je voulais préciser à @GUI que le

Je dois ajouter que j'ai supprimé certains modules pour essayer de résoudre le problème, le module obsolète lua-upstream-cache-nginx-module et la vitesse de page supprimée, mais cela ne semble pas avoir aidé.

J'ai quelques lignes d'erreur supplémentaires qui peuvent être utiles, je vais essayer de les obtenir des serveurs sous peu.

@ajmgh : Je ne suis pas tout à fait certain que ce soit lié, mais je pense avoir identifié certains problèmes potentiels qui pourraient entraîner des erreurs étranges si la taille de la mémoire lua_shared_dict configurée était trop faible : https://github.com /GUI/lua-resty-auto-ssl/issues/48#issuecomment -294397379

Alors, savez-vous à peu près combien de certificats se trouvent dans votre système et quelle est la taille de lua_shared_dict auto_ssl configurée dans votre configuration nginx ? Vous pouvez également essayer de mettre à niveau vers la v0.10.6, si possible, car il y a eu quelques mises à jour depuis la 0.10.3 qui pourraient résoudre ce problème (si nous avons de la chance), ou au moins fournir une meilleure gestion des erreurs et des messages.

Je suis confronté exactement à la même erreur.
Je viens de mettre à jour lua-resty-auto-ssl vers la version 0.10.6-1 et d'augmenter lua_shared_dict auto_ssl_settings à 1000m (avant qu'il ne soit réglé sur 64k).
lua_shared_dict auto_ssl reste le même : 1000m

J'attends juste de voir si ces changements résoudront ce problème :/

@ajmgh as -tu résolu ton problème ?

@aiev auto_ssl_settings ne stocke actuellement qu'une chaîne courte ainsi qu'un booléen, donc le changer ne fera aucune différence. Les certificats sont stockés dans auto_ssl . Alors s'il vous plaît essayez d'augmenter cela à la place.

Non, la dernière mise à jour ne résout pas notre problème. J'ai augmenté la taille auto_ssl à 8M, ce qui est excessif car nous n'utilisons qu'environ 10 certificats et n'avons vu aucun changement.

# Log entries after my script detects nginx is unresponsive and force kills it
2017/05/24 13:29:15 [alert] 462#0: worker process 474 exited on signal 9
2017/05/24 13:29:15 [alert] 462#0: worker process 475 exited on signal 9
2017/05/24 13:29:15 [alert] 462#0: shared memory zone "auto_ssl" was locked by 475

J'ai rencontré le même problème à quelques reprises.
J'utilise OpenResty 1.11.2.3/4 et lua-resty-auto-ssl 0.11.0-1 de luarocks.
Lorsque ce problème apparaît, plus de 100 connexions TCP sont bloquées à l'état CLOSE_WAIT.

Nous avons également rencontré le même problème à plusieurs reprises.
version nginx : openresty/1.11.2.4
lua-resty-auto-ssl 0.11.0-1
Il existe de nombreux états CLOSE_WAIT et nginx ne peut plus répondre. Soit nous devons supprimer la connexion CLOSE_WAIT, soit redémarrer le docker pour résoudre ce problème.

@ajmgh as-tu résolu ton problème ? Nous rencontrons le même problème dans nos conteneurs openresty. Nous avons environ 1200 connexions dans l'état CLOSE_WAIT et beaucoup de fichiers déshydratés dans /tmp sur nos serveurs qui n'exécutent qu'openresty avec lua-resty-auto-ssl.

Voici notre configuration système

• Quelle version de lua-resty-auto-ssl utilisez-vous ?
  0.11.0-1
• Exécutez-vous OpenResty ou nginx avec le module lua installé manuellement ?
  openresty
• Quelles versions d'OpenResty ou de nginx+lua utilisez-vous ?
  openresty 1.11.2.4
• Quel mécanisme de stockage utilisez-vous avec lua-resty-auto-ssl (Redis, système de fichiers, autre chose) ?
  redis
• À quelle fréquence les choses se bloquent-elles ? Cela semble-t-il se produire uniquement lorsque de nouveaux certificats sont enregistrés ou que des renouvellements ont lieu, ou est-ce apparemment aléatoire ?
  Cela a l'air très aléatoire. Cela s'est passé hier et a entraîné un temps d'arrêt de 30 minutes dans notre système. La fois précédente, c'était il y a 2 mois.
• Rechargez-vous nginx (en envoyant un SIGHUP au processus maître et en générant de nouveaux travailleurs au lieu de redémarrer complètement le processus maître) ?
  nous venons de remplacer tous les conteneurs docker
• Combien de nœuds de calcul nginx avez-vous en cours d'exécution (paramètre worker_processes dans la configuration de nginx) ?
  2
• Avez-vous d'autres plugins nginx installés (au-delà de ceux fournis par défaut avec OpenResty si vous êtes sur OpenResty) ?
  non, lua-resty-auto-ssl est le seul plugin que nous avons installé

@ronail Non, mais nous avons ajouté des serveurs supplémentaires sur notre roundrobin ainsi qu'un script de redémarrage automatisé lorsque ce problème se produit, nous l'avons donc fortement atténué.

Est-ce que tous les autres utilisateurs de Docker rencontrent ce bogue ? Peut-être que c'est quelque chose de vraiment bizarre qui se passe avec un mélange de Lua/OpenResty et Docker.

Je n'utilise pas Docker et je suis confronté au même problème.

Je suppose que c'est un problème lorsque déshydraté essaie d'émettre le certificat.

Je rencontre également un problème similaire, obligé de forcer jenkins à redémarrer OpenResty toutes les 30 minutes (Crashes toutes les heures environ constamment...)

J'ai défini des limites de mémoire élevées, mais j'ai remarqué que j'obtiens un bon nombre de limites de débit pour les authentifications échouées sur LetsEncrypt si cela aide?

Nous avons été confrontés au même problème hier et avons trouvé ces rapports (#43, #136) qui ne contenaient aucun indicateur quant à la cause possible. Nous n'avons pas pu reproduire le problème sur notre système de test, nous avons donc été obligés de déboguer sur celui de production. « Heureusement », les blocages étaient assez fréquents, nous avons donc pu parcourir rapidement nos méthodes de débogage. Premièrement, il n'y avait qu'une strace -fp $pid sur tous les processus nginx, et cela a révélé que tous attendaient un futex() - cohérent avec le fait que l'un des pid détenait toujours un verrou sur un shdict. Ensuite, j'ai ajouté un vidage de la trace arrière gdb de chaque processus, et après avoir ajouté des symboles de débogage à l'image, il est devenu clair que le problème se situe sur le chemin de code suivant :

#3  0x00007f8f4ea50219 in ngx_shmtx_lock (mtx=0x7f8f31a0c068) at src/core/ngx_shmtx.c:111
#4  0x00007f8f4eb7afbe in ngx_http_lua_shdict_set_helper (L=0x418257a0, flags=0) at ../ngx_lua-0.10.13/src/ngx_http_lua_shdict.c:1016
#5  0x00007f8f4eb7a4a4 in ngx_http_lua_shdict_delete (L=0x418257a0) at ../ngx_lua-0.10.13/src/ngx_http_lua_shdict.c:632
#6  0x00007f8f4debd2f3 in lj_BC_FUNCC () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#7  0x00007f8f4dec0b9f in gc_call_finalizer (g=0x418063b8, L=0x418257a0, mo=0x7ffc7592da00, o=0x40e11948) at lj_gc.c:475
#8  0x00007f8f4dec0e2b in gc_finalize (L=0x418257a0) at lj_gc.c:509
#9  0x00007f8f4dec15d9 in gc_onestep (L=0x418257a0) at lj_gc.c:659
#10 0x00007f8f4dec16ef in lj_gc_step (L=0x418257a0) at lj_gc.c:689
#11 0x00007f8f4ded8c3d in lua_pushlstring (L=0x418257a0, str=0x7f8f330a6066 "0\202\002\v\n\001", len=527) at lj_api.c:639
#12 0x00007f8f4eb7a225 in ngx_http_lua_shdict_get_helper (L=0x418257a0, get_stale=0) at ../ngx_lua-0.10.13/src/ngx_http_lua_shdict.c:538
#13 0x00007f8f4eb79eb6 in ngx_http_lua_shdict_get (L=0x418257a0) at ../ngx_lua-0.10.13/src/ngx_http_lua_shdict.c:419

Après un rapide coup d'œil à ngx_http_lua_shdict_get_helper(), la cause première du problème devient claire : le shdict est verrouillé et lua_pushlstring appelle parfois le ramasse-miettes, qui peut vouloir supprimer des éléments du même shdict, provoquant le blocage.

Ma solution rapide et sale était la suivante (c'est tellement moche que je ne vais pas publier de patch);

    case SHDICT_TSTRING:
{
int len = value.len;
char *tmp = malloc(len);
if(!tmp) {
    ngx_log_error(NGX_LOG_ERR, ctx->log, 0, "dict get: malloc: out of memory");
    return luaL_error(L, "out of memory");
}
ngx_memcpy(tmp, value.data, value.len);
ngx_shmtx_unlock(&ctx->shpool->mutex);
lua_pushlstring(L, tmp, len);
free(tmp);
}
        break;

Jusqu'à présent, cela fonctionne parfaitement - quelqu'un avec plus de perspicacité dans le fonctionnement interne du système pourrait vouloir produire une meilleure solution.

Fait intéressant, c'est un fait connu !
https://github.com/openresty/lua-nginx-module/issues/1207#issuecomment -350745592

c'est intéressant en effet. selon le problème que vous avez mentionné, l'utilisation de lua-resty-core résoudrait le problème, et selon sa documentation, il est automatiquement chargé depuis openresty 1.15.8.1, donc ce bogue a été résolu en silence dans cette version. nous mettrons à niveau notre proxy et ferons un rapport.

on dirait que cela fonctionne parfaitement - en supposant que la condition qui l'a fait se bloquer auparavant persiste, je dirais que le bogue a été corrigé.

Je viens de tomber dessus, après plus de 3 ans de fonctionnement sans heurts.

Également rencontré ce problème en production - merci @koszik et al. Juste pour confirmer, pour résoudre ce problème :

Mettre à jour OpenResty vers >1.15.8.1

Cela semble si pernicieux que cela pourrait valoir la peine de publier bientôt f66bb61f11a654f66d35dd793ceaf0293d9c0f46, ou au moins de mettre à jour la documentation selon les exigences, plutôt qu'une recommandation.