Zjutraj sem prejel nadzorno e-pošto od Baidu in ugotovil, da spletne strani ni mogoče odpreti, in takrat ni bilo razloga za skrb, ker spletne strani ni bilo mogoče odpreti, možni razlogi pa so bili naslednji:
1: Strežnik je v zaostanku
2: Strežnik je bil napaden
Takrat nisem posvečal preveč pozornosti, umil sem si zobe in obraz, da sem šel v službo, nato pa sem prižgal računalnik, da sem obiskal spletno stran Alibaba Cloud, in da preverim, ali je bil napad ali prepozno, sem ugotovil, da ni nobenih zaostankov ali napada.
Nato sem se prek SSH povezal s strežnikom, ga ponovno zagnal, počakal 5 minut in ugotovil, da strežnika ni mogoče povezati, ter da stvari niso tako preproste!!
Ker zunanje omrežne povezave ni mogoče povezati, uporabimo VNC za povezavo, torej se prijavimo v konzolo spletne strani Alibaba Cloud, da vzpostavimo oddaljeno povezavo, ki je spletna različica oddaljene povezave, in intranet je treba prehoditi, nato pa najti črn zaslon!!
Stvari postajajo vse manj preproste, zdi se mi, da je z Alibaba Cloud nekaj narobe??? (Ker se nisem dotaknil nobene operacije na strežniku) Najprej sem oddal delovni nalog, razložil situacijo in potem šel na delo...
V podzemni železnici se prijavite v aplikacijo Alibaba Cloud, kadarkoli pozorno spremljajte povratne informacije o delovnih nalogih, nenadoma pa se na strani aplikacije pojavi obvestilo, povezava: https://help.aliyun.com/noticelist/articleid/20651342.html
(Obnovljeno) 12. novembra 2017 po pekinškem času je bil napovedan telekomunikacijski sever-jug medsebojni obisk
Osebno mislim, da je to težava na strani Alibaba Clouda in ali je povzročena z uradnimi Alibaba Cloud storitvami ali vmesniki, ki se še niso vrnili v normalno stanje????
Po povratnih informacijah glede zahtevka za Alibaba Cloud sem ugotovil, da lahko uporabljam ssh do strežnika, vendar po ponovnem zagonu nisem mogel vzpostaviti povezave s strežnikom, zato sem večkrat komuniciral s kartico, telefon pa je bil dolgo komuniciran.
Tudi če je mogoče povezati SSH, nekatere storitve strežnika ne delujejo normalno, na primer mysql strežnik, ki se ne zažene normalno...
Na koncu vstopnica odgovori takole:
Gostitelj oddaljene povezave in okrevanja testiraš.
Trenutna težava: V rc.local je nenavaden zagonski element, ki povzroči, da sistem po zagonu ne zažene popolnega zagona in kartica je masterirana, kot je prikazano v Prilogi 1.
Po komentiranju vsebine na rc.local se bo vrnila v normalno stanje, prosimo, preverite, ali so v storitvi kakšne nepravilnosti.
Po obdelavi odprite vsebino v rc.local.
Zdi se mi, da nekaj razumem, in sicer da se nekatere storitve strežnika niso zagnale normalno, nato pa sem ročno zagnal mysql in ugotovil, da ga ni mogoče zagnati v 30 sekundah, in ugotovil sem, da stvari niso tako preproste。。。。。
Po svoji intuiciji sem pritisnil ukaz df -h, da preverim porabo prostora na trdem disku, in ugotovil, da je prostor zasedel 100 % prostora!!!
Na koncu poišči top 10 datotek, ki zavzemajo prostor na disku, in poišči datoteko, večjo od 12g, ki je logarinska datoteka nginx,
Moral bi bitiProstor na disku je poln, kar povzroči okvaroSpremenite konfiguracijske parametre nginx dnevnikov, nato izbrišite nginx dnevnike, ponovno zaženite strežnik in nekateri se bodo vrnili v normalno stanje.
Konfiguracija NGINX ima jamo.Ko strežniški segment ne določa access_log in v http segmentu ni določenih access_log parametrov, se privzeto zapiše v datoteko logs/access.log, torej privzeto vrednost access_log "logs/access.log", in je dostopni dnevnik vseh strežnikov。
|
Objavljeno na 13. 11. 2017 12:16:27
|
|
|
|
Najemodajalec|
Objavljeno na 13. 11. 2017 12:22:36
|
