Khi có gì đó không ổn

Đây là tài liệu hướng dẫn dùng MixEngine qua dòng lệnh mix. Nếu bạn muốn thao tác bằng giao diện đồ họa cho dễ hơn, hãy tải ứng dụng MixDB tại https://lab.mixnz.com/#mixdb. MixDB làm việc trên cùng một MixEngine, nên mọi khái niệm trong cẩm nang này vẫn áp dụng.

Bắt đầu từ đây

mix doctor

Lệnh này kiểm tra máy và cho biết có gì sai. Nó chỉ báo cáo, không sửa gì trừ khi bạn yêu cầu, và thoát với mã khác không khi phát hiện vấn đề, nên script cũng dùng được.

mix doctor --repair

Sửa mọi thứ có thể sửa. Những gì nằm trong home của MixEngine được sửa ngay. Những gì cần quyền quản trị được xếp vào hàng đợi, hiện ra cho bạn xem, rồi cấp quyền trong một hộp thoại cho cả đợt. --yes bỏ qua bước xác nhận trước hộp thoại đó.

Bốn câu hỏi người dùng hay gặp

"Có gì đang chạy không?"

mix status
mix service list

status nói về daemon: phiên bản, thư mục home, và nó đang giám sát gì. service list liệt kê từng service và trạng thái của mỗi cái.

"Sao tên miền này không mở được?"

mix domain status blog.test

Bốn câu hỏi được trả lời riêng rẽ thay vì một kết luận chung: tên đã được khai báo chưa, nó được định tuyến bằng cách nào, hiện tại nó có phân giải được trên máy này không, và có gì đang trả lời ở đó không. Câu nào trả lời no thì đó là chỗ cần sửa.

"Sao ổ khóa không xanh?"

mix cert status
mix cert ca-status

cert status mở một kết nối thật và báo lại chứng chỉ thực sự được đưa ra, tức là thứ duy nhất trình duyệt nhìn thấy. ca-status cho biết CA là gì. Nếu CA chưa được tin cậy, mix doctor --repair sẽ đưa nó trở lại.

"Đây là PHP nào, và vì sao?"

mix runtime resolve php

Phiên bản mà thư mục này dùng, và nguồn nào trong bốn nguồn quyết định điều đó. Vế sau là thứ bạn cần khi câu trả lời không như mong đợi.

Đọc log

mix service logs caddy --follow
mix service logs mariadb@main -n 200

--follow vẫn tiếp tục khi service crash và được khởi động lại, vì thứ đang được theo dõi là service chứ không phải một lần chạy của tiến trình. Log của chính daemon nằm ở logs/daemon.log trong home của MixEngine.

Với các thao tác dài, như cài đặt hay áp dụng blueprint, hãy xem ở job:

mix job list
mix job status <id>
mix job logs <id>

mix job logs chỉ trả lời cho job chạy chương trình của người khác, hiện tại nghĩa là blueprint chạy lệnh scaffold của nó. Mọi việc khác một job làm đều được báo qua tiến độ và kết quả, và lệnh nói rõ như vậy thay vì giả vờ output bị mất.

Các tình huống thường gặp

Cổng đã bị chiếm. Có thứ gì khác trên máy đang dùng nó. Với service mới, dùng mix service create --port để chọn cổng khác. Với service đã có, xóa rồi tạo lại trên cổng khác; thư mục dữ liệu được giữ nguyên.

Daemon không khởi động. Đọc logs/daemon.log trong home. mix status --no-autostart hỏi xem có daemon đang chạy không mà không khởi động cái mới. Đó là câu hỏi đúng khi bạn đang chẩn đoán chứ không phải đang làm việc.

Lệnh cần một phiên bản chưa cài. MixEngine nói rõ và nêu đúng lệnh mix runtime install cần gõ. Nếu bạn yêu cầu một khoảng phiên bản thì nó không biết phiên bản nào thỏa mãn, nên chỉ bạn sang mix runtime available.

Có gì đó xin quyền quản trị và bạn đã từ chối. Không có gì bị áp dụng nửa chừng. mix elevation status cho biết còn gì đang chờ, và mix elevation grant hỏi lại.

Khi chính MixEngine gặp bug

Nếu daemon gặp bug trong mã của chính nó, nó ghi một file nhỏ vào logs/crashes/ trong home của MixEngine. mix doctor cho bạn biết có file như vậy, dưới dạng ghi chú chứ không phải vấn đề, nên không làm đổi mã thoát của lệnh.

Trong file có gì: bug xảy ra ở đâu trong mã nguồn của MixEngine, tên các hàm xung quanh, phiên bản đang chạy và hệ điều hành nào. Chỉ có vậy.

Trong file không có gì: không có đường dẫn nào của bạn, không có tên site hay project, và không có mật khẩu. Điều này đúng vì file chỉ được phép chứa những gì kể trên, chứ không phải vì có gì đó được lọc bỏ về sau. Nên bạn có thể đính kèm nguyên file vào một báo cáo lỗi công khai mà không cần đọc trước.

Thông báo mà crash in ra là phần duy nhất có thể nhắc tới đường dẫn của bạn, nên nó được ghi vào logs/daemon.log thay vì vào file kia. File đó cũng đáng gửi kèm, nhưng hãy gửi có ý thức. Xem bên dưới.

Không có gì được gửi đi đâu cả. Không có server nào để gửi tới. Hai mươi file mới nhất được giữ lại, các file cũ hơn bị xóa. Nếu bạn không muốn file như vậy được ghi ra, thêm vào config.toml:

[crash]
enabled = false

Log của daemon vẫn ghi lại rằng đã có crash.

Báo cáo lỗi

mix doctor --bundle

Một file nén gom đủ mọi thứ một báo cáo lỗi cần: kết quả doctor tìm được, trạng thái daemon này, thông tin máy, các báo cáo crash nếu có, và phần cuối của log. --out chép nó tới nơi bạn chọn.

Những gì cố ý bỏ ra ngoài được ghi tên ngay trong file nén, nên không ai phải đoán một phần thiếu là do che đi hay do lỗi. Hãy mở ra xem trước khi gửi đi đâu. Đó là một file nén bình thường, và nó là của bạn.

Mọi lệnh mix đều nhận --json, thường là cách nhanh nhất để cho người khác thấy chính xác bạn đã thấy gì.

Trang này ở dạng Markdown: https://mixnz.github.io/mixengine/vi/troubleshooting.md