Sau khi chương trình chạy: Dịch vụ Linux, Cổng, systemd và Quản trị Log

Nhiều hướng dẫn triển khai kết thúc ngay khi dòng chữ Running xuất hiện trong terminal. Người mới đóng cửa sổ SSH lại thì chương trình tắt ngóm; hoặc khởi động lại VPS xong thì trang web biến mất không dấu vết mà không biết tìm nguyên nhân từ đâu.

"Chương trình chạy được tạm thời" và "dịch vụ có thể duy trì vận hành ổn định" là hai khái niệm hoàn toàn khác biệt. Một dịch vụ trực tuyến lâu dài đòi hỏi sự rõ ràng về tiến trình, cổng mạng, khởi động tự động, cấu hình, nhật ký log và phương án phục hồi.

1. Bản đồ luồng xử lý của một dịch vụ web

Hình dung luồng yêu cầu đến một ứng dụng web tiêu chuẩn:

Trình duyệt người dùng
  ↓ HTTPS 443
Reverse Proxy
  ↓ Localhost 127.0.0.1:3000
Tiến trình ứng dụng (Application Process)
  ↓
Cấu hình, Dữ liệu bền vững & Log

Các khái niệm then chốt:

Cổng mạng không phải là một cánh cửa vật lý, cũng không tự động mở ra chỉ vì bạn vừa cài đặt phần mềm. Kết nối chỉ thành công khi: ứng dụng đang lắng nghe, địa chỉ bind chính xác, tường lửa OS và tường lửa đám mây cho phép, và tuyến mạng bên ngoài thông suốt.

2. Sự khác biệt giữa 127.0.0.1 và 0.0.0.0

Ứng dụng lắng nghe trên 127.0.0.1:3000 nghĩa là chỉ chính máy chủ VPS đó mới kết nối được. Lắng nghe trên 0.0.0.0:3000 nghĩa là nó nhận kết nối trên mọi giao diện mạng IPv4 (có truy cập được từ bên ngoài hay không còn tùy thuộc vào tường lửa).

Đối với ứng dụng web đứng sau Reverse Proxy, cấu hình chuẩn là chỉ cho backend lắng nghe trên localhost:

Internet công cộng chỉ tiếp xúc với cổng 80 / 443;
Cổng 3000 của ứng dụng ẩn hoàn toàn bên trong VPS.

Điều này giúp giảm thiểu tối đa các bề mặt tấn công không cần thiết.

3. Vì sao systemd là bắt buộc

Nếu bạn chạy chương trình trực tiếp trong terminal SSH, tiến trình sẽ gắn liền với phiên đăng nhập đó. systemd là trình quản lý hệ thống và dịch vụ tiêu chuẩn trên Linux hiện đại, định nghĩa rõ:

• Chạy dưới quyền người dùng hệ thống nào;
• Bắt đầu từ thư mục làm việc nào;
• Lệnh thực thi và tham số chính xác;
• Các biến môi trường cần thiết;
• Có tự động khởi động lại khi bị crash không;
• Có tự động chạy khi bật máy không;
• Luồng log chuẩn được chuyển đi đâu để lưu trữ.

Tệp định nghĩa dịch vụ là bản cam kết vận hành giúp việc gỡ lỗi về sau không phụ thuộc vào trí nhớ về các câu lệnh tạm thời.

Kiểm tra trạng thái dịch vụ:

systemctl status example-app

Trạng thái active (running) chỉ chứng minh systemd thấy tiến trình chính còn sống, không đảm bảo ứng dụng đang xử lý yêu cầu HTTP đúng đắn. Bạn vẫn cần kiểm tra cổng và phản hồi thực tế.

4. Quy trình gỡ lỗi theo lớp từ trong ra ngoài

Khi gặp lỗi, đừng vội cài lại từ đầu, hãy kiểm tra tuần tự:

Lớp 1: Trạng thái tiến trình và dịch vụ

systemctl status example-app

Xem dịch vụ có đang chạy không, có bị lặp lại vòng lặp crash không, đang tải unit file nào.

Lớp 2: Nhật ký log của dịch vụ

journalctl -u example-app --since today

Log ghi lại lỗi cú pháp cấu hình, thiếu quyền truy cập tệp, xung đột cổng hoặc không kết nối được cơ sở dữ liệu. Khi nhờ hỗ trợ bên ngoài, hãy che các thông tin nhạy cảm như mật khẩu, cookie, token.

Lớp 3: Cổng đang lắng nghe

ss -lntp

Xem địa chỉ bind TCP và mã tiến trình PID. Đảm bảo ứng dụng thực sự đang chờ kết nối trên đúng địa chỉ và cổng thiết kế.

Lớp 4: Yêu cầu cục bộ trên VPS

curl -I http://127.0.0.1:3000

Nếu gọi nội bộ thất bại, lỗi nằm ở chính ứng dụng hoặc cấu hình cục bộ. Nếu gọi nội bộ thành công nhưng bên ngoài không vào được, hãy kiểm tra Reverse Proxy, DNS và tường lửa.

Lớp 5: Truy cập thực tế từ mạng ngoài

Dùng thiết bị mạng khác truy cập tên miền, kiểm tra HTTPS, mã trạng thái HTTP và nội dung trang.

5. Quy trình triển khai dịch vụ chuẩn mực

1. Ghi lại phiên bản OS, phiên bản ứng dụng, cổng và đường dẫn tệp; 2. Tải phần mềm từ nguồn chính thức và xác thực mã checksum; 3. Chạy ứng dụng bằng người dùng hệ thống chuyên dụng không có đặc quyền root; 4. Phân tách rõ ràng mã nguồn, cấu hình, dữ liệu bền vững và log với quyền hạn phù hợp; 5. Kiểm tra cú pháp cấu hình và chạy thử nội bộ; 6. Quản lý khởi động và tự phục hồi bằng systemd; 7. Chỉ mở các cổng mạng công cộng thực sự cần thiết trên tường lửa; 8. Kiểm tra theo từng lớp: Dịch vụ → Cổng → Cục bộ → Bên ngoài; 9. Khởi động lại toàn bộ VPS để kiểm tra khả năng tự phục hồi; 10. Lưu lại phương án rollback và tài liệu khôi phục.

6. Thay đổi một biến số tại một thời điểm

Tuân thủ vòng lặp an toàn:

Sao lưu cấu hình cũ → Sửa 1 mục → Kiểm tra cú pháp → Reload/Restart → Xem log → Kiểm tra yêu cầu thực tế

Nâng cấp ứng dụng, đổi cổng, sửa phân quyền, đổi tường lửa và đổi tên miền cùng một lúc sẽ khiến bạn không thể biết nguyên nhân lỗi xuất phát từ đâu khi có sự cố.

7. Tổng kết

Một dịch vụ Linux có thể duy trì lâu dài không phải là "một câu lệnh cài đặt ăn liền", mà là chuỗi bằng chứng có thể kiểm chứng: systemd kiểm soát tiến trình, ứng dụng lắng nghe đúng địa chỉ, log ghi nhận rõ ràng, truy cập nội bộ và bên ngoài đều vượt qua kiểm tra.

Câu hỏi thường gặp (FAQ)

Dịch vụ báo running mà trang web vẫn không mở được là sao?

Tiến trình còn sống không đồng nghĩa với việc nó phản hồi web bình thường. Hãy kiểm tra địa chỉ lắng nghe, kết quả curl nội bộ, Reverse Proxy, tường lửa, DNS và SSL.

Có cần khởi động lại cả VPS sau khi sửa cấu hình không?

Thường là không. Hầu hết các dịch vụ đều hỗ trợ nạp lại cấu hình (reload) hoặc chỉ khởi động lại chính dịch vụ đó (restart).

Có phải log càng nhiều càng tốt không?

Không. Log cần đủ để định vị sự cố, nhưng phải có cơ chế xoay vòng (logrotate) và giới hạn dung lượng để tránh làm đầy ổ đĩa.

Tài liệu tham khảo

• systemd: Tài liệu systemd.service
• systemd: Tài liệu journalctl
• Ubuntu Server: Tường lửa
• IANA: Danh mục số hiệu cổng và tên dịch vụ