journalctl Cheat Sheet: Tail, Filter at Follow ng Linux Logs

journalctl sa isang linya: journalctl -u <service> -f para sundan ang live service log, journalctl -u <service> -n 100 para sa huling 100 linya, at journalctl --since "1 hour ago" para sa lahat ng kamakailan. Yan ang sagot sa 90% ng mga “bakit patay ang service na ito” moment. Ang natitira ng cheat sheet na ito ay ang mga copy-paste pattern na nagliligtas sa’yo sa paulit-ulit na pagbasa ng man page alas-dos ng madaling-araw — filtering kada unit, oras, priority at boot, plus ang mga cleanup command na pumipigil sa journal na kainin ang disk mo. Bawat command sa ibaba ay tumatakbo as-is sa kahit anong systemd distro (Ubuntu, Debian, Fedora, Arch).

Ano ang journalctl at bakit hindi na lang basahin ang /var/log/syslog?

Ang old-school Linux logging ay nagsusulat ng plain text files sa ilalim ng /var/log — syslog, auth.log, messages. Pinalitan ito ng systemd gamit ang journal: binary, indexed log na pinangangasiwaan ng systemd-journald. Hindi kayang basahin ng plain grep; ang journalctl lang ang pinto, at kapalit nito may filtering ka kada service, oras, boot at severity nang walang regex gymnastics.

Simple lang ang mental model: nakastore sa journal ang lahat, at ang journalctl ang query tool. Hindi kailangan ng sariling log file ng isang service — anumang isulat nito sa stdout/stderr habang tumatakbo sa ilalim ng systemd ay diretso sa journal. Kaya gumagana ang journalctl -u nginx kahit walang idea ang lahat kung saan ni-configure ng nginx ang error log nito.

Isang caveat: sa ilang minimal installs, volatile ang journal (naka-store sa /run, binubura sa reboot) dahil wala ang /var/log/journal. Isang beses lang ang ayos:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

Paano ko makita ang huling 100 linya ng log?

Nililimitahan ng -n ang output sa pinakabagong N linya (default ay 10):

journalctl -n 100                      # last 100 lines of everything
journalctl -u nginx -n 100             # last 100 lines from one unit
journalctl -n 100 --no-pager           # print and exit — perfect for piping

Mas mahalaga ang --no-pager kaysa itsura nito: kapag wala ito, magbubukas ang journalctl ng less at ang script mo, pipe o ssh one-liner ay mapupuwing naghihintay ng keypress. Dapat bitbitin ito ng kahit anong command na ipi-pipe mo pa.

Paano ko ma-follow ang logs nang live, parang tail -f?

Ang -f flag ang tail -f ng journalctl — sinasabayan nito ang mga bagong entry habang nangyayari:

journalctl -f                    # everything, live
journalctl -u sshd -f            # just the SSH daemon, live
journalctl -u ollama -f -n 50    # live, but start with the last 50 lines

Ito ang command na i-run mo sa pangalawang terminal habang nirerestart mo ang service sa una: systemctl restart nginx sa isang pane, journalctl -u nginx -f sa kabila, at ang sanhi ng crash karaniwang nagpapakilala sa sarili sa loob ng ilang segundo. Eksaktong ganito ang loop ko sa homelab ko tuwing may umastang container o service.

Paano ko ipakita ang logs ng isang partikular na service?

Ang -u ay nagfi-filter kada systemd unit:

journalctl -u nginx                    # one unit, all history
journalctl -u nginx -u redis           # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # the exact-match alternative

Pwedeng mag-spawn ang units ng helper units na silang nagtatago ng interesting output — minsan ang totoong error ng isang failing web app ay naka-log sa ibang unit. Kung walang laman ang -u <service> pero halatang tumatakbo ang service, hanapin mo muna ang totoong unit name:

systemctl list-units --type=service | grep -i <guess>

Gumagana rin ang same -u pattern sa mga timer (systemctl list-timers ang nagpapakita ng names) at sa mga user service — para sa kahit anong tumatakbo sa ilalim ng systemd --user, dagdagan mo ng --user:

journalctl --user -u pipewire -n 50

Paano mag-filter ng logs ayon sa oras?

Tumatanggap ang --since at --until ng timestamps, pero tinatanggap din nila ang mapagpatawad na relative phrasing:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Pagsamahin mo ang time window at isang unit, at may incident triage ka na sa isang linya: “ano ang naka-log ng API between 09:00 at nang bumagsak ito?” Mas mabilis pa iyan kaysa kahit anong log aggregator para sa isang box.

Paano ko ipakita ang mga errors lang (o warnings)?

Ang -p ay nagfi-filter kada priority, gamit ang syslog severity names:

journalctl -p err -b              # errors only, since this boot
journalctl -p warning..alert -u nginx   # a range of severities

Ang mga priority, pababa: emerg, alert, crit, err, warning, notice, info, debug. Kapag “kakaiba ang kilos” ng isang box, ang journalctl -p err -b --since today ang pinakamabilis na sanity check — sinasagot nito ang “may talaga bang bumabagsak?” nang walang ingay ng routine info lines.

Paano ko makita ang logs mula sa previous boot?

Ang mga service na bumabagsak sa startup ay nag-iiwan ng log lines bago ang current boot mo, at tahimik na ipinapakita lang ng journalctl ang kasalukuyan. Ang -b ang pumipili ng boots:

journalctl -b                 # current boot only
journalctl -b -1              # previous boot
journalctl -b -1 -u sshd      # why SSH died last time
journalctl --list-boots       # index of stored boots

Ito ang isang pinakamahalagang flag para sa “nabagsak, nirinset ko, at ngayon hindi ko na makita ang error” — nandiyan pa rin ang error, isang boot ang layo.

Quick reference: ang mga flags na worth memorahin

Layunin	Command
Sundan ang isang service nang live	journalctl -u <svc> -f
Huling 100 linya	journalctl -n 100
Simula isang oras ang nakalipas	journalctl --since "1 hour ago"
Errors sa boot na ito	journalctl -p err -b
Previous boot	journalctl -b -1
Disk usage ng journal	journalctl --disk-usage
Machine-readable output	journalctl -o json-pretty
Kernel messages lang	journalctl -k

Paano ko pipigilan ang journal na punuin ang disk ko?

Sukatin mo muna ang gastos, tapos i-cap:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # keep newest 500 MB
sudo journalctl --vacuum-time=30d      # keep newest 30 days

Para gawing permanente ang cap, takdaan ng SystemMaxUse=500M ang ilalim ng [Journal] section sa /etc/systemd/journald.conf, tapos sudo systemctl restart systemd-journald. Sa size cap at boot filter sa itaas, nananatiling tool ang journal at hindi mabagal na disk leak.

journalctl vs dmesg vs /var/log — ano ang titingnan ko muna?

• journalctl — kilos ng application at service. Lahat ng ina-asikaso ng systemd ay nandito, indexed at filterable. Default na unang puntahan.
• journalctl -k / dmesg — kernel at hardware: OOM kills, USB resets, disk errors. Kung namatay nang misteryoso ang isang process, hanapin mo muna dito ang OOM killer bago mo isisi sa app.
• /var/log/<app>/ — para lang sa mga apps na may sariling file logging (nginx access logs, PostgreSQL). Kahit noon, ang startup errors ay karaniwang diretso pa rin sa journal.

Umaabot din sa local AI services ang same workflow — kapag na-stall ang isang ollama serve unit, agad na ipinapakita ng journalctl -u ollama -n 100 ang model load failure, tulad ng saklaw sa Ollama vs LM Studio comparison.

Yan ang buong cheat sheet: -u para sa unit, -f para sundan, -n para sa linya, --since para sa oras, -p para sa severity, -b para sa boots. Anim na flags ang sumasagot sa halos bawat tanong sa logs na itatanong sa’yo ng isang Linux box.