Quan sát tiến trình Linux bằng ps, top và proc; đọc bộ nhớ, log và trạng thái dịch vụ, phân biệt dữ kiện đã kiểm thử với hướng dẫn systemd trên VM.
Một ứng dụng báo lỗi chưa cho biết lỗi nằm ở cấu hình, tiến trình hay dữ liệu đầu vào. Trong bài này, bạn học cách tìm đúng loại dữ kiện trước khi can thiệp: chương trình nằm ở đâu, tiến trình nào đang chạy, bộ nhớ được báo cáo thế nào và nhật ký nào có thể giải thích sự kiện.
Sau bài học, bạn có thể phân biệt tệp chương trình với tiến trình; đọc PID, PPID và trạng thái cơ bản; quan sát bộ nhớ bằng free; giải thích vai trò của /etc, /var/log, /proc và journal.
Bạn cần biết đường dẫn, pipe và biến Bash. Lab đã chạy trên container Ubuntu 26.04.1 LTS ARM64 với procps, kiểm tra ngày 23/10/2026. Container này không có systemctl và journalctl. Các lệnh systemd phía dưới là hướng dẫn đọc trên VM có systemd, đã đối chiếu tài liệu chính thức nhưng chưa được chạy trong lab VM của bài. Không lấy kết quả container làm bằng chứng dịch vụ của máy chủ hoạt động.
Tệp thực thi là chương trình được lưu trữ; tiến trình là một lần thực thi đang tồn tại. Cấu hình quyết định hành vi, còn nhật ký ghi lại những sự kiện mà ứng dụng hoặc hệ thống chọn lưu.
| Vị trí | Vai trò thường gặp | Điều cần kiểm tra |
|---|---|---|
/usr/bin, /usr/sbin |
Chương trình do hệ thống cung cấp | Gói và phiên bản nào sở hữu? |
/usr/local |
Phần mềm cài đặt cục bộ | Có thuộc quản lý gói không? |
/etc |
Cấu hình cấp hệ thống | Chương trình thực sự đọc tệp nào? |
| Thư mục home | Dữ liệu và cấu hình người dùng | Đúng tài khoản và profile chưa? |
/var/log |
Nhiều loại nhật ký | Định dạng, quyền và thời hạn lưu? |
/proc |
Giao diện dữ liệu kernel | Đang quan sát PID và namespace nào? |
Trên hệ thống gộp /usr, /bin hoặc /sbin có thể là liên kết. Dùng ls -ld /bin /sbin để xem máy thực tế; đừng kết luận có hai bản chương trình chỉ từ hai đường dẫn. Dùng command -v để biết shell chọn lệnh nào, rồi đối chiếu quản lý gói khi cần xác định nguồn.
Không phải mọi cấu hình đều nằm trực tiếp trong /etc. Ứng dụng có thể dùng biến môi trường, tham số khởi chạy hoặc thư mục người dùng. Sửa một tệp có tên hợp lý chưa chứng minh ứng dụng đã đọc nó.
PID là số nhận diện tiến trình trong phạm vi quan sát; PPID chỉ tiến trình cha. PID có thể được tái sử dụng sau khi tiến trình kết thúc. Vì vậy, ghi một PID hôm qua rồi gửi tín hiệu hôm nay có thể tác động nhầm đối tượng. Kiểm tra lại tên, người sở hữu và bối cảnh ngay trước thao tác.
Lệnh sau chụp danh sách với những trường đã chọn:
ps -eo pid,ppid,user,stat,comm
Theo manual ps của procps-ng, comm là tên lệnh, không phải toàn bộ tham số. Trường trạng thái có thể gồm nhiều ký tự. Với procps, R chỉ đang chạy hoặc sẵn sàng chạy; S thường là ngủ có thể ngắt; D là chờ không thể ngắt, thường liên quan I/O; Z là zombie, tiến trình đã kết thúc nhưng cha chưa thu hồi trạng thái. Một trạng thái đơn lẻ không đủ chẩn đoán nguyên nhân.
top cung cấp màn hình cập nhật. Nhấn q để thoát; trong lab tự động dùng top -b -n 1 lấy một lần. CPU cao trong một ảnh chưa chứng minh treo máy: cần xem thời lượng, tải công việc và phản hồi ứng dụng. Một zombie cũng không phải tiến trình đang liên tục tiêu thụ CPU; gửi SIGKILL cho nó không giải quyết việc tiến trình cha chưa thu hồi.
Manual free của procps-ng giải thích các trường bộ nhớ; free -h trình bày chúng theo đơn vị dễ đọc. Linux tận dụng RAM cho cache; vì vậy free thấp không tự động có nghĩa thiếu RAM. Cột available ước lượng lượng bộ nhớ có thể dành cho ứng dụng mới mà không cần swap, hữu ích hơn khi đọc cùng xu hướng và triệu chứng.
Bộ nhớ ảo của tiến trình không đồng nghĩa toàn bộ dữ liệu đang chiếm RAM vật lý. Trong top, các cột bộ nhớ có ý nghĩa khác nhau và có thể chứa vùng chia sẻ. Không cộng đơn giản các số của mọi tiến trình để suy ra RAM duy nhất đã sử dụng.
Trong container, số liệu toàn hệ thống do công cụ đọc có thể không phản ánh chính xác hạn mức cgroup của container. Khi ticket nói ứng dụng bị dừng vì bộ nhớ, cần bổ sung giới hạn tài nguyên và sự kiện của nền tảng. Bài Essentials chỉ đặt câu hỏi đúng, chưa thay thế điều tra OOM hoặc phân tích bộ nhớ chuyên sâu.
Thực hiện trong Bash của lab riêng. sleep tạo công việc ít tác động, đủ thời gian đọc trạng thái. Không thay PID dưới đây bằng PID dịch vụ thật.
sleep 60 &
worker=$!
ps -p "$worker" -o pid,ppid,user,stat,comm
grep -E '^(Name|State|Pid|PPid|Uid|VmRSS):' "/proc/$worker/status"
free -h
top -b -n 1
$! lấy PID công việc nền vừa tạo. Kết quả mong đợi: ps có tên sleep; /proc/<PID>/status cung cấp dữ kiện của chính tiến trình ấy.
Bây giờ kết thúc đúng công việc thử nghiệm:
kill -TERM "$worker"
wait "$worker"
printf 'Trạng thái wait: %s\n' "$?"
Tín hiệu TERM yêu cầu kết thúc; chương trình có thể xử lý nó. Với sleep trong lần kiểm tra bằng Bash này, wait trả 143, tức quy ước 128 cộng số tín hiệu 15. Đây là kết quả của fixture, không phải mã bắt buộc cho mọi ứng dụng. Nếu tự chờ quá 60 giây, tiến trình có thể đã kết thúc bình thường và kết quả sẽ khác.
kill không luôn có nghĩa ép chết ngay. SIGKILL không cho tiến trình tự dọn dẹp; dùng tùy tiện có thể làm mất dữ liệu đang xử lý. Với dịch vụ được quản lý, cần xem trình quản lý dịch vụ và tác động tới người dùng thay vì săn PID rồi gửi tín hiệu hàng loạt.
/proc là giao diện động, không phải bản sao lưuTheo tài liệu kernel về procfs, /proc cung cấp giao diện tới cấu trúc dữ liệu kernel; các thư mục mang PID chứa thông tin tiến trình. Trong lab, thư mục của sleep biến mất sau khi tiến trình được kết thúc và thu hồi. Sao chép cây /proc không tạo bản sao lưu có thể phục hồi một ứng dụng đang chạy.
Một số mục liên quan bộ nhớ và môi trường có thể chứa dữ liệu nhạy cảm; quyền đọc còn phụ thuộc cấu hình và quan hệ giữa các tiến trình. Đừng đính kèm toàn bộ environ, dòng lệnh hoặc nội dung bộ nhớ vào ticket. Bài này chỉ đọc những trường trạng thái đã chọn, không đọc /proc/<PID>/mem hoặc ghi vào /proc/sys.
Các thư mục /boot, /dev và /sys đã xuất hiện ở bài phần cứng: lần lượt liên quan dữ liệu khởi động, giao diện thiết bị và mô hình thiết bị kernel. Container có thể chỉ nhìn thấy một phần. Cây thư mục trống không chứng minh máy vật lý không có kernel hay thiết bị.
Một log hữu ích cần được đặt cạnh thời điểm lỗi, múi giờ, tên máy, ứng dụng và thao tác của người dùng. Hai sự kiện gần nhau có thể chỉ trùng thời gian. Hãy tìm bằng chứng nối chúng, chẳng hạn cùng request ID, cùng dịch vụ hoặc cùng lần khởi động.
Tạo log văn bản giả lập để luyện cách đọc, không dùng dữ liệu khách hàng:
work=$(mktemp -d)
printf '%s\n' \
'2026-10-23T10:00:00+07:00 demo: request accepted' \
'2026-10-23T10:00:01+07:00 demo: missing fixture' > "$work/demo.log"
tail -n 1 "$work/demo.log"
Kết quả là dòng missing fixture. Đây là dữ liệu tự tạo, không phải lỗi đã quan sát trên hệ thống thật. tail phù hợp log văn bản; journal và các cơ sở dữ liệu đăng nhập dạng nhị phân cần công cụ tương ứng. Ví dụ, last có thể đọc dữ liệu wtmp nếu hệ thống cung cấp, nhưng thiếu tệp không chứng minh chưa có ai đăng nhập.
dmesg đọc bộ đệm thông điệp kernel khi được cấp quyền. Nếu bị từ chối, ghi nhận quyền hạn; không hạ cấu hình bảo vệ để hoàn thành bài. Các tệp /var/log/syslog, auth.log hoặc messages phụ thuộc bộ thu log và cấu hình.
Chỉ thực hiện các truy vấn này trên VM dùng systemd có công cụ tương ứng. Trước hết xem ps -p 1 -o comm= và phiên bản systemctl --version. Tài liệu online latest được đọc ngày cập nhật bài đang mang phiên bản 262; không suy ra VM Ubuntu đã cài phiên bản đó. Tra man systemctl trên chính máy khi có khác biệt.
systemctl list-units --type=service --all --no-pager
systemctl list-unit-files --type=service --no-pager
Theo manual systemctl, hai danh sách phục vụ việc xem unit trong bộ nhớ và tệp unit đã cài. Chọn một tên thực sự xuất hiện rồi thay vào ví dụ sau:
systemctl status TEN.service --no-pager
journalctl -b -u TEN.service -n 50 --no-pager
status tóm tắt trạng thái unit, không thay kiểm tra chức năng ứng dụng. active chưa chứng minh người dùng truy cập thành công. journalctl truy vấn journal; -b giới hạn lần khởi động hiện tại, -u theo unit, -n giới hạn số mục cuối. Phạm vi kết quả phụ thuộc quyền và log còn được giữ, như manual journalctl mô tả. Không có mục khớp chưa chứng minh chưa từng có lỗi.
Bài này không yêu cầu restart hay stop dịch vụ. Những thao tác đó có thể ngắt phiên người dùng và làm mất bằng chứng tạm thời; cần hiểu tác động trước khi áp dụng trên máy làm việc.
free thấp có đủ kết luận thiếu RAM không? Cần xem available, xu hướng, giới hạn và triệu chứng.auth.log có phải không có sự kiện xác thực? Cần kiểm tra nguồn ghi log và chính sách thực tế.Một ticket tốt ghi môi trường, thời điểm, lệnh đọc đã chạy, phần kết quả đã che dữ liệu nhạy cảm và điều chưa kiểm chứng. Giữ riêng quan sát với giả thuyết để người tiếp nhận biết bước tiếp theo cần xác nhận gì.
Khung tham chiếu: giáo trình LPI Linux Essentials 010-160 tiếng Việt, mục 4.3, trang in 283–324, trang PDF 292–333. Bài viết, fixture và hình được biên soạn độc lập. Đối chiếu thêm mục tiêu Linux Essentials do LPI công bố; mục 014.3 của 010-200 hiện bao gồm tiến trình, dịch vụ và nhật ký. Bài giữ ánh xạ giáo trình 4.3, bổ sung nội dung hiện hành theo phạm vi này.
Bằng chứng lab gồm quan sát PID tự tạo, TERM, wait, /proc, free, top và log văn bản giả lập. Chưa kiểm thử systemd/journal trên VM, thay đổi dịch vụ, khôi phục boot hay điều tra sự cố production.
Thực hành Linux với ticket giả lập: tạo script đếm, kiểm tra lỗi, giới hạn dữ liệu, phục hồi TAR và xác minh báo cáo HTTP loopback bằng so sánh byte.
Hiểu thư mục tạm và tệp đặc biệt Linux; thử mktemp, sticky bit, hard link và symlink, kiểm tra đích sau di chuyển và phân biệt liên kết với backup.
Đọc quyền tệp Linux, owner và group; thử chmod, chown, search thư mục và umask bằng tài khoản không root, phân biệt ghi nội dung với xóa tên tệp.
Tạo người dùng Linux và nhóm trong lab riêng; kiểm tra home, skeleton, nhóm bổ sung, khóa mật khẩu và phạm vi xóa tài khoản trước khi áp dụng thực tế.