När en webbplats slutar svara eller en server börjar få ont om diskutrymme behöver du ofta hitta rätt kommando snabbt. En linuxkommandon-guide kan hjälpa dig med det, men kommandon som fungerar på Ubuntu behöver inte finnas eller bete sig likadant på varje distribution.
Kommandon som hjälper dig att hitta, felsöka och agera
- Hitta rätt plats: använd
pwd,ls -laochcd. - Undersök först: kombinera
df -hmeddu -shnär diskutrymmet tar slut. - Felsök tjänster:
systemctl statusvisar status ochjournalctlvisar loggar på system med systemd. - Var försiktig med ändringar: kontrollera sökvägen före
rm,chmodoch kommandon medsudo.
Hitta rätt katalog innan du ändrar något
Ett felaktigt filkommando blir snabbt dyrt om du kör det från fel katalog. Börja med pwd för att se var du är, och använd ls -la för att visa även dolda filer och detaljer om objekt i katalogen.
Med cd /sökväg byter du katalog, medan cd .. går en nivå upp. Ska du skapa en katalogstruktur där mellanliggande kataloger kanske saknas, fungerar mkdir -p projekt/loggar. För att läsa en stor loggfil utan att fylla terminalen passar less fil.log; avsluta med tangenten q.
För filhantering är cp kopiering, mv flytt eller namnbyte och rm borttagning. Jag tycker att det är klokt att granska sökvägen en extra gång före borttagning, särskilt när ett kommando innehåller -r eller -f.
Sök efter rätt fil eller felmeddelande
När filnamnet är okänt men du vet vad du letar efter kan find söka i katalogträdet. Exempelvis listar find . -type f -name "*.log" loggfiler under den aktuella katalogen. Citattecknen hindrar skalet från att expandera stjärnan innan find får mönstret.
För att hitta text i filer använder du grep. Kommandot grep -n "timeout" app.log visar rader med ordet och deras radnummer; med grep -R "timeout" ./config söker du rekursivt i en katalog. Behöver du se början eller slutet av en fil är head -n 20 fil.log och tail -n 50 fil.log snabba val.
Vid felsökning i realtid kan tail -f fil.log visa nya rader när de skrivs. Tryck Ctrl+C för att avsluta visningen utan att stoppa processen som skapar loggen.
Skilj på full disk och stora kataloger
En server kan rapportera fullt filsystem även när katalogen du tittar på inte verkar särskilt stor. Det beror ofta på att df visar användningen på monterade filsystem, medan du summerar utrymmet som filer och kataloger tar upp.
| Situation | Trolig förklaring | Nästa steg |
|---|---|---|
df -h visar nästan fullt |
Det monterade filsystemet har lite ledigt utrymme. | Kör du -xhd1 /sökväg för att jämföra kataloger på samma filsystem, om din du-version stöder flaggorna. |
du hittar inte stora filer trots fullt utrymme |
En process kan fortfarande hålla en borttagen fil öppen. | Kontrollera processer med verktyg som lsof, om det finns installerat, innan du startar om tjänster. |
| En katalog verkar stor men disken har plats | Katalogen kan ligga på ett annat monterat filsystem. | Jämför sökvägen med utdata från df -h och undersök rätt monteringspunkt. |
Flaggorna för du kan skilja sig mellan system. Om kommandot ger ett fel, kontrollera du --help eller den lokala manualsidan i stället för att anta att alla Linuxdistributioner har exakt samma verktygsversion.
Kontrollera processer och tjänster innan omstart
En tjänst som verkar ha hängt sig behöver inte startas om på chans. Börja med ps aux för en processlista eller pgrep -a namn för att söka efter processer med ett visst namn. top visar processaktivitet löpande; avsluta med q.
På system som använder systemd visar systemctl status tjänst om en tjänst är aktiv och ger ofta en ledtråd om senaste fel. Med journalctl -u tjänst -n 100 --no-pager kan du läsa de senaste loggraderna för den enheten utan att öppna en interaktiv vy.
Om du behöver följa nya logghändelser i realtid använder du journalctl -u tjänst -f. systemd-dokumentationen för systemctl beskriver tjänstehanteringen, medan manualen för journalctl förklarar filtrering av loggar. Kommandona gäller inte system som använder en annan init- och logglösning.
Undvik falskt grönt resultat i kommandokedjor
En pipeline kan se lyckad ut trots att ett tidigare kommando misslyckades. I Bash blir statuskoden som standard statusen från det sista kommandot i kedjan, så kommando1 | grep något kan ge ett missvisande resultat om kommando1 fallerar men grep ändå avslutas normalt.
I ett Bash-skript gör set -o pipefail att pipelinen rapporterar fel om ett kommando i kedjan misslyckas. Det är särskilt användbart när resultatet går vidare till ett distributions- eller backupsteg. GNU Bash Reference Manual beskriver hur statuskoden ändras, och Ubuntu Server-dokumentationen samlar grundsyntax för omdirigeringar, pipes och kommandokedjor.
Behöver du köra nästa kommando bara om det första lyckas, använd cmd1 && cmd2. Med cmd1 ; cmd2 körs det andra kommandot oavsett hur det första avslutades. Den skillnaden kan avgöra om ett distributionsskript stannar vid ett fel eller fortsätter ändå.
Ändra rättigheter utan att öppna för mycket
Kommandot chmod ändrar filrättigheter och chown ändrar ägare eller grupp. För en skriptfil kan chmod u+x deploy.sh ge ägaren körbehörighet utan att samtidigt göra filen körbar för alla användare.
Talformen chmod 755 fil ger ägaren läs-, skriv- och körbehörighet, medan gruppen och andra får läs- och körbehörighet. Den passar inte automatiskt för alla filer: en konfigurationsfil med hemligheter bör normalt inte göras läsbar för alla. Kontrollera först utfallet med ls -l fil.
Använd sudo endast när kommandot faktiskt behöver administratörsrättigheter. Jag tycker att en tydlig kontroll före sudo rm eller en bred rättighetsändring är bättre än att försöka återställa filer efteråt.
Låt terminalen visa nästa steg
Du behöver inte memorera varje flagga. man kommando öppnar manualsidan och kommando --help brukar ge en kortare översikt; i man kan du söka med /ord och avsluta med q. För Bash-specifika funktioner är GNU Bash Reference Manual rätt dokumentation, medan GNU Coreutils-manualen täcker många vanliga fil- och systemkommandon.
När ett problem dyker upp, börja med att läsa status och loggar, kontrollera sökvägen och kör sedan den minsta ändring som kan lösa felet. Den ordningen minskar risken att en snabb kommandoradslösning skapar ett större driftproblem.