Reggel kaptam egy megfigyelő e-mailt Baidutól, és azt találtam, hogy a weboldalt nem lehet megnyitni, és akkor nem volt miért aggódni, mert a weboldalt nem lehetett megnyitni, és a lehetséges okok a következők voltak:
1: A szerver elmarad
2: A szervert megtámadták
Ekkor nem figyeltem túl sokat, fogat mostam, és megmostam az arcom, hogy dolgozzak, majd bekapcsoltam a számítógépet, hogy meglátogassam az Alibaba Cloud weboldalát, és megnéztem, hogy megtámadták-e vagy késedelmes volt-e, rájöttem, hogy nincs késés vagy támadás.
Ezután az ssh csatlakozott a szerverhez, újraindítottam, 5 percet vártam, és azt tapasztaltam, hogy a szerver nem volt csatlakoztatva, és a dolgok nem is olyan egyszerűek!!
Mivel a külső hálózati kapcsolatot nem lehet csatlakoztatni, használjunk VNC-t a csatlakozáshoz, vagyis jelentkezzünk be az Alibaba Cloud weboldal konzoljára, hogy legyen távoli kapcsolat, ami a távoli kapcsolat webes verziója, és az intranetet kell végigjárni, majd megtaláljuk a fekete képernyőt!!
Egyre egyszerűbbek a dolgok, úgy érzem, valami baj lenne az Alibaba Clouddal??? (Mert nem érintettem semmilyen műveletet a szerveren) Először beadtam egy munkamegrendelést, elmagyaráztam a helyzetet, aztán munkához mentem...
A metrón, jelentkezz be az Alibaba Cloud APP-ba, figyelj a munkarendelési visszajelzésekre bármikor, amikor hirtelen megjelenik egy bejelentés, link: https://help.aliyun.com/noticelist/articleid/20651342.html
(Visszaállítva) 2017. november 12-én, pekingi idő szerint bejelentették a távközlési észak-déli kölcsönös látogatást
Személy szerint szerintem ez az Alibaba Cloud oldalán van probléma, és akár hivatalos Alibaba Cloud szolgáltatásokból vagy nem visszatért normál felületekből fakad-e????
Az Alibaba Cloud jegyvisszajelzése után rájöttem, hogy az ssh-t használhatom a szerverhez, de újraindítás után nem tudtam csatlakozni a szerverhez, és ismételten kommunikáltam a jegygel, és a telefon hosszú ideig kommunikált.
Még ha az SSH csatlakoztatható is, a szerver egyes szolgáltatásai nem működnek normálisan, például a mysql szerver, amely nem indul normálisan...
Végül a jegy így válaszol:
A távoli kapcsolat és a helyreállítás mellett teszteled a letöltést.
Jelenlegi probléma: Az rc.local-ban rendellenes indítási elem van beállítva, ami miatt a rendszer nem indul teljes indítás után, és a kártya masterelve van, ahogy az 1. mellékletben látható.
Miután kommentelte az rc.local-ban a tartalmat, visszatér a normális állapotba, kérjük, ellenőrizze, van-e bármilyen rendellenesség a szolgáltatásban.
A feldolgozás után nyissa meg a tartalmat az rc.local oldalon.
Úgy tűnik, értek valamit: az az, hogy a szerver egyes szolgáltatásai nem indultak normálisan, aztán manuálisan elindítottam a mysql-t, és azt tapasztaltam, hogy 30 másodperc alatt nem lehet elindítani, és nem is ilyen egyszerű。。。。。
A személyes megérzésem alapján megnyomtam a df -h parancsot, hogy ellenőrizzem a merevlemez helyhasználatát, és azt találtam, hogy van egy hely, ami a hely 100%-át foglalta el!!!
Végül keresd meg a top 10 fájlt, amely elfoglal a lemezhelyet, és keress egy fájlt, amely több mint 12g volt, ami egy nginx naplófájlja,
KelleneA tárchely megtelt, ami meghibásodást eredményezMódosítsd az nginx naplók konfigurációs paramétereit, majd töröld az nginx naplófájlokat, indítsd újra a szervert, és néhány visszatér a normál állapotba.
A nginx konfigurációban van egy gödör.Ha a szerverszegmens nem határoz meg access_log, és a http szegmensben nincs access_log paraméter, akkor alapértelmezés szerint a logs/access.log fájlba íródik, vagyis az alapértelmezett érték access_log "logs/access.log", és ez az összes szerver hozzáférési naplója。
|
Közzétéve 2017. 11. 13. 12:16:27
|
|
|
|
Háziúr|
Közzétéve 2017. 11. 13. 12:22:36
|
