Linux commando: watch

1. De basis

watch draait een commando keer op keer en laat je de uitvoer zien op een leeggemaakt scherm. Meer doet het niet. Alles wat interessant is komt voort uit de details van hoe het dat commando draait, en uit het feit dat het niet de tool is die de meeste mensen erin zien.

1.1 De eenvoudigst mogelijke toepassing

Zet watch voor een willekeurig commando:

$ watch date

Het scherm wordt leeggemaakt en vult zich met twee dingen, een kopregel en de uitvoer:

Every 2.0s: date                              xps: Sun Aug 23 21:13:02 2026

Sun Aug 23 09:13:02 PM CEST 2026

Elke twee seconden draait het commando opnieuw en wordt het scherm hertekend. Ctrl-C stopt het. Er is geen andere uitgang, wat mensen verrast die verwachten dat q werkt: watch is geen pager.

1.2 De kopregel lezen

De kopregel bevat vier stukjes informatie en die zijn het kennen waard, want twee ervan beantwoorden precies de vragen die je stelt terwijl je naar het scherm staart.

Dat laatste punt is het onthouden waard. Een bevroren klok in de kopregel betekent dat je commando niet terugkomt, niet dat watch is doodgegaan.

1.3 Het interval is een pauze, geen schema

Vrijwel iedereen leest -n 5 als "draai dit elke vijf seconden". Dat betekent het niet. Het betekent "wacht vijf seconden nadat het commando klaar is, en draai het dan opnieuw". Is het commando traag, dan is de cyclus trager dan je vroeg.

Hier een commando dat twee seconden duurt, met het interval op een halve seconde, dat het moment van elke start wegschrijft:

$ watch -n 0.5 'date +%s.%N >> t.log; sleep 2'

# gaps between runs, in seconds:
2.5   2.5   2.5

Niet 0,5. Niet 2,0. Het interval plus de looptijd, elke keer. Daarom loopt een watch op iets traags, een databasequery, een du over een grote boom, een commando dat een DNS-lookup doet, gestaag weg van het ritme dat je dacht in te stellen. Paragraaf 6.3 laat de optie zien die dat oplost, en paragraaf 7.1 het geval waarin zelfs die niet helpt.

Het juiste mentale model: watch is een lus die tussen runs slaapt, geen planner die op intervallen afgaat. Elke eigenaardigheid in dit artikel volgt uit die zin en uit de shell in paragraaf 5.1.

3. Een korte geschiedenis

watch is ouder dan de meeste tools waarmee mensen het vergelijken, en het is meer dan eens herschreven. Het copyrightbestand op elke Debian- of Ubuntu-machine draagt nog steeds de oorspronkelijke naam:

$ grep -A3 "Tony Rems" /usr/share/doc/procps/copyright
Copyright: 1998-2004 Albert Cahalan
           1991 Tony Rems <Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.>
           1993 Larry Greenfield
           1996 Charles Blake

Uit die tijdlijn volgen twee dingen die in de praktijk uitmaken.

Ten eerste zit watch niet in POSIX, en heeft er nooit in gezeten. Het is een Linux-gemak uit de procps-familie, dus het is niet gegarandeerd op een BSD, op macOS (waar je het via Homebrew installeert), of in een minimale container-image. Een script dat erop leunt is een script dat ergens gaat falen, en paragraaf 6.4 behandelt wat je in plaats daarvan schrijft.

Ten tweede zijn de opties niet overal gelijk. De nieuwste (-q, -r, -w) ontbreken op oudere servers, dus controleer voordat je erop vertrouwt:

$ watch --version
watch from procps-ng 4.0.4

5. Gemiddelde toepassingen

5.1 De aanhalingsregel, en dat is het hele spel

Hier komt meer watch-verwarring vandaan dan uit al het andere bij elkaar. Je shell verwerkt de opdrachtregel voordat watch hem ooit ziet. Daarna geeft watch wat overblijft aan sh -c, een tweede shell, bij elke verversing opnieuw.

Twee shells, en het verschil is zichtbaar. Hier hetzelfde commando op drie manieren geschreven, waarbij de buitenste shell zelf PID 468449 heeft:

$ echo $$
468449

$ watch -t echo $$
468449                             # frozen: YOUR shell expanded it, once

$ watch -t echo '$$'
468474                             # a new number every refresh: watch's sh did it
468476
468478
468480

$ watch -t -x echo '$$'
$$                                 # no shell at all, so nothing expanded it

Lees die drie uitkomsten tot ze kloppen, want ze vormen samen het hele model. Zonder aanhalingstekens vervangt jouw shell de waarde een keer en herhaalt watch eeuwig een vaste tekst. Met aanhalingstekens gebeurt de vervanging binnen watch, elke cyclus vers. Met -x is er geen shell om iets te vervangen.

De praktische regel is kort: bevat het commando iets waar de shell om geeft, zet er dan aanhalingstekens omheen. Dat betekent $, |, >, &&, *, backticks en puntkomma's.

5.2 Pipes horen binnen de aanhalingstekens

Dit is dezelfde regel, maar hij verdient een eigen demonstratie omdat het misgaan stil verloopt in plaats van luid:

$ watch ls /etc | head -3
# the whole of /etc fills the screen.
# the pipe applied to WATCH's output, not to ls.

$ watch 'ls /etc | head -3'
adduser.conf
alsa
alternatives                       # correct

In het eerste geval gaat er niets fout. Jouw shell bouwde een pipeline met watch zelf erin, watch nam toch het scherm over, en head zat daar zonder iets nuttigs te doen. Je krijgt een geloofwaardig ogend scherm dat niet is wat je vroeg, en dat is de vervelendste soort fout.

Dezelfde valkuil geldt voor omleiding en voor ketenen:

$ watch 'systemctl is-active nginx && curl -s -o /dev/null -w "%{http_code}" localhost'
$ watch 'tail -5 /var/log/syslog 2>&1'

5.3 Wanneer je -x gebruikt

-x (afkorting van exec) slaat de sh -c helemaal over en draait je commando rechtstreeks. Gebruik het als die extra shell je meer last dan hulp bezorgt:

$ watch -x kubectl get pods -o wide
$ watch -x php artisan queue:monitor default

De ruil is dat je elke shellfunctie kwijtraakt. Pipes, omleidingen, variabelen en jokertekens houden op bijzonder te zijn en worden gewone argumenten:

$ watch -x ls /etc '|' head
ls: cannot access '|': No such file or directory
ls: cannot access 'head': No such file or directory

Heb je zowel een pipeline als -x nodig, dan moet je de shell zelf leveren, en dan kun je -x net zo goed weglaten:

$ watch -x sh -c 'echo ok | tr a-z A-Z'
OK

In de praktijk verdient -x zijn plaats bij commando's met lastige argumenten, JSON, accolades, aanhalingstekens binnen aanhalingstekens, waar het nesten goed krijgen voor sh -c meer moeite kost dan de shell waard is.

5.4 Je krijgt alleen het eerste scherm

watch toont wat past en gooit de rest weg. Hij scrollt niet, hij pagineert niet, en er is geen toets om meer te zien. Een bestand van honderd regels in een terminal van tien regels toont er acht:

$ seq 1 100 > hundred.txt
$ watch cat hundred.txt            # in a 10-row terminal

Every 2.0s: cat hundred.txt                   xps: Sun Aug 23 21:17:11 2026

1
2
3
4
5
6
7
8                                  # lines 9 to 100 are simply gone

Dit is geen bug om te omzeilen, het is een beperking om voor te ontwerpen. Laat het commando een samenvatting maken in plaats van een uitstorting:

$ watch 'tail -20 /var/log/nginx/error.log'
$ watch 'ls -1 /var/spool/queue | wc -l'
$ watch 'df -h | grep -E "^/dev|Filesystem"'
$ watch 'ps aux --sort=-%mem | head -12'

Die laatste is het patroon om je eigen te maken: sorteer op wat je belangrijk vindt, en neem dan de bovenste paar. Een scherm dat altijd past is een scherm dat je in een oogopslag leest, en dat is het hele doel van de tool.

5.5 Lange regels

Standaard breekt een regel die langer is dan de terminal af naar de volgende regel, wat je beperkte verticale ruimte opeet en een tabel onleesbaar maakt. -w kapt hem in plaats daarvan af:

$ watch -w 'ps aux --sort=-%cpu | head -15'

Voor alles met kolommen is afkappen bijna altijd de betere keuze: een afgekapte tabel loopt nog steeds recht, een afgebroken tabel niet.

5.6 De eigen bestanden van de kernel bekijken

watch en het /proc-bestandssysteem zijn voor elkaar gemaakt, en de reden is een detail dat de meeste mensen nooit opvalt. De bestanden in /proc zijn geen bestanden. Ze hebben geen inhoud tot je ze leest, en de kernel maakt het antwoord op dat moment aan:

$ ls -l /proc/meminfo /proc/loadavg
0 /proc/loadavg
0 /proc/meminfo                    # zero bytes, both of them

$ cat /proc/uptime
215685.54 3283350.21
$ cat /proc/uptime
215686.54 3283365.06               # a second later, a fresh answer

Elke verversing is dus een werkelijk nieuwe meting van levende kernelstatus, gedaan met niets exotischers dan cat. Daarmee komt een groot deel van wat de kernel weet binnen bereik van een commando van een regel:

$ watch -d 'cat /proc/loadavg'
$ watch -d 'cat /proc/meminfo'
$ watch -d 'grep -E "^(procs_running|procs_blocked)" /proc/stat'
$ watch -n 2 'cat /proc/mdstat'              # a RAID rebuild, the classic use
$ watch -d 'cat /proc/net/dev'

/sys werkt hetzelfde voor hardware- en driverstatus, meestal een waarde per bestand:

$ watch -n 5 'cat /sys/class/thermal/thermal_zone0/temp'
20000                              # millidegrees, so 20 C

$ watch -n 1 'cat /sys/class/net/eth0/statistics/rx_bytes'

Die laatste komt met de belangrijkste beperking uit dit hele artikel, en hij treft mensen die watch verder goed gebruiken. rx_bytes is een totaal, geen snelheid. Hij klimt alleen maar, en hem zien klimmen zegt je niets over hoe snel het verkeer loopt.

Voor een snelheid heb je twee metingen nodig en de tijd ertussen, en watch houdt geen herinnering aan de vorige verversing. Hij kan niet aftrekken. Alles in de vorm "per seconde" valt dus buiten wat hij kan, hoe kort het interval ook is:

$ vmstat 1                         # rates, with scrolling history
$ iostat -x 2                      # per-device I/O rates
$ sar -n DEV 1                     # network rates, and it keeps the history
$ watch -n 1 'cat /sys/class/net/eth0/statistics/rx_bytes'   # a climbing total

De algemene vorm van de regel: watch is uitstekend in het tonen van een waarde, en niet in staat een verandering over tijd te tonen, verder dan de hint van een cyclus die -d geeft. Paragraaf 7.5 gaat over de gevolgen daarvan.

7. Iets wat de meeste gebruikers niet weten

7.1 Een traag commando laat watch tegen je liegen

Paragraaf 1.3 liet zien dat het interval een pauze is. Er is een ergere versie van hetzelfde probleem, en de handleiding geeft het toe in de BUGS-sectie in plaats van het te verbergen. Duurt het commando soms langer dan het interval, dan kan watch herhaaldelijk gaan vuren om bij te komen:

BUGS
       --precise mode doesn't yet have advanced temporal distortion technology
       to compensate for a command that takes more than --interval seconds to
       execute.  watch also can get into a state where it rapid-fires as many
       executions of command as it can to catch up from a previous executions
       running longer than --interval (for example, netstat(8) taking ages on
       a DNS lookup).

Dat is een echt gevaar als het bekeken commando duur is. watch -n 1 op een query die meestal 200 ms kost en af en toe vier seconden slaat niet netjes een beurt over; hij kan datgene wat hij bevraagt gaan afhameren. Twee gewoontes voorkomen dat: stel het interval royaal boven het slechtste geval in in plaats van boven het typische geval, en kies liever een goedkope vervanger voor een dure controle. Een teller bekijken is veiliger dan bekijken wat er geteld wordt.

7.2 Elke verversing is een gloednieuw proces

De PID's in paragraaf 5.1 waren geen curiositeit, ze waren het mechanisme. Elke cyclus start een verse sh, die op zijn beurt je commando start. Er gaat niets mee tussen verversingen: geen mapwijzigingen, geen variabelen, geen enkele shellstatus.

$ watch -t 'echo $$ >> pids.log'
$ cat pids.log
468474
468476
468478
468480                             # a new shell every single time

Daar volgen drie dingen uit. Een commando met neveneffecten voert die neveneffecten bij elke verversing uit, dus watch 'curl -X POST ...' is een manier om iets een paar honderd keer voor de lunch te versturen. Een teller die je in een variabele ophoogt begint elke cyclus opnieuw. En op een kort interval start je voor altijd twee processen per cyclus, wat goedkoop is maar niet gratis, en dat is het onthouden waard voordat je -n 0.1 op een drukke productiemachine zet.

7.3 Niet-afdrukbare tekens worden verwijderd

watch haalt stilletjes stuurtekens uit de uitvoer in plaats van ze door te geven, en dat is verstandig omdat een losse escapereeks het scherm zou verpesten dat hij juist probeert te beheren. Maar het betekent wel dat wat je ziet niet altijd is wat het commando produceerde:

$ printf 'a\tb\001c\n' > np.txt      # a, tab, control-A, c
$ cat -A np.txt
a^Ib^Ac$                           # the file really does contain it

# search what reached the terminal for that byte:
$ watch -t cat np.txt
raw 0x01 bytes: 0    visible "^A": 0     # gone without a trace

$ watch -t 'cat -v np.txt'
raw 0x01 bytes: 0    visible "^A": 1     # cat -v turned it into text first

De handleiding beveelt precies die oplossing aan. Gebruik je watch om een opmaakprobleem op te sporen, in een bestand met vreemde regeleindes, in uitvoer van een programma dat iets raars uitstoot, zet dan cat -v aan het eind van de pipeline of je kijkt naar een opgepoetste versie van het bewijs.

7.4 watch is geen bestandsbewaker

Dit is de fout die de meeste tijd kost, want watch lijkt te werken. Richt hem op een build en hij ververst inderdaad, dus er ziet niets er kapot uit; hij doet alleen het verkeerde werk op het verkeerde moment.

De kernel heeft een interface voor het juiste werk, inotify, en die vertelt je het moment dat een bestand verandert in plaats van tot N seconden later. De tools die daarop gebouwd zijn wil je hebben:

$ ls *.c | entr -c make            # rebuild the instant a source file is saved
$ inotifywait -m -e close_write /var/spool/incoming

De vuistregel: zendt datgene waar je om geeft een gebeurtenis uit, luister dan naar die gebeurtenis. Gebruik watch voor toestand die niets aankondigt, en dat is het meeste van wat een server doet. Schijfgebruik, aantallen verbindingen, wachtrijlengte en processenlijsten hebben geen meldingsmechanisme, en die op een timer bevragen is precies goed.

7.5 Hij bemonstert, dus hij mist dingen

watch toont je het heden en vergeet het meteen. Beide helften van die zin kosten mensen tijd.

Het vergeten komt eerst. Stel dat de belasting op een server dit doet:

12:00   0.4
12:01   0.5
12:02   8.7        <- the thing you were called about
12:03   0.6

Je start watch uptime om 12:03 en ziet 0,6. Niet "0,6, en daarvoor was het ook prima": alleen 0,6, zonder enige manier om het verschil te zien tussen een server die de hele ochtend rustig was en een die zestig seconden geleden omviel. -d=permanent helpt een beetje vanaf het moment dat je begint, en geen seconde verder terug.

Het missen komt daarna, en dat is het subtielere. Tussen twee verversingen kijkt watch niet. Alles wat korter is dan het interval kan zich volledig in dat gat afspelen:

interval:   |-----2s-----|-----2s-----|-----2s-----|
sampled:    X            X            X
the event:        [==1.5s==]                            never seen

Het interval verkorten maakt het gat smaller maar sluit het nooit, en het kost elke cyclus meer. Die ruil is het duidelijk benoemen waard, want hij is helemaal niet eigen aan watch:

short interval   better resolution, more overhead, more load on what you watch
long interval    less overhead, more that happens invisibly between samples

Dezelfde ruil bepaalt elk metrics-systeem, elke SNMP-poll en elke healthcheck die je ooit instelt. watch is een goede plek om hem tegen te komen, want hier is de prijs van een verkeerde keuze niet meer dan een verwarrend scherm.

Twee gewoontes volgen daaruit. Onderzoek je iets dat af en toe optreedt, log het dan in plaats van het te bekijken, zodat er achteraf iets te lezen valt:

$ while true; do printf '%s %s\n' "$(date +%T)" "$(cut -d' ' -f1 /proc/loadavg)"; sleep 5; done | tee load.log

En wil je weten wat er gebeurde voordat je aankwam, aanvaard dan dat dit niet het werk van watch is. Gebruik wat de historie al bewaarde: sar, het journaal, de logs van je eigen applicatie, of een monitoringsysteem. watch beantwoordt "wat gebeurt er nu", en alleen dat.

7.6 Kleur werd de standaard, en dat veranderde oude commando's

procps-ng 4.0.4 zette ANSI-interpretatie standaard aan. De Debian-changelog legt het vast in een regel:

$ zcat /usr/share/doc/procps/changelog.Debian.gz | grep -i "watch:"
  * watch: Color support turned on by default use -C to turn off

Je ziet de omslag door de kleurcodes te tellen die overleven:

# command emits ESC[31m for red
$ watch ...        SGR-31 sequences passed through: 1     # interpreted
$ watch -c ...     SGR-31 sequences passed through: 1     # same, -c is now redundant
$ watch -C ...     SGR-31 sequences passed through: 0     # stripped

Meestal is dit een verbetering. Het bijt op een specifieke plek: bij een commando waarvan je de uitvoer juist om de escapecodes leest, worden die nu opgeslokt. Gebruikte je watch om ruwe gekleurde uitvoer te bekijken, voeg dan -C toe. En kom je een tutorial tegen die volhoudt dat je -c nodig hebt, dan is die van voor 2023 en is de rest van het advies mogelijk net zo verouderd.

7.7 Weten waar watch ophoudt

watch is een kleine tool en hij is eerlijk over zijn omvang. Het punt waarop je moet ophouden hem op te rekken:

Nog voor al die dingen is er echter een goedkopere vraag te stellen, en die slaan mensen over: weet het commando al hoe het zichzelf moet herhalen? Verrassend veel commando's weten dat, en hun eigen modus is bijna altijd beter dan ze inpakken:

Kijk goed naar de tweede en derde regel, want die zijn niet alleen netter. vmstat 1 en iostat -x 2 drukken elk interval een nieuwe regel af en laten die doorscrollen, en daarmee geven ze je de twee dingen waarvan paragraaf 7.5 zei dat watch ze structureel niet kan: snelheden, en een historie om in terug te kijken. Biedt een tool zijn eigen herhaalmodus, dan biedt hij die twee er meestal bij.

Die vijfde regel is het proberen waard als je tmux al hebt. Drie panelen met watch -d op schijf, verbindingen en wachtrijlengte maken een bruikbaar dashboard uit tools die je al hebt:

$ tmux new-session -d 'watch -d -n 5 df -h'
$ tmux split-window -h 'watch -d -n 2 "ss -tn state established | wc -l"'
$ tmux split-window -v 'watch -d -n 5 "ls /var/spool/queue | wc -l"'
$ tmux attach

9. Veelgemaakte fouten

9.1 watch versus een shell-lus

Vrijwel iedereen schrijft de lus voordat hij het commando leert kennen, en die lus is een volstrekt redelijk ding om te schrijven. Het is goed om helder te hebben wat je wint en wat je opgeeft, want het antwoord is niet "de lus is slechter".

$ while true; do clear; df -h; sleep 5; done

Dat is het eerlijke equivalent, en voor een snelle blik is het prima. Dit is wat watch -n 5 df -h toevoegt:

De scheiding is helder zodra je hem ziet. watch is om te kijken; een lus is om te doen. Gaat er een mens zitten en het scherm lezen, dan wint watch -d op elk punt dat ertoe doet. Zodra er iets met het antwoord moet gebeuren, gelogd, opnieuw geprobeerd of teruggegeven aan een aanroeper, schrijf je de lus, want watch kan het resultaat niet doorgeven (paragraaf 6.4).

Die laatste regel vergeet je makkelijk. De clear weglaten maakt van de lus iets wat watch helemaal niet kan: een doorscrollend verslag waarin je achteraf kunt terugbladeren, en paragraaf 7.5 betoogde dat dat vaak is wat je eigenlijk wilde.

9.2 Mythe versus werkelijkheid

9.3 Andere valkuilen om te vermijden

• Iets met neveneffecten bekijken. watch 'curl -X POST .../deploy' rolt elke twee seconden uit. Hetzelfde geldt voor alles met rm, mv, INSERT of een e-mail erin.
• Een inloggegeven in een bekeken commando zetten. Het geheim staat de hele sessie in de argumentenlijst van watch, zichtbaar voor iedereen:

  $ watch -n 2 'mysql -u root -phunter2 -e "SHOW PROCESSLIST"'
  
  # from any other account on the box, for as long as it runs:
  $ ps -ef | grep watch
  pe7er  471478  watch -n 2 mysql -u root -phunter2 -e SHOW PROCESSLIST

  Gebruik een gegevensbestand met inloggegevens, een socket, of een omgevingsvariabele die het commando zelf uitleest. Een eenmalig commando flitst voorbij in de processentabel; een watch parkeert het daar.
• Een commando bekijken dat op invoer wacht. git log, systemctl status en soortgenoten openen een pager, die daar vervolgens blijft staan. Voeg --no-pager toe, of zet PAGER=cat.
• Een kort interval urenlang laten draaien. -n 0.1 is twintig processen per seconde, eindeloos. Prima voor een minuut debuggen, onbeleefd op een gedeelde server 's nachts.
• sudo bekijken. sudo kan vanuit watch niet om een wachtwoord vragen, dus tenzij het gegeven al in de cache staat faalt elke verversing op dezelfde manier: sudo: a password is required. Authenticeer eerst, of start het geheel met sudo watch ... zodat de vraag een keer vooraf komt.
• Vergeten dat het commando elke cyclus opnieuw ontleed wordt. Een relatief pad wordt opgelost vanaf de map waar je begon, wat prima is, maar een cd binnen het commando blijft niet staan tot de volgende verversing.
• Verwachten dat -d een schermwijziging overleeft. De handleiding is expliciet: bij het aanpassen van de terminalgrootte wordt het scherm pas bij de volgende verversing hertekend, en gaat alle markering verloren.
• watch gebruiken als monitoring voor de arme man. Hij heeft geen historie, geen waarschuwingen en geen verslag. Doet het er om drie uur 's nachts toe, dan hoort het in een monitoringsysteem.
• Aannemen dat -x alleen maar netter quoten is. Het haalt de shell volledig weg, dus pipes, omleidingen, jokertekens en variabelen werken niet meer (paragraaf 5.3).
• Een schermafbeelding van watch zonder kopregel vertrouwen. Met -t is er geen tijdstempel, dus een oude schermafbeelding ziet er precies zo uit als een actuele.
• Ernaar grijpen op een trage verbinding. Elke verversing tekent het hele scherm opnieuw. Over een haperende SSH-sessie is een interval van een seconde erger dan nutteloos; verhoog het interval en verklein de uitvoer.