Feilsøking — når terminalen sier nei | Linux-kommandoreferansen

På denne siden

Alt i terminalkapitlene fungerer, helt til den dagen det ikke gjør det. En kommando forsvinner, en disk fylles, en tjeneste nekter å starte. Denne guiden handler om å lese de øyeblikkene i stedet for å kjempe mot dem: seks feilmeldinger, hver sporet til en årsak langs den korteste kommandoveien som skiller kandidatene.

Guiden står på egne ben, men lener seg på kapitlene for dybden. Alt her er verifisert på Ubuntu 26.04-, Fedora 44- og Arch-containere, og der distroene skiller lag, sier teksten ifra.

Les feilen, og krymp problemet

Hver feil starter som tekst på en skjerm, og teksten er som regel ærlig. Vanen som skiller en femminutters fiks fra en kveld med gjetting, er tre spørsmål, stilt i rekkefølge:

Hva sto det, nøyaktig? Ikke «det gikk i stykker». De nøyaktige ordene, kopiert ut.
Hva har endret seg siden det fungerte? En oppdatering, en flyttet fil, en ny disk, en full en.
Hva er den minste testen som fortsatt feiler? Én kommando i stedet for en hel arbeidsflyt, én fil i stedet for en mappe.

Det tredje spørsmålet er arbeidshesten. «Internett er nede» blir til «kan jeg nå denne adressen», som blir til «slår noen navn opp i det hele tatt», og hver krymping finner enten det ødelagte laget eller eliminerer det. Symptomseksjonene nedenfor er den krympingen, skrevet ut.

En frossen terminal har sin egen lille aritmetikk. Ctrl+C avbryter en kjørende kommando — som oftest en ping som glemte å stoppe, og det er grunnen til at Nettverk lærer bort ping -c, slik at kommandoen avslutter av seg selv. Og ble skjermen stille rett etter Ctrl+S, har ingenting krasjet: Ctrl+S setter utdataen fra terminalen på pause, og Ctrl+Q setter den i gang igjen.

Kommandoene her er bevisst korte, fordi hver av dem har et kapittel som lærer den skikkelig bort — Filnavigering og Filer og mapper først blant dem, deretter rettigheter, prosesser, pakker, nettverk, disker, skallet, og tjenester og logger. Seks symptomseksjoner følger, pluss en loggseksjon og en full gjennomgang til slutt.

«command not found»

$ xyzzy
bash: xyzzy: command not found
$ echo $?
127

Bash har aldri spilt eventyrspillene som gjorde xyzzy til et magisk ord, så bash konstaterer bare fraværet. Exit-kode 127 er den formelle erklæringen om at ingenting med dette navnet finnes, og exit-kode-seksjonen i bash-guiden forklarer hele null-mot-ikke-null-saken. Ubuntu-skrivebordsinstallasjoner legger ofte ved et pakkehint til denne feilen. Det er et bekvemmelighetslag, og meldingen betyr det samme uten den.

Tre ulike årsaker produserer denne ene meldingen, og spørsmålene som krymper problemet, sorterer dem ut.

Det kan være en skrivefeil

type er den innebygde detektiven. Den svarer likt på ekte kommandoer, skallets innebygde og ren tull:

$ type xyzzy
bash: type: xyzzy: not found
$ type cd
cd is a shell builtin
$ type ls
ls is /usr/bin/ls

which gjør den smalere jobben med å skrive ut bare stien. Stol mer på at en sti kom tilbake enn på selve stien: i Ubuntu-containeren vår svarte which ls /usr/bin/ls, og på Fedora 44 og Arch svarte den /usr/sbin/ls. Samme program, ulik parkeringsplass per distro.

Det kan mangle

Hver distro kan fortelle deg hvem som leverer et program. Samme spørsmål, tre dialekter:

$ apt search traceroute
$ dnf provides '*/traceroute'
$ pacman -Fy
$ pacman -F traceroute
extra/traceroute 2.1.6-1, usr/bin/traceroute

apt search lister matchende pakker etter navn på Debian og Ubuntu, og Pakkebehandling dekker den typen søk. Å finne hvilken pakke som eier en fil, er den mindre kjente halvparten av jobben, og kapitlene overlater den til denne guiden: Fedoras dnf provides tar imot et stiemønster og navngir pakken som eier filen. Arch har en filedatabase som pacman -Fy oppdaterer, før pacman -F traceroute skriver ut linjen over.

Det kan ligge i feil mappe

Skript er den klassiske fellen. Bash leter etter nakne navn langs PATH, aldri i mappen du står i, så skriptet ved siden av deg er usynlig til du peker på det:

$ script.sh
bash: script.sh: command not found
$ ./script.sh
hello-from-vfyscript

Prefikset ./ betyr «her, eksplisitt». For et program installert på et uvanlig sted gjelder samme logikk for PATH selv:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ PATH=$PATH:/opt/vfytools

Det er Ubuntu sin innloggingsstandard, med Fedora og Arch som hver legger sine egne oppføringer i kantene. Tilordningen leses fra venstre til høyre: den gamle PATH, et kolon, den nye mappen, og etterpå kjører verktøy i /opt/vfytools på nakent navn. Shell-grunnleggende presenterer $PATH blant miljøvariablene.

Et alias kan skape den samme forvirringen, inne fra skallet selv: virker en kommando for en kollega, men ikke for deg, kan det være et alias i oppsettet deres, og type NAVN sier ifra. Samme kapittel lærer bort aliaser med det kjente ll-eksempelet.

Enda en dobbeltgjenger til slutt. Hadde bash svart bash: ./script.sh: Permission denied, gjaldt ingenting i denne seksjonen — det er neste feil, og nybegynnere blander de to sammen i årevis.

«Permission denied»

Her er dobbeltgjengeren i full lengde:

$ ./script.sh
bash: ./script.sh: Permission denied
$ echo $?
126

Exit-koden skiller de to: 127 betydde «ingen slik kommando», 126 betyr «funnet, men ikke tillatt å kjøre». Filen finnes og er lesbar. Utføre-biten er ikke satt, og ett chmod +x script.sh senere har rettighetsstrengen endret seg fra -rw-r--r-- til -rwxr-xr-x, og skriptet kjører. (Du kan se et etterfølgende tegn etter disse bitene — + på Ubuntu når tilgangslister er festet, . på Fedora for SELinux-kontekster. Ignorer det for dette formålet.) Rettigheter og eierskap lærer bort tallformen og den symbolske formen.

Mapper kompliserer bildet, fordi deres to viktige biter gjør ulike jobber: r lar deg liste navn, x lar deg gå inn. «Ingen rettigheter, ingen tilgang» er oppsummeringen alle lærer, og så kommer den verifiserte splittelsen. Begge halvdelene er én chmod unna på en engangsmappe: chmod 644 somedir er r-uten-x-tilfellet. Med r, men uten x:

$ cd /tmp/vfydir
bash: cd: /tmp/vfydir: Permission denied
$ ls /tmp/vfydir
vfyfile
$ ls -l /tmp/vfydir
ls: cannot access '/tmp/vfydir/vfyfile': Permission denied

Du kan lese navnene på døra, men ikke gå inn. Vanlig ls lister dem, ls -l må åpne hver fil for detaljene sine og feiler per oppføring. Speiltilfellet (chmod 311 somedir tar r bort og lar x ligge igjen) snur oppførselen: cd seiler rett igjennom mens listingen dør:

ls: cannot open directory '/tmp/vfydir': Permission denied

De to bitene er to spørsmål: får jeg lest listen, og får jeg forbi døra.

Den siste rettighetsfeilen handler ikke om biter i det hele tatt, men om identitet. Før du strekker deg etter sudo, sjekk hvem skallet tror du er:

$ id
uid=1000(user) gid=1000(user) groups=1000(user),27(sudo)
$ chown alice /tmp/vfyown.txt
chown: changing ownership of '/tmp/vfyown.txt': Operation not permitted

Den chown-feilen er hvordan «du mangler myndighet» ser ut når det sies rett frem — eierskapsendringer krever root, og derfor finnes sudo chown. (Ubuntus versjon av feilen legger til (os error 1).) Mange rettighetsfeiler viser seg å være feilbrukerfeiler, og id koster ingenting å kjøre.

«No space left on device»

Kjernen forhandler ikke om diskplass. Feilen kommer ved enhver skriving, fra ethvert program, og det første spørsmålet er om den er bokstavelig sann:

$ df -h /mnt/vfyfs | tail -1
tmpfs            64M   64M     0 100% /mnt/vfyfs

(Fra testriggen: en 64M tmpfs, RAM som later som den er en disk, fylt med vilje.) df -h rapporterer byte. Når Use% viser 100, er neste spørsmål hvem som spiste dem:

$ du -xh --max-depth=1 / 2>/dev/null | sort -rh | head -5
1.9G	/
1.3G	/usr
536M	/var
4.8M	/etc
64K	/root

Les utdataen i deler. du måler per mappe, sort -rh sorterer de menneskelesbare størrelsene størst først (paret Disker og lagring lærer bort), og head -5 beholder de fem største mistenkte. -x låser du til ett filsystem, og 2>/dev/null kaster vekk rettighetsklagene om andre folks mapper.

Noen ganger sier df -h at det er god plass, og likevel feiler skrivingene. Da er filsystemets andre budsjett syndebukken: hver fil trenger en inode, en oppføring i innholdsfortegnelsen, og inoder kan gå tom mens byte gjenstår:

$ df -i /mnt/vfyino | tail -1
tmpfs             100   100     0  100% /mnt/vfyino
$ touch /mnt/vfyino/overflow
touch: cannot touch '/mnt/vfyino/overflow': No space left on device

Samme feiltekst, motsatt årsak — på dette filsystemet viste df -h 0% brukt. Millioner av bittesmå filer, typen som hoper seg opp i cachemapper, bruker opp inoder uten å flytte bytetelleren stort, og df -i skiller de to manglene fra hverandre.

På en full root-disk er systemd-journalen en hyppig syndebukk, og den krymper seg på forespørsel:

$ journalctl --disk-usage
Archived and active journals take up 40M in the file system.

(40M i Ubuntu-containeren vår, 32M på Fedora, 16M på Arch — tallet ditt blir annerledes.) Å krympe den er root-territorium:

$ sudo journalctl --vacuum-size=100M
Deleted archived journal /var/log/journal/…/system@….journal (70.1M).
Vacuuming done, freed 70.1M of archived journals from /var/log/journal/….

(De 70,1M kom fra en testrigg som hadde vokst godt over taket før vacuum kjørte — en normalt begrenset journal frigjør mindre. Tallene dine blir annerledes; mekanismen er den samme.)

Tre ærlige begrensninger, alle verifisert. Bare arkiverte journaler blir slettet; den aktive filen fortsetter å samle. Journalen krymper aldri til null. Og under grensen skriver kommandoen ut freed 0B og endrer ingenting.

Vil du gjenskape dette bevisst, er det foretrukne fyllet head -c 100M /dev/zero > filler.bin. -c-flagget teller byte, og suffiksene er potenser av 1024 — 1M er 1048576 byte, 1G er 1073741824. Gjennomgangen til slutt i guiden bruker den.

«Nettverket er nede»

Et nettverk er en stakk av spørsmål, og «internett er ødelagt» er for stort til å svare på. Gå gjennom dem i rekkefølge, fra maskinen og utover. Nettverk lærer hver kommando i sin helhet — her blir de til en halvering.

Er TCP/IP-maskineriet i live i det hele tatt? ping -c 1 localhost bør ende i 1 packets transmitted, 1 received, 0% packet loss, time 0ms. Dette rører aldri en kabel — feiler det her, er problemet inne i maskinen.
Har grensesnittet en adresse? ip addr: se etter nettverksenheten din og en inet-linje under den.
Finnes det en rute ut? ip route bør inneholde en linje som starter med default:
```
default via 10.40.33.1 dev eth0 proto dhcp src 10.40.33.227 metric 100
```
Standardlinjen navngir gatewayen (via) og enheten den bor på. Enhetsnavn kan variere fra maskin til maskin. Vår sa tilfeldigvis eth0 overalt, men din kan hete enp3s0, wlan0, hva som helst.
Kan vi nå verden med rå adresse? ping -c 3 1.1.1.1 som ender i 3 packets transmitted, 3 received, 0% packet loss, time 2002ms betyr at pakker går ut og kommer tilbake.
Slår navn opp? Her skjer det klassiske skillet:
```
$ dig example.com +short
104.20.23.154
172.66.147.243
```
Virket ping med rå adresse, men feiler navnet med
```
ping: example.com: Temporary failure in name resolution
```
da er nettverket i orden, og DNS er pasienten — den feilen avslutter med kode 2. dig @1.1.1.1 example.com +short spør en bestemt resolver i stedet for systemstandard, og skiller «vår resolver er ødelagt» fra «den oppstrøms er det». Finnes ikke dig på maskinen din, har ping-skillet over allerede navngitt laget.
Lytter det noe? For «tjenesten er utilgjengelig»-klager viser ss -tlnp hvem som venter på hvilken adresse:
```
LISTEN 0      5            0.0.0.0:8822      0.0.0.0:*    users:(("python3",pid=88555,fd=3))
LISTEN 0      5          127.0.0.1:8811      0.0.0.0:*    users:(("python3",pid=88554,fd=3))
```
To testservere, ett mysterium løst. Den første lytter på 0.0.0.0, alle grensesnitt, nåbar utenfra. Den andre lytter på 127.0.0.1, kun localhost, usynlig fra alle andre steder. En bemerkelsesverdig andel av «det fungerer på maskinen, men ikke eksternt»-saker ender på denne linjen.
Ping kan lyve. Noen nettverk dropper ping mens de serverer trafikk i fleng, så test den ekte protokollen i stedet. curl -I example.com vil svare HTTP/2 200: bare headere, ikke selve siden.

Dør pinger med rå adresse midtveis, viser traceroute det siste hoppet som svarte — det er nettverkskapittelets område. Og når ss sier 0.0.0.0, men utenforstående får ingenting, er den mistenkte en brannmur. Samme kapittel skisserer det landskapet (ufw på Ubuntu, firewalld på Fedora) i prosa uten kommandoer, noe som omtrent er der denne guiden også stopper.

«Tjenesten vil ikke starte»

Tjenester feiler høfligere enn disker — systemd skriver ned alt. Først navnene, for de biter. SSH-daemonen heter ssh.service på Ubuntu, der sshd.service også finnes som et alias, og sshd.service på Fedora og Arch. En god andel av «unit not found»-panikk er én distros navn tastet inn på en annen distros maskin. systemctl is-active NAVN svarer med en tilstand, og inactive er en gyldig tilstand: ssh satt deaktivert i Ubuntu-containeren vår, slått av i stedet for ødelagt. Tjenester og logger lærer bort systemctl-grunnene.

systemctl --failed lister de syke unitene. En frisk maskin svarer 0 loaded units listed. En syk en navngir navn — ● vfyfail.service loaded failed failed VFY broken unit — og avslutter med 1 loaded units listed.

For historien bak en feil: status først, journal etterpå:

× vfyfail.service - VFY broken unit
     Active: failed (Result: exit-code) since Mon 2026-08-31 21:17:35 UTC; 31s ago

Status forteller deg at den feilet. Journalen forteller deg hvorfor:

$ journalctl -u vfyfail -n 20
vfyfail.service: Unable to locate executable '/nonexistent/vfyfail': No such file or directory
vfyfail.service: Failed at step EXEC spawning /nonexistent/vfyfail: No such file or directory
vfyfail.service: Main process exited, code=exited, status=203/EXEC
vfyfail.service: Failed with result 'exit-code'.

Denne uniten pekte ExecStart sin mot en binærfil som ikke finnes, og status=203/EXEC er systemds kortform for det. Mønsteret gjelder enhver tjeneste: journalctl -u NAVN -n 20 er der grunnen bor. SSH — herding av serveren leser de samme linjene for sin egen daemon.

Én reload-regel, lært på den harde måten. En ny unitfil legges merke til av seg selv — slipp den på plass og start den, ingen seremoni trengs. Men etter redigering av en eksisterende fortsetter systemd å kjøre den utdaterte versjonen til du laster på nytt, og det står rett i statusutdataen:

Warning: The unit file, source configuration file or drop-ins of vfyfail.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Fiksen står skrevet inn i advarselen: kjør systemctl daemon-reload, og start så på nytt. Den dyre versjonen av denne feilen er å redigere en unit, starte tjenesten på nytt, og teste den gamle konfigurasjonen mens du tror du testet den nye.

«Systemet er tregt»

«Tregt» er en følelse. To tall gjør den om til en diagnose.

Først lasten. uptime skriver ut tre gjennomsnitt, for de siste 1, 5 og 15 minuttene, og nproc skriver ut antall kjerner de fordeles over:

$ uptime
 21:12:09 up 2 days, 13 min,  0 users,  load average: 0.69, 0.84, 0.89
$ nproc
12

Sammenlign det største lasttallet med kjernetallet — 12 her, ditt blir annerledes. Last 0.89 på tolv kjerner er en maskin som vri tomlene. Den samme 0.89 på en firekjernet bærbar er en normal arbeidsdag, og 12.0 på en av dem betyr at arbeidet står i kø.

Så minnet:

$ free -h
total used free shared buff/cache available
Mem:  31Gi  30Mi  31Gi  144Ki  176Mi  31Gi

Les available-kolonnen, ikke free. Linux parkerer ekstra RAM i buff/cache og gir det tilbake i det øyeblikket et program spør, så en skummel free ved siden av en frisk available er normalt, ikke et problem. (Disse tallene kommer fra en nettopp startet container; dine vil se travlere ut.)

Finn så frem til den skyldige:

$ ps aux --sort=-%mem | head

Minneeterne først, størst øverst. top gjør det samme live — trykk M for å sortere etter minne, P etter CPU, q for å gå ut — og Prosesser og system gir den en full omvisning.

Når én prosess er problemet, skriver pgrep -x firefox ut ID-ene til prosessene hvis navn matcher nøyaktig. kill PID ber den om å avslutte. kill -9 PID tvinger saken frem når ingenting annet virker — en siste utvei, som Prosesser og system forklarer.

Logger i ettertid

Tjenester og logger presenterer journalctl med -n, -f og en første --since. Å lese gårsdagens feil trenger tre filtre til, og de kombineres fritt:

$ journalctl --since "1 hour ago"
$ journalctl --since today
$ journalctl -p err
$ journalctl -b

Begge --since-formene virker som skrevet. -p err er den som overrasker folk: den viser oppføringer på err-nivå og alt som er alvorligere. I prøvekjøringen vår dukket logger skrevet på crit opp, og logger på info ble skjult — det er et gulv, ikke et filter for det nivået alene. -b kutter utdataen til gjeldende oppstart, noe som etter en måneds oppetid er forskjellen mellom to hundre linjer og to hundre tusen.

Du kan se alvorlighetsfilteret arbeide på dine egne oppføringer, for logger skriver inn i journalen. En ren logger "vfy no-tag message" endte i utdataet vi fanget opp som root[2431]: vfy no-tag message. Etiketten i klammene er brukernavnet ditt, valgt for deg når du ikke sender med -t. Oppføringer skrevet på user.err og user.crit passerer en -p err-lesing, vanlige gjør ikke det.

Én ærlig merknad om tilgang. En fersk, upriviligert bruker på Ubuntu og Fedora ser bare sine egne brukerjournal-oppføringer — ingen feilmelding, bare en kortere liste. På Arch får samme bruker

No journal files were opened due to insufficient permissions.

Medlemskap i riktig gruppe åpner hele systemjournalen: adm på Ubuntu, wheel eller systemd-journal på Fedora og Arch. Gjennom sudo ser du alltid alt.

Diskfeilen, fra start til slutt

Alt fra diskseksjonen i én transkripsjon, kjørt for alvor i en engangscontainer — en liten tmpfs som står modell for en full disk, slik at feilen kunne utløses, måles og ryddes opp etter, uten at noen ekte stasjoner sto i fare:

$ mkdir -p /mnt/vfyfs && sudo mount -t tmpfs -o size=64M tmpfs /mnt/vfyfs
$ df -h /mnt/vfyfs | tail -1
tmpfs            64M     0   64M   0% /mnt/vfyfs
$ head -c 100M /dev/zero > /mnt/vfyfs/filler.bin
head: error writing 'standard output': No space left on device
$ df -h /mnt/vfyfs | tail -1
tmpfs            64M   64M     0 100% /mnt/vfyfs
$ du -xh --max-depth=1 /mnt/vfyfs
64M	/mnt/vfyfs
$ du -xh --max-depth=1 / 2>/dev/null | grep mnt
0	/mnt
$ du -h --max-depth=1 / 2>/dev/null | grep mnt
64M	/mnt
$ rm /mnt/vfyfs/filler.bin && df -h /mnt/vfyfs | tail -1
tmpfs            64M     0   64M   0% /mnt/vfyfs

Gjennomgå den steg for steg. Den ferske monteringen rapporterer 64M tilgjengelig, ingenting brukt. head -c 100M ber om hundre mebibyte med nullbyte, filsystemet har 64M, og head dør ved veggen med feilen du nå gjenkjenner. (Ubuntu legger til (os error 28) på den linjen — formen over er Fedora- og Arch-varianten.) df bekrefter veggen: 64M brukt, 0 tilgjengelig, 100%.

du-parene er -x-lærdommen, tatt live. Innefra tmpfs teller du 64M. Fra roten med -x teller monteringspunktet /mnt som 0, fordi -x nekter å krysse inn i et annet filsystem. Derfor bruker gjennomgangen det: tallene forblir tilskrivbare til disken som eier dem. Utelater du -x, dukker tmpfsens 64M opp under /mnt, ført til feil disk.

Siste linje er gevinsten. Fjern fyllet, og plassen kommer tilbake: 0 brukt, 64M tilgjengelig, 0%.

Vil du prøve dette hjemme, er tmpfs-veien den anbefalte: kjør mount-kommandoen fra transkripsjonen, og du fyller RAM som later som den er en disk, så ingenting ekte er i fare, alt i den er borte ved neste omstart, og den eneste prisen er sudo for monteringssteget. Varianten uten montering, der fyllet peker på en mappe på et filsystem du vil overvåke i stedet, er for en ekte disk bare hvis du vet nøyaktig hvorfor du gjør det.

Hvor du står nå

Én vane bærer alt det overstående: hva sto det nøyaktig, hva har endret seg siden det fungerte, og hva er den minste testen som fortsatt feiler. Kapitlene holder verktøyreferansen — Prosesser og system for top, free og venner, Tjenester og logger for systemctl og journalctl i sin helhet.

Tre lenker verdt å ta vare på, alle på engelsk:

Arch Wiki-siden er det beste langformatkartet over dette terrenget, og man-sidene svarer på spørsmålene denne guiden bevisst dro over.