作为一名资深的安企CMS网站运营人员，我深知网站稳定运行对于内容发布和用户体验的重要性。在日常工作中，日志文件是我们诊断系统健康状况、快速定位问题不可或缺的工具。安企CMS提供了running.log和check.log这两个关键的日志文件，它们分别记录了不同的进程信息，共同为我们提供了排查系统故障的宝贵线索。
AnQiCMS 进程信息在 running.log 和 check.log 中的记录
当AnQiCMS系统在服务器上运行时，为了确保其稳定性和可维护性，系统会自动生成并更新running.log和check.log这两个日志文件。它们各自承担着不同的职责，记录着不同层面的进程信息。
check.log 文件主要记录了AnQiCMS应用程序进程的健康检查情况。根据AnQiCMS的启动脚本设计，通常会有一个定时任务（如crontab）每隔一段时间执行一个检查脚本。这个脚本的核心任务是确认AnQiCMS的主进程是否正在运行。如果进程不存在，它会尝试重新启动AnQiCMS。check.log中记录的信息，正是这些周期性检查的结果，包括检查的时间戳、AnQiCMS可执行文件的名称，以及系统在执行检查时是否检测到AnQiCMS进程的存在状态。例如，日志中可能会出现PID check: 0表示进程未运行，或PID check: 1表示进程正在运行的字样。这使得我们能够一目了然地了解AnQiCMS进程的生命周期管理是否正常，是否有启动脚本在持续尝试启动服务，以及这些尝试是否成功。
running.log 文件则更为详细地记录了AnQiCMS主应用程序的实际运行状态。当我们通过nohup命令启动AnQiCMS主程序时，所有的标准输出（stdout）和标准错误（stderr）都会被重定向并记录到running.log中。这意味着，应用程序在执行过程中的任何信息，包括系统启动时的初始化消息、正常的业务操作日志、警告信息、以及更为关键的程序错误（如Go语言的panic堆栈信息）、数据库连接问题、配置加载失败、路由处理异常等，都会被详尽地记录在这个文件中。它是AnQiCMS应用程序内部行为的直接体现，反映了程序在运行时遇到了哪些问题，或者正在进行哪些操作。
如何利用 running.log 和 check.log 进行排障
在AnQiCMS网站出现异常时，这两个日志文件是进行系统排查的得力助手。理解它们各自记录的内容，并结合实际情况进行分析，可以帮助我们迅速定位问题根源。
首先，从check.log入手判断进程管理问题。 当网站无法访问时，我们应优先查看check.log。通过检查最新的日志条目，我们可以判断AnQiCMS的启动脚本是否在正常运行。如果check.log中长时间没有新的记录，或者持续显示进程不存在（PID check: 0），这可能意味着AnQiCMS根本就没有启动成功，或者启动脚本本身存在问题。此时，我们需要检查crontab配置是否正确、启动脚本start.sh的权限是否足够，以及其内部的路径配置是否与AnQiCMS的实际安装路径相符。一个常见的场景是，如果check.log显示脚本反复尝试启动但进程始终无法维持，那么问题可能出在AnQiCMS应用程序本身，但check.log至少告诉我们，进程管理层面的“看护”机制是存在的。
其次，深入分析running.log定位应用程序内部错误。 如果check.log显示AnQiCMS进程被正常启动，但网站仍然无法访问，或者功能出现异常，那么问题很可能出在AnQiCMS应用程序内部。这时，running.log就成了我们最重要的线索。我们应该使用tail -f running.log命令实时查看日志的最新内容，或者回溯历史日志。在running.log中，重点关注以下几类信息：
- 错误信息（Error）和警告信息（Warning）：这些通常会以特定的前缀或颜色标示，是应用程序自身报告的问题。它们可能指向配置错误、数据库连接失败、外部服务调用超时、文件权限不足等。
- Go语言的Panic堆栈：如果AnQiCMS应用程序发生未捕获的严重错误（Go语言中的panic），
running.log会记录完整的堆栈跟踪信息。这是定位程序崩溃原因的关键，通常会指出导致崩溃的代码文件和行号。 - 数据库相关的日志：AnQiCMS需要连接数据库才能正常工作。
running.log可能会记录数据库连接失败、SQL执行错误或缓慢的查询。这些是常见的性能瓶颈或配置问题。 - 端口绑定冲突：如果AnQiCMS尝试监听的端口（默认8001）已经被其他程序占用，
running.log中会记录端口绑定的错误信息。结合lsof -i:{端口号}命令可以进一步确认端口占用情况。 - 启动阶段的详细输出：AnQiCMS在启动过程中会打印一系列初始化信息，包括加载配置、初始化模块、注册路由等。如果程序在启动的某个环节失败，
running.log会停止在失败前的最后一条正常日志，或者直接输出错误信息。
结合两者，形成完整的排障路径。 例如，当网站无法访问时：
- 检查
check.log：确认启动脚本是否正在运行AnQiCMS。- 如果
check.log没有更新或显示进程始终未启动：检查start.sh脚本路径、权限以及crontab任务。问题可能在系统层面或进程管理脚本。 - 如果
check.log显示进程已启动：继续下一步，问题可能在应用程序层面。
- 如果
- 检查
running.log：查看应用程序的实际运行情况。- 如果
running.log中有近期更新的错误信息（如数据库连接失败、配置加载错误、端口冲突、Go panic）：根据错误提示，修正对应的配置文件、数据库服务或释放端口。 - 如果
running.log内容很少或没有更新，但check.log显示进程已启动：这可能意味着应用程序启动后立即崩溃，没有来得及输出太多日志，或者日志文件写入权限有问题。此时，可以尝试手动执行start.sh中的AnQiCMS启动命令，观察终端输出，或者检查running.log的文件权限。
- 如果
通过上述方法，我们可以有条不紊地利用running.log和check.log这两个日志文件，从进程管理到应用程序内部，层层深入地分析和解决AnQiCMS运行过程中遇到的各类问题，确保网站的持续稳定运营。
常见问题解答 (FAQ)
1. Q: AnQiCMS网站突然打不开了，我应该先检查哪个日志文件？
A: 当AnQiCMS网站无法访问时，您应该首先检查check.log文件。这个文件记录了AnQiCMS进程的周期性健康检查结果。如果check.log显示AnQiCMS进程没有运行，或者启动脚本反复尝试启动失败，那么问题可能出在进程管理层面。如果check.log显示进程正常启动，但网站依然无法访问，那么接下来就需要查看running.log来定位应用程序内部的错误。
2. Q: running.log中显示“address already in use”错误是什么意思？我该如何解决？
A: running.log中出现“address already in use”错误，意味着AnQiCMS尝试监听的端口（通常是8001）已经被服务器上的另一个程序占用了。解决此问题的方法有：首先，您可以使用lsof -i:{端口号}（例如lsof -i:8001）命令在Linux系统上查找占用该端口的进程，并将其终止。其次，您也可以修改AnQiCMS的配置文件（config.json），将port参数更改为服务器上未被占用的其他端口，然后重启AnQiCMS服务。
3. Q: check.log长时间没有更新，或者里面的PID检测结果一直不变，是什么原因？
A: check.log长时间没有更新，或者PID检测结果异常，通常表明执行AnQiCMS健康检查的start.sh脚本没有被正确执行。这可能是由以下原因造成的：
- crontab任务未配置或配置错误：检查服务器的
crontab -e设置，确保存在一个每分钟执行start.sh脚本的任务，并且路径正确。 start.sh脚本文件权限不足：确保start.sh文件具有可执行权限（chmod +x start.sh）。start.sh脚本路径不正确或依赖缺失：检查脚本中定义的BINPATH和BINNAME是否与AnQiCMS的实际安装路径和可执行文件名称一致。如果脚本在执行过程中遇到语法错误或依赖问题，也可能导致其无法正常写入日志。 您应该手动在终端执行./start.sh，观察是否有错误输出，并检查日志文件是否更新，以定位具体问题。