สรุปคำสั่ง journalctl: ดู กรอง และติดตาม log บน Linux

journalctl ในหนึ่งบรรทัด: journalctl -u <service> -f ติดตาม log ของ service แบบสด, journalctl -u <service> -n 100 แสดง 100 บรรทัดสุดท้าย และ journalctl --since "1 hour ago" แสดงทุกอย่างที่เกิดขึ้นล่าสุด สามคำสั่งนี้ครอบคลุม 90% ของช่วงเวลา “ทำไม service นี้ถึงล่ม” ที่เหลือของ cheat sheet คือรูปแบบคำสั่ง copy-paste ที่ช่วยให้คุณไม่ต้องกลับไปอ่าน man page ตอนตีสอง — การกรองตาม unit เวลา priority และรอบบูต รวมถึงคำสั่งเก็บกวาดที่กันไม่ให้ journal กินดิสก์ ทุกคำสั่งด้านล่างรันได้ทันทีบน distro ที่ใช้ systemd (Ubuntu, Debian, Fedora, Arch)

journalctl คืออะไร แล้วทำไมไม่อ่าน /var/log/syslog ตรง ๆ?

ระบบ log ของ Linux สมัยเก่าเขียนไฟล์ข้อความลงใต้ /var/log — syslog, auth.log, messages systemd เปลี่ยนมาเป็น the journal: log แบบไบนารีที่มีดัชนี ดูแลโดย systemd-journald grep ธรรมดาอ่านไม่ได้ journalctl คือประตูหน้าบ้านเส้นเดียว แลกกับสิ่งที่ได้คือการกรองตาม service เวลา รอบบูต และระดับความรุนแรง โดยไม่ต้องออกแรงเขียน regex

โมเดลความคิดง่ายมาก: journal เก็บ ทุกอย่าง และ journalctl คือเครื่องมือสอบถาม service ไม่จำเป็นต้องมีไฟล์ log ของตัวเอง — ทุกอย่างที่มันเขียนลง stdout/stderr ขณะทำงานภายใต้ systemd จะไหลลง journal อัตโนมัติ นี่คือเหตุผลที่ journalctl -u nginx ใช้ได้แม้คุณจะไม่รู้ด้วยซ้ำว่า nginx ตั้งค่า error log ไว้ที่ไหน

ข้อควรระวังหนึ่ง: ในบางเครื่องที่ติดตั้งแบบมินิมอล journal จะเป็นแบบ volatile (เก็บใน /run และถูกลบเมื่อรีบูต) เพราะ /var/log/journal ไม่มีอยู่ แก้ครั้งเดียวจบ:

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

จะดู 100 บรรทัดสุดท้ายของ log ได้อย่างไร?

-n จำกัดผลลัพธ์ไว้ที่ N บรรทัดล่าสุด (ค่าเริ่มต้น 10):

journalctl -n 100                      # 100 บรรทัดสุดท้ายของทุกอย่าง
journalctl -u nginx -n 100             # 100 บรรทัดสุดท้ายของ unit เดียว
journalctl -n 100 --no-pager           # พิมพ์แล้วออก — เหมาะกับการ pipe

--no-pager สำคัญกว่าที่ดู: ถ้าไม่ใส่ journalctl จะเปิด less ขึ้นมา แล้วสคริปต์ ท่อ หรือคำสั่งบรรทัดเดียวผ่าน ssh ของคุณจะค้างรอกดแป้น คำสั่งไหนที่จะส่งผลลัพธ์ต่อไปยังท่อ ให้ใส่ตัวเลือกนี้ไว้เสมอ

จะติดตาม log แบบสดเหมือน tail -f ได้อย่างไร?

-f คือ tail -f ของ journalctl — สตรีมรายการใหม่ทันทีที่เกิดขึ้น:

journalctl -f                    # ทุกอย่าง แบบสด
journalctl -u sshd -f            # เฉพาะ SSH daemon แบบสด
journalctl -u ollama -f -n 50    # แบบสด แต่เริ่มจาก 50 บรรทัดสุดท้าย

นี่คือคำสั่งที่รันไว้ในเทอร์มินัลที่สองขณะรีสตาร์ต service ในเทอร์มินัลแรก: systemctl restart nginx ในหน้าต่างหนึ่ง journalctl -u nginx -f อีกหน้าต่าง แล้วสาเหตุการล่มมักประกาศตัวเองภายในไม่กี่วินาที ผมรันวงจรนี้บน homelab ทุกครั้งที่ container หรือ service ใดแสดงอาการ

จะดู log ของ service เฉพาะตัวได้อย่างไร?

-u กรองตาม unit ของ systemd:

journalctl -u nginx                    # unit เดียว ทั้งประวัติ
journalctl -u nginx -u redis           # หลาย unit พร้อมกัน
journalctl _SYSTEMD_UNIT=nginx.service # ทางเลือกแบบแมตช์เป๊ะ

unit บางตัวสร้าง unit ช่วยที่เก็บผลลัพธ์สำคัญไว้ — บางทีเว็บแอปที่ล่มกลับบันทึก error ตัวจริงไว้ใต้ unit อื่น ถ้า -u <service> ไม่เห็นอะไรเลยทั้งที่ service ชัดเจนว่าทำงานอยู่ ให้หาชื่อ unit จริงก่อน:

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

รูปแบบ -u เดียวกันใช้กับ timer ได้ (systemctl list-timers แสดงชื่อ) และกับ service ระดับผู้ใช้ — อะไรที่รันใต้ systemd --user ให้เติม --user:

journalctl --user -u pipewire -n 50

จะกรอง log ตามเวลาได้อย่างไร?

--since และ --until รับ timestamp ได้ แต่ยังเข้าใจถ้อยคำแบบสัมพัทธ์ที่หยวนหย่อนด้วย:

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

จับคู่ช่วงเวลากับ unit แล้วคุณจะได้การคัดกรองเหตุการณ์ในหนึ่งบรรทัด: “API บันทึกอะไรไว้ระหว่าง 09:00 ถึงตอนที่มันล้ม” สำหรับเครื่องเดียว เร็วกว่าตัวรวบรวม log ตัวใด

จะแสดงเฉพาะ error (หรือ warning) ได้อย่างไร?

-p กรองตาม priority โดยใช้ชื่อระดับของ syslog:

journalctl -p err -b              # เฉพาะ error ตั้งแต่บูตนี้
journalctl -p warning..alert -u nginx   # ช่วงของระดับความรุนแรง

ลำดับ priority จากมากไปน้อย: emerg, alert, crit, err, warning, notice, info, debug เมื่อเครื่อง “ทำท่าประหลาด” journalctl -p err -b --since today คือการเช็กที่เร็วที่สุด — ตอบคำถาม “มีอะไรพังจริงไหม?” โดยไม่มีเสียงรบกวนจากบรรทัด info ประจำวัน

จะดู log จากรอบบูตก่อนหน้าได้อย่างไร?

service ที่ล่มตอนเริ่มทำงานจะเขียน log ก่อน รอบบูตปัจจุบัน และ journalctl แสดงเฉพาะรอบปัจจุบันโดยไม่บอก -b เลือกรอบบูต:

journalctl -b                 # เฉพาะรอบบูตปัจจุบัน
journalctl -b -1              # รอบก่อนหน้า
journalctl -b -1 -u sshd      # ทำไม SSH ถึงตายเมื่อครั้งก่อน
journalctl --list-boots       # ดัชนีรอบบูตที่เก็บไว้

นี่คือตัวเลือกที่มีประโยชน์ที่สุดสำหรับกรณี “มันพัง ผมรีบูต แล้วตอนนี้มองไม่เห็น error” — error ยังอยู่ตรงนั้น รอบบูตถอยหลังไปหนึ่งรอบ

คู่มือด่วน: ตัวเลือกที่ควรจำ

วัตถุประสงค์	คำสั่ง
ติดตาม service เดียวแบบสด	journalctl -u <svc> -f
100 บรรทัดสุดท้าย	journalctl -n 100
ตั้งแต่หนึ่งชั่วโมงก่อน	journalctl --since "1 hour ago"
error ของรอบบูตนี้	journalctl -p err -b
รอบบูตก่อนหน้า	journalctl -b -1
เนื้อที่ที่ journal ใช้	journalctl --disk-usage
ผลลัพธ์แบบเครื่องอ่าน	journalctl -o json-pretty
เฉพาะข้อความจาก kernel	journalctl -k

จะกันไม่ให้ journal กินดิสก์ได้อย่างไร?

ดูค่าใช้จ่ายก่อน แล้ววางเพดาน:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # เก็บ 500 MB ล่าสุด
sudo journalctl --vacuum-time=30d      # เก็บ 30 วันล่าสุด

ให้เพดานถาวร ให้ตั้ง SystemMaxUse=500M ใต้หัวข้อ [Journal] ใน /etc/systemd/journald.conf แล้ว sudo systemctl restart systemd-journald ระหว่างเพดานขนาดกับตัวกรองรอบบูตข้างบน journal จะยังเป็นเครื่องมือ ไม่ใช่น้ำซึมดิสก์แบบช้า ๆ

journalctl vs dmesg vs /var/log — เช็กอะไรก่อน?

• journalctl — พฤติกรรมของแอปและ service ทุกอย่างที่ systemd ดูแลอยู่ที่นี่หมด มีดัชนีและกรองได้ เป็นจุดหยุดแรกโดยดีฟอลต์
• journalctl -k / dmesg — kernel และฮาร์ดแวร์: การ kill ด้วย OOM, USB reset, ความผิดพลาดของดิสก์ ถ้า process ตายแบบลึกลับ ให้ตามหา OOM killer ที่นี่ก่อนโทษแอป
• /var/log/<app>/ — เฉพาะแอปที่จัดการไฟล์ log ของตัวเอง (access log ของ nginx, PostgreSQL) แม้กระนั้น error ตอนเริ่มทำงานก็มักไหลลง journal เหมือนเดิม

ขั้นตอนการทำงานเดียวกันใช้กับ AI service ในเครื่องได้ด้วย — เมื่อ unit ของ ollama serve ค้าง journalctl -u ollama -n 100 จะชี้ความล้มเหลวในการโหลดโมเดลทันที ตามที่กล่าวไว้ใน การเปรียบเทียบ Ollama กับ LM Studio

ทั้งหมดของ cheat sheet นี้คือ: -u สำหรับ unit, -f สำหรับติดตาม, -n สำหรับจำนวนบรรทัด, --since สำหรับเวลา, -p สำหรับระดับ, -b สำหรับรอบบูต หกตัวเลือกนี้ครอบคลุมแทบทุกคำถามเรื่อง log ที่เครื่อง Linux จะถามคุณ