journalctl Cheat Sheet: Tail, Lọc và Theo Dõi Log Linux

journalctl trong một dòng: journalctl -u <service> -f theo dõi log của một service đang chạy, journalctl -u <service> -n 100 hiện 100 dòng cuối, và journalctl --since "1 hour ago" hiện mọi thứ gần đây. Vậy là xong 90% những khoảnh khắc “sao service này sập”. Phần còn lại của cheat sheet là các pattern copy-paste giúp bạn khỏi phải đọc lại man page lúc 2 giờ sáng — lọc theo unit, thời gian, priority và boot, cùng mấy lệnh dọn dẹp ngăn journal ăn hết ổ đĩa. Mọi lệnh dưới đây chạy nguyên bản trên bất kỳ distro systemd nào (Ubuntu, Debian, Fedora, Arch).

journalctl là gì và sao không đọc thẳng /var/log/syslog?

Logging Linux kiểu cũ ghi file text thuần dưới /var/log — syslog, auth.log, messages. systemd thay điều đó bằng journal: log nhị phân có index, quản lý bởi systemd-journald. grep thường không đọc được nó; journalctl là cánh cửa duy nhất, và đổi lại bạn có lọc theo service, thời gian, boot và mức độ nghiêm trọng mà không cần vặn vẹo regex.

Mô hình tư duy đơn giản: journal lưu mọi thứ, còn journalctl là tool truy vấn. Service không cần file log riêng — mọi thứ nó ghi ra stdout/stderr khi chạy dưới systemd đều tự động rơi vào journal. Vì thế journalctl -u nginx chạy được cả khi bạn chẳng biết nginx cấu hình error log ở đâu.

Một lưu ý: trên một số bản cài tối giản, journal là volatile (nằm trong /run, biến mất khi reboot) vì /var/log/journal không tồn tại. Sửa một lần là xong:

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

Xem 100 dòng cuối của log bằng cách nào?

-n giới hạn output ở N dòng mới nhất (mặc định là 10):

journalctl -n 100                      # 100 dòng cuối của mọi thứ
journalctl -u nginx -n 100             # 100 dòng cuối của một unit
journalctl -n 100 --no-pager           # in rồi thoát — hoàn hảo để pipe

--no-pager quan trọng hơn vẻ ngoài của nó: thiếu nó journalctl mở less và script, pipe hay one-liner qua ssh của bạn sẽ treo chờ phím. Lệnh nào bạn định pipe tiếp nên mang nó theo.

Theo dõi log trực tiếp kiểu tail -f bằng cách nào?

Cờ -f chính là tail -f của journalctl — nó stream entry mới ngay khi xuất hiện:

journalctl -f                    # mọi thứ, trực tiếp
journalctl -u sshd -f            # chỉ daemon SSH, trực tiếp
journalctl -u ollama -f -n 50    # trực tiếp, nhưng bắt đầu bằng 50 dòng cuối

Đây là lệnh để chạy ở terminal thứ hai trong khi bạn restart service ở terminal đầu: systemctl restart nginx ở pane này, journalctl -u nginx -f ở pane kia, và thủ phạm gây sập thường tự lộ diện trong vài giây. Mình chạy đúng vòng lặp này trên homelab mỗi khi container hay service có biểu hiện lạ.

Xem log của một service cụ thể bằng cách nào?

-u lọc theo systemd unit:

journalctl -u nginx                    # một unit, toàn bộ lịch sử
journalctl -u nginx -u redis           # nhiều unit cùng lúc
journalctl _SYSTEMD_UNIT=nginx.service # cách khớp chính xác tuyệt đối

Unit có thể sinh ra các unit phụ giữ phần output thú vị — một web app lỗi thỉnh thoảng ghi lỗi thật dưới một unit khác. Nếu -u <service> không ra gì nhưng service rõ ràng đang chạy, tìm đúng tên unit đã:

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

Cùng pattern -u đó dùng được cho timer (systemctl list-timers hiện tên) và user service — thứ gì chạy dưới systemd --user thì thêm --user:

journalctl --user -u pipewire -n 50

Lọc log theo thời gian bằng cách nào?

--since và --until nhận timestamp, nhưng cũng chấp nhận cách nói tương đối dễ dãi:

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

Ghép khung thời gian với một unit là bạn có sơ cứu sự cố trong một dòng: “API đã log gì giữa 09:00 và lúc nó gục?” Nhanh hơn bất kỳ log aggregator nào với một máy đơn lẻ.

Chỉ hiện error (hoặc warning) bằng cách nào?

-p lọc theo priority, dùng tên mức severity của syslog:

journalctl -p err -b              # chỉ error, tính từ boot này
journalctl -p warning..alert -u nginx   # một khoảng severity

Priority theo thứ tự giảm dần: emerg, alert, crit, err, warning, notice, info, debug. Khi máy “hành xử kỳ lạ”, journalctl -p err -b --since today là phép kiểm tra nhanh nhất — nó trả lời câu hỏi “có gì đang fail thật không?” mà không lẫn nhiễu từ các dòng info thường ngày.

Xem log của lần boot trước bằng cách nào?

Service sập lúc khởi động tạo log line trước boot hiện tại, và journalctl lặng lẽ chỉ hiện boot hiện tại. -b chọn boot:

journalctl -b                 # chỉ boot hiện tại
journalctl -b -1              # boot trước
journalctl -b -1 -u sshd      # vì sao SSH chết lần trước
journalctl --list-boots       # danh mục các boot đã lưu

Đây là cờ hữu dụng nhất cho tình huống “nó hỏng, mình reboot và giờ không thấy lỗi đâu” — lỗi vẫn nằm đó, cách lại một boot.

Tham khảo nhanh: những cờ đáng thuộc

Mục tiêu	Lệnh
Theo dõi một service trực tiếp	journalctl -u <svc> -f
100 dòng cuối	journalctl -n 100
Từ một giờ trước	journalctl --since "1 hour ago"
Error từ boot này	journalctl -p err -b
Boot trước	journalctl -b -1
Dung lượng đĩa của journal	journalctl --disk-usage
Output máy đọc được	journalctl -o json-pretty
Chỉ message của kernel	journalctl -k

Chặn journal làm đầy ổ đĩa bằng cách nào?

Xem nó tốn bao nhiêu, rồi chặn lại:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # giữ 500 MB mới nhất
sudo journalctl --vacuum-time=30d      # giữ 30 ngày mới nhất

Để giới hạn vĩnh viễn, đặt SystemMaxUse=500M dưới section [Journal] trong /etc/systemd/journald.conf, rồi sudo systemctl restart systemd-journald. Có trần dung lượng và bộ lọc boot ở trên, journal vẫn là một công cụ chứ không phải vết rò đĩa chậm.

journalctl vs dmesg vs /var/log — kiểm tra đâu trước?

• journalctl — hành vi ứng dụng và service. Mọi thứ systemd quản lý đều ở đây, có index, lọc được. Điểm dừng đầu tiên mặc định.
• journalctl -k / dmesg — kernel và phần cứng: OOM kill, reset USB, lỗi đĩa. Nếu một process chết bí ẩn, tìm OOM killer ở đây trước khi đổ thừa app.
• /var/log/<app>/ — chỉ dành cho app tự ghi log ra file (access log của nginx, PostgreSQL). Dù vậy, lỗi khởi động thường vẫn rơi vào journal.

Cùng workflow đó áp dụng cho dịch vụ AI local — khi unit ollama serve đứng im, journalctl -u ollama -n 100 hiện ngay lỗi load model, như đã nói trong so sánh Ollama vs LM Studio.

Hết cheat sheet: -u cho unit, -f để theo dõi, -n cho số dòng, --since cho thời gian, -p cho severity, -b cho boot. Sáu cờ phủ gần như mọi câu hỏi log mà một máy Linux có thể hỏi bạn.