Khi debug Linux, mấy lệnh như ps, top, lsof, ss, docker ps cho mình biết cái gì đang chạy. Nhưng thứ mình hay bí nhất lại là: vì sao nó chạy tới giờ.

Để hiểu chuyện đó, thường phải tự ghép thông tin từ nhiều lệnh khác nhau. witr sinh ra để làm phần việc này thay bạn: nó nói thẳng chuỗi nguyên nhân, process này từ đâu ra, ai khởi động và hệ thống nào đang “nuôi” nó, gói gọn trong một output dễ đọc.

witr là gì?

witr là một công cụ dòng lệnh giúp bạn hiểu nguồn gốc và lý do tồn tại của một process trên hệ thống.

Thông thường, khi bạn dùng các công cụ quen thuộc, bạn chỉ biết được:

• Process tên gì?
• PID bao nhiêu?
• Đang chiếm port nào?

Nhưng witr đi xa hơn một bước. Nó cố gắng trả lời những câu hỏi mà người mới rất hay mắc kẹt:

• Process này do ai khởi động
• Hệ thống nào đang giữ nó chạy
• Vì sao kill xong nó lại xuất hiện lại

witr giải quyết vấn đề gì?

Khi mới làm quen với Linux server, bạn rất dễ gặp tình huống này:

• Bạn thấy một process đang chạy
• Bạn không nhớ mình đã chạy nó bao giờ
• Bạn không rõ nó thuộc service nào, hay ai đã khởi động nó

Lúc này, câu hỏi trong đầu thường là: Process này từ đâu ra vậy?

Đây chính là vấn đề cốt lõi mà witr giải quyết. witr không nhằm thay thế các công cụ xem trạng thái. Nó tồn tại để giải thích nguyên nhân tồn tại của process, thứ mà người mới rất khó tự suy ra.

witr tiếp cận vấn đề như thế nào?

Thay vì đưa ra một danh sách thông tin rời rạc, witr cố gắng kể lại câu chuyện của process đó theo một cấu trúc dễ đọc.

Khi bạn hỏi witr về một process, nó sẽ cố giải thích theo các phần:

• Why It Exists: Chuỗi “ai sinh ra ai”, giúp bạn hiểu process này xuất phát từ đâu?
• Source: Thực thể chính đang chịu trách nhiệm giữ process này chạy
• Context: Process đang chạy trong môi trường nào (thư mục, repo, cách bind port…)
• Warnings: Có dấu hiệu bất thường nào cần chú ý hay không

Điểm quan trọng là: witr không chỉ cho bạn dữ liệu, mà cho bạn biết lý do/

Cài đặt nhanh witr

Bạn chỉ cần cài một lần, rồi để đó dùng khi cần.

curl -fsSL https://raw.githubusercontent.com/pranshuparmar/witr/main/install.sh | bash

Kiểm tra:

witr --version

Các câu lệnh witr thường gặp

Phần này không đi theo tình huống phức tạp, mà đi theo cách người mới thật sự hay gõ lệnh, rồi giải thích họ sẽ hiểu được gì sau khi chạy.

Hỏi theo port

Khi gặp lỗi service không start được vì port bị chiếm, phản xạ tự nhiên là hỏi theo port:

witr --port 5000

Sau khi chạy, thứ bạn cần quan tâm không phải mọi dòng output, mà là hai chỗ:

• Source: thằng nào đang chịu trách nhiệm chính
• Why It Exists: chuỗi ai sinh ra ai

Chỉ cần đọc hai phần này, bạn sẽ biết:

• process đó không chạy một mình
• kill tay chỉ xử lý ngọn
• muốn xử lý gốc thì phải quay về đúng hệ đang “nuôi” nó

Nếu đang gấp và chỉ cần chốt hướng, dùng bản rút gọn:

witr --port 5000 --short

Một dòng output ngắn là đủ để bạn quyết định nên debug ở tầng nào.

Hỏi theo PID

Khi bạn đã biết PID (từ bất kỳ lệnh nào), cách hỏi rõ ràng nhất là:

witr --pid 12345

Cách này giúp bạn:

• không bị nhầm process
• đọc được đầy đủ câu chuyện của đúng đối tượng cần điều tra

Đây là cách nên dùng khi:

• tên process trùng nhau
• bạn muốn chắc chắn mình không “đánh nhầm thằng”

Hỏi theo tên process

Cách này tiện, nhưng nếu máy có nhiều process trùng tên, witr sẽ yêu cầu bạn chọn PID cụ thể.

witr node

Điều này nghe có vẻ hơi phiền, nhưng thực ra lại rất tốt cho người mới:

• tránh debug nhầm
• tránh kill nhầm
• tránh làm hỏng thứ không liên quan

Khi chỉ muốn soi nhanh xem có gì không?

Có những lúc process vẫn chạy bình thường, nhưng bạn muốn biết:

• nó có chạy quyền cao không
• có bind public không
• có dấu hiệu bất thường không

Bạn có thể hỏi riêng phần cảnh báo:

witr --pid 12345 --warnings

Hoặc khi nghi do biến môi trường gây ra hành vi lạ:

witr --pid 12345 --env

Đây là cách dùng witr để hiểu trạng thái hệ thống, không chỉ để chữa cháy.

Kết bài

Qua những câu lệnh trên, thứ witr mang lại không chỉ là output, mà là cách suy nghĩ:

• process luôn có nguồn gốc
• luôn có một hệ chịu trách nhiệm
• muốn sửa đúng thì phải hiểu đúng trước

witr giúp người mới không debug theo cảm tính, mà theo nguyên nhân.