Linux commando: tail

Er is iets mis op een server, en het eerste wat iedereen typt is tail -f op een logbestand. Het is waarschijnlijk het meest gebruikte commando in systeembeheer, en bijna iedereen gebruikt het op een manier die vannacht om middernacht stilletjes ophoudt te werken, wanneer het log roteert. Dit artikel gaat over de standaard van tien regels, het plusteken dat verandert wat het getal betekent, en de ene letter die bepaalt of je morgenochtend nog steeds naar je log kijkt.

2. Waar komen de namen vandaan?

De namen zijn letterlijk. Een bestand heeft een kop en een staart zoals een wachtrij of een lijst die heeft, en de commando's tonen de een of de ander. Er is geen afkorting en geen verborgen grap.

Wat wel het weten waard is, is de scheefheid eronder. Die twee lijken broers en zussen die samen geschreven zijn, en dat waren ze niet. Ze komen uit verschillende Unix-lijnen, ze verschenen een jaar na elkaar, en maar een van beide kreeg ooit de functie die hem beroemd maakte. tail kreeg -f. head had die nooit nodig: een bestand groeit niet aan de voorkant.

Die ene optie is de reden dat tail een begrip is en head niet. Het vocabulaire eromheen is klein en het is goed het helder te hebben:

-f, --follow      keep the file open and print new data as it is appended
-F                shorthand for --follow=name --retry (see section 6)
descriptor        follow THIS file, even if it gets renamed  (the -f default)
name              follow whatever has THIS name, reopening as needed
--retry           keep trying to open a file that is missing or unreadable
rotation          when a log is renamed or truncated and a fresh one begins
inotify           the kernel interface that tells tail the moment a file changes

Twee daarvan zijn belangrijker dan de rest. Descriptor versus naam is de hele paragraaf 6, en het is het verschil tussen een tail -f die de nacht overleeft en een die dat niet doet. En inotify is waarom een moderne tail -f direct reageert in plaats van een keer per seconde wakker te worden om te kijken.

4. Eenvoudige toepassingen

4.1 Naar de uiteinden van dingen kijken

Het dagelijks gebruik heeft geen uitleg nodig, alleen de gewoonte:

$ head -n 20 /etc/services              # what is at the top of this file?
$ tail -n 50 /var/log/nginx/error.log   # what just went wrong?
$ head -n 1 *.csv                       # the header row of every file
$ tail -n 1 /etc/passwd                 # the most recently added account

4.2 Een kopregel overslaan

Dit is het nuttigste dat het plusteken doet, en het komt voortdurend voor bij CSV-bestanden en bij commando's die een titelregel afdrukken:

$ tail -n +2 data.csv                   # everything EXCEPT the header
$ ps aux | tail -n +2                   # the processes, without the column titles
$ df -h | tail -n +2 | sort -k5 -hr     # sort by use%, header out of the way

Lees -n +2 als "begin bij regel 2". Het is de idiomatische manier om een kopregel in een shell-pipeline te laten vallen, en het is veel veiliger dan grep -v op de koptekst, wat ook elke gegevensregel wist die er toevallig op lijkt.

4.3 Meerdere bestanden tegelijk

Geef een van beide commando's meer dan een bestand en het labelt ze voor je:

$ tail -n 1 f1.txt f2.txt
==> f1.txt <==
a2

==> f2.txt <==
b2

Twee opties bepalen die labels, en beide zijn af en toe precies wat je nodig hebt:

$ tail -q -n 1 f1.txt f2.txt        # -q for quiet: no headers, just the lines
a2
b2

$ tail -v -n 1 f1.txt               # -v for verbose: force a header on ONE file
==> f1.txt <==
a2

-q is degene die je wilt als je het resultaat aan een ander commando voert, want die ==>-regels zijn gegevens voor zover het volgende programma weet. Een snelle manier om de laatste regel van elk log in een map te krijgen:

$ tail -q -n 1 /var/log/*.log | sort

4.4 Bytes in plaats van regels

-c is het juiste gereedschap als het bestand geen bruikbare regels heeft, of als het je om grootte gaat en niet om structuur:

$ head -c 512 disk.img | xxd | head -n 4     # look at a boot sector
$ head -c 2M huge.log > sample.log           # grab a manageable sample
$ tail -c 100 file.bin | xxd                 # the last 100 bytes

head -c is de nette manier om een heel groot of binair bestand te bemonsteren, omdat het stopt met lezen zodra het heeft wat het nodig heeft. Paragraaf 7.1 meet precies hoeveel dat scheelt.

Een waarschuwing bij tekst. Bytes zijn geen tekens, en -c telt bytes. Snijd op de verkeerde plek en je hakt een teken van meerdere bytes doormidden:

$ printf 'aeiou \xc3\xa9\xc3\xa8\xc3\xaa done\n' > u.txt      # three 2-byte chars

$ tail -c 12 u.txt | xxd
00000000: c3a9 c3a8 c3aa 2064 6f6e 650a       # lands on a boundary: fine

$ tail -c 11 u.txt | xxd
00000000: a9c3 a8c3 aa20 646f 6e65 0a         # starts mid-character

$ tail -c 11 u.txt | iconv -f UTF-8 -t UTF-8
iconv: illegal input sequence at position 0

Een losse vervolgbyte is geen geldige UTF-8, dus het eerste teken komt eruit als een vervangingsteken of helemaal niet. Tel bij alles met accenten, emoji of niet-Latijns schrift liever regels dan bytes.

6. Gevorderde toepassingen

6.1 Logrotatie, en de letter die ertoe doet

Dit is de belangrijkste paragraaf van het artikel. Elk log op een productieserver wordt geroteerd, meestal 's nachts, en de standaard tail -f overleeft dat niet. Hij waarschuwt je niet. Hij stopt gewoon met iets tonen, voorgoed, terwijl hij er precies zo uitziet als wanneer hij werkt.

Hier het experiment. Twee tails op hetzelfde bestand, een met -f en een met -F, over een rotatie die hernoemt en opnieuw aanmaakt:

$ echo "line 1 before rotation" > app.log
$ tail -f app.log > out-f.txt &
$ tail -F app.log > out-F.txt &
$ echo "line 2 before rotation" >> app.log

$ mv app.log app.log.1                     # what logrotate does
$ echo "line 3 AFTER rotation" > app.log
$ echo "line 4 AFTER rotation" >> app.log

En de twee uitkomsten, naast elkaar:

----- tail -f saw -----
line 1 before rotation
line 2 before rotation
                                   # and then nothing. Ever.

----- tail -F saw -----
line 1 before rotation
line 2 before rotation
tail: 'app.log' has become inaccessible: No such file or directory
tail: 'app.log' has appeared;  following new file
line 3 AFTER rotation
line 4 AFTER rotation

De reden is een stukje Unix dat het een keer begrijpen waard is, want het verklaart nog een tiental andere dingen. Een bestandsnaam is niet een bestand. Er zijn drie afzonderlijke lagen bij betrokken:

Dus als logrotate app.log hernoemt naar app.log.1, gebeurt er niets met het bestand dat tail open heeft. De mapregel verhuisde; de inode niet. tail -f volgt nog steeds trouw dezelfde bytes als altijd, die nu app.log.1 heten en waar nooit meer iets naartoe geschreven wordt.

Dat is de hele fout, en het is een verdedigbaar ontwerp en geen vergissing. -f volgt de bestandsdescriptor, en dat is juist voor "kijk naar dit exacte bestand" en precies verkeerd voor "kijk naar dit log".

-F volgt de naam. Zodra de naam niet meer wijst naar het bestand dat hij open had, zegt hij dat en opent hij opnieuw. Het is een afkorting voor twee langere opties:

$ tail -F app.log
$ tail --follow=name --retry app.log       # identical

Maak -F je standaard voor alles onder /var/log. Het kost niets: op een bestand dat nooit roteert gedraagt -F zich precies als -f.

6.2 De andere soort rotatie

De regel hierboven heeft een eerlijke nuance nodig, want logrotate heeft een tweede modus. Met copytruncate wordt het bestand gekopieerd en daarna ter plekke leeggemaakt in plaats van hernoemd, dus de descriptor blijft geldig. Een kale -f kan daarmee overweg:

$ cp t.log t.log.1 && : > t.log        # copytruncate, in two commands
$ echo "after truncate" >> t.log

# what tail -f printed:
before 1
before 2
tail: t.log: file truncated
after truncate                     # it kept up

Welke rotatiestijl je server gebruikt bepaalt dus of een kale -f stilletjes faalt. Je kunt het opzoeken:

$ grep -r copytruncate /etc/logrotate.conf /etc/logrotate.d/ | head

Het praktische advies verandert niet. Gebruik -F en je hoeft het niet te weten of erom te geven, want die kan met allebei overweg.

6.3 Wachten op een bestand dat nog niet bestaat

-F bevat --retry, en dat betekent dat je kunt beginnen met kijken voordat er iets is om naar te kijken. Dat is precies wat je wilt als je op het punt staat een dienst te starten waarvan het log pas bestaat als het bestaat:

$ tail -F /var/log/myapp/app.log
tail: cannot open '/var/log/myapp/app.log' for reading: No such file or directory
tail: '/var/log/myapp/app.log' has appeared;  following new file
[2026-08-24 09:15:02] starting up

Een kale tail -f op een ontbrekend bestand drukt een fout af en stopt meteen. -F wacht. Start eerst de tail, dan de dienst, en je mist de eerste regels niet.

6.4 inotify, en waar -s nog voor dient

Een moderne tail -f polt niet. Op Linux vraagt hij de kernel om hem te melden wanneer het bestand verandert, via dezelfde inotify-interface die andere bestandsbewakers gebruiken. Je kunt het bevestigen op een draaiende tail:

$ tail -f w.log &
$ ls -l /proc/$!/fd | grep -c inotify
1                                  # one inotify descriptor

Daarom verschijnen nieuwe regels direct in plaats van tot een seconde later. De optie -s, die een wachttijd tussen controles instelt, is een overblijfsel uit het polltijdperk en doet op een lokaal bestand vandaag vrijwel niets. In een geval telt hij nog wel: inotify werkt niet betrouwbaar op netwerkbestandssystemen, dus op een log op een NFS-koppeling valt tail terug op pollen en wordt -s weer echt.

$ tail -f -s 5 /mnt/nfs/shared/app.log     # check every 5s on a network mount

6.5 In scripts

head en tail gedragen zich netjes in scripts zolang je -f vermijdt, die per ontwerp nooit terugkomt. Drie patronen dekken vrijwel alles:

# bounded: read a fixed amount and move on
last_line=$(tail -n 1 "$logfile")

# follow, but with an owner: tail dies when the job does
./deploy.sh & tail -F deploy.log --pid=$!

# follow, but with a deadline
timeout 300 tail -F deploy.log

Let op een wisselwerking. Schrijf je tail -f log | grep -q PATROON in de verwachting dat het bij de eerste treffer stopt, bedenk dan dat grep -q inderdaad stopt, maar dat tail dat pas merkt als hij weer probeert te schrijven, dus de pipeline kan blijven hangen. Geef hem een deadline met timeout, of gebruik de --pid-vorm hierboven.

Er is een tweede wisselwerking, en die heeft meer scripts gebroken dan wat dan ook in dit artikel. Paragraaf 7.2 laat zien dat head zijn producent met SIGPIPE doodt, wat die afsluitcode 141 geeft. Normaal verbergt de shell dat, want een pipeline meldt alleen de status van zijn laatste commando. Zet pipefail aan en het verbergen houdt op:

$ bash -c 'yes | head -n 2 >/dev/null; echo $?'
0                                  # the usual, comfortable answer

$ bash -c 'set -o pipefail; yes | head -n 2 >/dev/null; echo $?'
141                                # SIGPIPE, now visible

Bedenk nu hoe vrijwel elk zorgvuldig script begint:

#!/bin/bash
set -euo pipefail                  # the standard safety boilerplate

count=$(seq 1 2000000 | head -n 1)        # perfectly ordinary line
echo "reached this line, c=$count"        # never printed

$ ./script.sh; echo "script exit: $?"
script exit: 141

set -e zag een status die niet nul was en stopte. De pipeline deed precies wat de bedoeling was, en het script stierf zonder bericht. Dit treft mensen die alles goed hebben gedaan. Drie uitwegen, gemeten:

seq 1 2000000 | head -n 1        -> 141    the problem
seq 1 2000000 | head -n 1 || true ->   0    tolerate it where it is harmless
seq 1 2000000 | sed -n '1p'      ->   0    sed keeps reading, so no SIGPIPE
seq 1 2000000 | sed -n '1{p;q}'  -> 141    ... but quit early and it is back

Die derde regel heeft een prijs die het benoemen waard is: sed -n '1p' ontloopt het signaal juist doordat hij alle twee miljoen regels leest in plaats van te stoppen. Hij ruilt een statuscode in voor het werk dat head je bespaarde. Op een grote invoer is || true het betere antwoord.

Hetzelfde geldt voor grep -q en voor al het andere dat een pipe sluit voordat zijn producent klaar is.

8. Best practices

• Gebruik -F en niet -f op alles in /var/log. Rotatie via hernoemen maakt een kale -f stilletjes doof, en -F kost niets op een bestand dat nooit roteert.
• Schrijf -n 20, niet -20. Het kale getal is de verouderde vorm van voor POSIX. Hij werkt nog en hij zal de volgende lezer nog steeds in verwarring brengen over regels versus bytes.
• Leer tail -n +2. "Begin bij regel 2" is de nette manier om een kopregel te laten vallen, en het is beter dan grep -v op de koptekst, dat ook passende gegevens opeet.
• Onthoud head -n -1. "Alles behalve de laatste regel" scheelt naar sed grijpen zodra een bestand een afsluitend totaal of een samenvatting heeft.
• Geef de bestandsnaam mee, gebruik geen cat ervoor. tail -n 5 bestand springt naar het einde; cat bestand | tail -n 5 leest het hele ding. Op een log van een gigabyte is dat 0,00 s tegen 0,32 s.
• Voeg --line-buffered toe aan grep in elke tail -f-pipeline, en -u aan sed, fflush() aan awk, of stdbuf -oL aan al het andere. Anders blijven je treffers in een buffer van 4 kB zitten.
• Begin met meer context dan de standaard. tail -n 100 -F laat je zien wat voorafging aan het ding waarop je wacht; tien regels doen dat zelden.
• Gebruik --pid=$! als je het log van een klus volgt. De tail eindigt dan wanneer de klus eindigt, in plaats van eeuwig te blijven hangen.
• Zet nooit een kale tail -f in een script. Hij komt per ontwerp niet terug. Begrens hem met --pid of timeout.
• Gebruik -q als je meerdere bestanden doorstuurt. Die ==>-kopregels zijn gegevens voor het volgende commando in de pipeline.
• Grijp naar less +F als je wilt lezen zowel als kijken. Ctrl-C om terug te scrollen en te zoeken, F om verder te volgen.
• Kies tail -n +8 | head -n 5 boven head -n 12 | tail -n 5 voor een bereik in het midden. Zelfde antwoord, en het stopt met lezen zodra het heeft wat het nodig heeft.
• Bescherm | head in elk script met set -o pipefail. Schrijf | head -n 1 || true waar de SIGPIPE onschuldig is, anders sterft het script op afsluitcode 141 zonder iets verkeerd te hebben gedaan.
• Tel regels en geen bytes bij tekst met accenten. -c kan een UTF-8-teken doormidden snijden en ongeldige uitvoer opleveren.
• Gebruik binnen containers het commando van de runtime zelf. docker logs -f --tail 100 en kubectl logs -f zijn de echte equivalenten, want een goede image logt naar stdout en heeft geen bestand om te tailen.
• Lees de handleiding voor de twee die je gaat vergeten. --retry en --follow=name zijn waar -F uit bestaat, en dat weten maakt zijn gedrag vanzelfsprekend in plaats van magisch.

$ man 1 tail               # short, and the -f/-F explanation is worth reading
$ man 1 head
$ info coreutils 'tail invocation'    # deeper than the man page
$ man 1 less               # for +F
$ man 5 logrotate.conf     # to see which rotation style your server uses

10. Samenvatting

head en tail horen bij de eerste commando's die iemand leert en bij de laatste waarvan iemand de handleiding leest. De delen die het weten waard zijn: het plusteken, de letter F, en de buffer midden in je pipeline.

• Beide staan standaard op tien regels. -n verandert het aantal, -c schakelt over naar bytes, en beide lezen standaardinvoer als je geen bestand meegeeft.
• Het teken verandert de vraag. tail -n 3 is "de laatste drie"; tail -n +3 is "van regel 3 tot het einde". head -n -3 is "alles behalve de laatste drie".
• tail -n +2 laat een kopregel vallen. head -n -1 laat een afsluitende samenvatting vallen. Die twee dekken het meeste waarvoor mensen sed schrijven.
• tail -f sterft stilletjes wanneer een log roteert. Hij volgt de bestandsdescriptor en kijkt dus naar het hernoemde oude bestand. -F volgt de naam, zegt wat er gebeurde, en opent opnieuw.
• -F is precies --follow=name --retry, wat ook betekent dat hij wacht op een bestand dat nog niet bestaat.
• De uitzondering: bij copytruncate-rotatie blijft de descriptor geldig, dus een kale -f redt het en drukt "file truncated" af. Gebruik -F en je hoeft nooit te weten welke stijl je server gebruikt.
• tail -f | grep lijkt kapot omdat grep buffert. Voeg --line-buffered toe, of stdbuf -oL voor al het andere in de pipeline.
• tail springt: 0,00 s om het einde van een bestand van 1,1 GB te lezen. cat bestand | tail leest alles, omdat je in een pipe niet kunt springen. Geef de bestandsnaam mee.
• head die een pipe sluit stuurt SIGPIPE naar de producent, die met 141 stopt. Dat is wat yes | head laat stoppen in plaats van eeuwig door te gaan.
• Op Linux gebruikt tail -f inotify en reageert direct. -s is een optie uit het polltijdperk die alleen op netwerkbestandssystemen telt.
• --pid=$! laat een follow eindigen wanneer de klus die hij volgt eindigt. Zet nooit een kale tail -f in een script.
• Meerdere bestanden krijgen ==>-kopregels, ook tijdens het volgen. -q haalt ze weg, -v dwingt ze af.
• Een bestand zonder laatste regeleinde levert uitvoer zonder laatste regeleinde. tail kopieert wat er staat.
• head komt uit 1BSD in 1978 en tail uit Version 7 Unix in 1979. Schrijf -n 5 en niet -5: het kale getal dateert van voor POSIX.
• De sprong is zichtbaar in vier systeemaanroepen: SEEK_END voor de grootte, SEEK_SET naar een blok voor het einde, en een leesactie van 2751 bytes van de 1,3 MB. Via een pipe zijn er helemaal geen sprongen, dus valt tail terug op een rollende buffer en leest hij elke byte.
• Een bestandsnaam is niet een bestand. Hernoemen verplaatst een regel in een map; de inode en elke geopende descriptor blijven onaangeroerd. Precies daarom blijft tail -f een log lezen waar niets meer naartoe geschreven wordt.
• Onder set -o pipefail laat | head een pipeline 141 melden, en set -e breekt het script dan af. Gebruik || true waar de SIGPIPE onschuldig is.
• -F werkt ook op BusyBox. --pid, --retry en de lange opties zijn alleen GNU, en dat telt binnen minimale container-images.
• -c telt bytes en kan dus een UTF-8-teken splitsen en ongeldige uitvoer geven. Tel regels bij tekst met accenten.
• Gebruik in containers docker logs -f of kubectl logs -f. En tail -f /dev/null is geen loggen: het is een keep-alive-hack die verbergt dat de container geen echt hoofdproces heeft.
• Voor lezen zowel als kijken verslaat less +F de tail -f. Voor het journaal journalctl -f.

Dit is het overzicht dat het bewaren waard is:

THE BASICS (both default to 10 lines)
head -n 20 FILE            first 20 lines
tail -n 20 FILE            last 20 lines
head -c 512 FILE           first 512 bytes  (K=1024, kB=1000)
tail -c 100 FILE           last 100 bytes

THE SIGN CHANGES THE QUESTION
tail -n +2 FILE            from line 2 on   <- drops a header row
head -n -1 FILE            all but the last line  <- drops a summary row
tail -c +2 FILE            from byte 2 on   <- strips a leading byte
head -c -4 FILE            all but the last 4 bytes

A RANGE IN THE MIDDLE (lines 8-12)
tail -n +8 FILE | head -n 5      preferred: stops reading early
head -n 12 FILE | tail -n 5      same answer, reads more

FOLLOWING A LOG
tail -F FILE               USE THIS. = --follow=name --retry
tail -f FILE               follows the descriptor: DIES on rotation
tail -n 100 -F FILE        start with real context
tail -F a.log b.log        several at once, with ==> headers
tail -F FILE --pid=$!      exit when the writer exits
timeout 300 tail -F FILE   exit after 5 minutes
less +F FILE               follow, Ctrl-C to scroll back, F to resume

UNBUFFERING A FOLLOW PIPELINE (or nothing appears)
tail -F log | grep --line-buffered ERROR
tail -F log | sed -u 's/x/y/'
tail -F log | awk '/E/ { print; fflush() }'
tail -F log | stdbuf -oL ANY-OTHER-COMMAND

MULTIPLE FILES
tail -q -n 1 *.log         no ==> headers (use when piping onward)
tail -v -n 1 one.log       force a header on a single file

IN CONTAINERS (a good image logs to stdout, so there is no file)
docker logs -f --tail 100 NAME
docker compose logs -f SERVICE
kubectl logs -f deploy/NAME --tail=100
tail -f /dev/null          NOT logging: a keep-alive hack. Prefer sleep infinity.

PORTABILITY
-n -c -q -v -f -F -s -n +N -n -N     GNU and BusyBox both
--pid --retry --follow=name          GNU only (absent in BusyBox)

SCRIPTS
set -o pipefail  +  | head   ->  exit 141, and set -e aborts. Use || true.
tail -c N on UTF-8 text can split a character. Count lines instead.

tail SEEKS to the end: pass the filename, never cat into it
exit 141 from a producer = SIGPIPE = head closed the pipe. Normal.
-5 is the obsolete pre-POSIX form. Write -n 5.

Neem je een gewoonte mee uit dit artikel, maak er dan de hoofdletter F van. De meeste mensen ontdekken het verschil op de harde manier, om twee uur 's nachts, starend naar een log dat om middernacht ophield iets te zeggen, zich afvragend waarom het probleem stil werd. En blijft een server symptomen geven die niemand kan aanwijzen, dan staat het antwoord meestal al in een log dat niemand goed volgde.