Puncte:0

Intermitent „Adresa deja utilizată: AH00072: make_sock: nu s-a putut lega la adresa” pe portul 80

drapel ng

Ne confruntăm cu „Adresa deja în uz: AH00072: make_sock: nu s-a putut lega la adresa” intermitentă la eșecurile portului 80 de pe serverele noastre. M-am uitat la alte răspunsuri și ele se bazează în mare parte pe faptul că este un eșec constant și un ASCULTARE fiind definit de două ori, ceea ce nu este problema noastră.

Problema noastră apare la scurt timp după pornirea instanței în care „sudo service httpd restart” serviciul pentru a încărca o nouă configurație pe care o stabilim în funcție de mediu.

Am putut să prind problema în direct și să văd că a fost de fapt httpd care este legat. Problema pare să fie că Apache/httpd este blocat și nu poate reporni, iar apoi repornirea nu așteaptă.

Folosim Apache 2.4 pe Amazon Linux 1.

introduceți descrierea imaginii aici

Michael Hampton avatar
drapel cz
Amazon Linux 1? Asta e _vechi_. Mai este suportat asta? Credeam că a fost renunțat cu ani în urmă. Nu sunt sigur cât de departe vei putea ajunge cu asta.
drapel ng
Da, acest lucru este adevărat, și-a pierdut sprijinul recent. Lucrăm la migrarea către containere pe K8-uri, dar mai sunt câteva luni, iar până atunci încă mai caut o soluție la acest lucru. Acesta afectează doar CD-ul nostru de mediu inferior chiar acum, dar ne provoacă eșecuri aleatorii chiar acum.
Michael Hampton avatar
drapel cz
Vă sugerez să implementați configurația dvs. _înainte_ de a porni httpd.
drapel ng
Cred că avem o constrângere acolo asupra sistemului nostru de implementare (bazat pe Ansible), dar îl voi arunca o privire și voi vedea dacă îl pot refactoriza. Sună ca și cum ar fi o soluție solidă și ar rezolva asta. Mulțumesc Michael pentru această sugestie!
drapel ng
legate de: https://askubuntu.com/questions/500977/ah00015-unable-to-open-logs-action-start-failed-in-ubuntu-14-04
Puncte:1
drapel cn

Există două motive principale pentru a obține un Adresă deja utilizată eroare:

  1. Un alt server folosește acel IP:port

    În acest caz, încercați să porniți două servicii și ambele doresc aceeași combo adresă și port, ceea ce nu este posibil. Un singur serviciu poate asculta pe un anumit port. Se pare că nu ești în această situație.

  2. Același server este repornit prea repede

    În mod implicit, nucleul va menține un combo IP:port pentru câteva secunde (posibil un minut) înainte de a permite unui serviciu să le folosească din nou. Acest lucru este pentru a vă asigura că toți clienții au avut șansa de a primi un semnal de închidere adecvat. De asemenea, din motive de securitate, puteți ajunge să primiți pachete care se așteptau să fie trimise la vechea conexiune. Asta poate cauza probleme.

    Se pare că asta ar fi situația ta, deși am crezut că Apache va folosi automat SO_REUSEADDR steag. Modul de a remedia acest lucru este să te uiți la implementarea repornirii și să adaugi un somn între comenzile de oprire și pornire. Este destul de ușor dacă utilizați un script init:

     [...croitor...]
         ;;
     repornire)
         log_daemon_msg „Se repornește $DESC” „$NAME”
         do_stop opriți
         cazul "$?" în
                 0|1)
                         sleep 12 # <<-- sleep înainte de a reporni
                         do_start
                         cazul "$?" în
     [...croitor...]
    

    Cu systemd, ar trebui să editați fișierul .service și să adăugați un sleep înainte de a porni serverul apache2.

     ExecStart=sleep 20 && /usr/sbin/apache2
    

Ordinea dvs. de inițializare poate fi, de asemenea, cauza problemei (dacă trebuie să începeți, schimbați ceva și apoi reporniți apache2 pe o pornire; acestea fiind spuse, este probabil important să puteți reporni apache2 în orice moment).

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.