作为一位深度熟悉安企CMS（AnQiCMS）的网站运营人员，我深知系统稳定运行与高效问题排查对于内容管理的重要性。当AnQiCMS在运行时出现异常，或者需要深入了解其内部工作流程时，获取详细的调试信息是至关重要的一步。start.sh 脚本作为AnQiCMS在Linux环境下的启动入口，正是我们修改以获取更多调试信息的关键所在。
理解 start.sh 脚本的初始作用
在AnQiCMS的部署中，start.sh 脚本承担着检查AnQiCMS进程状态并启动其主程序的任务。通过文档，我们了解到其核心逻辑包含了判断AnQiCMS是否正在运行，如果未运行，则通过 nohup $BINPATH/$BINNAME >> $BINPATH/running.log 2>&1 & 这行命令来启动程序。这行命令的意义在于，它在后台（通过 nohup）运行AnQiCMS可执行文件（$BINPATH/$BINNAME），并将标准输出和标准错误（2>&1）都重定向到 running.log 文件中。这意味着所有由AnQiCMS程序直接输出到控制台的信息都会被记录在这个日志文件中。
然而，对于更深层次的调试需求，仅仅捕获标准输出和标准错误可能还不够。很多Go语言应用，包括像AnQiCMS这样的内容管理系统，其内部的日志系统通常支持不同的日志级别，例如 info、warn、error，以及我们调试时最常需要的 debug 或 trace 级别。要获取“更详细的调试信息”，往往需要指示AnQiCMS程序自身以更高的日志级别运行。
启用更详细调试信息的方法探讨
AnQiCMS作为Go语言开发的应用程序，其日志输出的详细程度通常可以通过以下几种常见方式来控制：
首先，许多应用程序会响应特定的环境变量。例如，可以设置 ANQICMS_DEBUG=true 或者 LOG_LEVEL=debug 这样的环境变量，来告诉程序输出更多细节。这些环境变量需要在程序启动前被设置。
其次，有些程序会接受命令行参数来控制日志级别。例如，在启动命令后添加 --debug 或 --verbose 这样的标志。
再者，配置文件也是控制应用程序行为的常见方式。AnQiCMS的 config.json 文件用于配置端口等基础信息，理论上也可以包含日志级别设置。但根据提供的文档，config.json 主要用于模板相关的配置，并未明确指出其支持日志级别调整。因此，我们需要将重点放在前两种通过 start.sh 脚本直接修改的方法上。
修改 start.sh 脚本以获取详细调试日志
为了让AnQiCMS在启动时记录更详细的调试信息，我们需要修改 start.sh 脚本，在执行AnQiCMS程序时加入相应的控制参数。这里我们将介绍两种基于环境变量和命令行参数的修改方式，您可以根据AnQiCMS实际支持的参数进行尝试。同时，为了避免调试日志与常规运行日志混淆，建议将调试信息输出到单独的日志文件中。
以下是修改 start.sh 脚本的步骤：
首先，找到您服务器上AnQiCMS安装目录下的 start.sh 文件。通常，这个文件会位于 /www/wwwroot/your_domain/start.sh 路径（根据您实际的安装路径而定）。
使用文本编辑器打开 start.sh 文件，例如 vi start.sh 或 nano start.sh。
在脚本中找到启动AnQiCMS核心程序的那一行。它大致会是这样：
cd $BINPATH && nohup $BINPATH/$BINNAME >> $BINPATH/running.log 2>&1 &
现在，我们将根据不同的调试需求来修改这一行：
方法一：通过设置环境变量启用详细日志
如果AnQiCMS支持通过环境变量来控制日志级别（例如 ANQICMS_LOG_LEVEL=debug），您可以在执行命令前设置这个环境变量。修改后的启动命令可能如下所示：
#!/bin/bash
### check and start AnqiCMS
# author fesion
# the bin name is anqicms
BINNAME=anqicms
BINPATH=/www/wwwroot/anqicms # 请根据您的实际路径修改
# check the pid if exists
exists=`ps -ef | grep '\<anqicms\>' |grep -v grep |wc -l`
echo "$(date +'%Y%m%d %H:%M:%S') $BINNAME PID check: $exists" >> $BINPATH/check.log
echo "PID $BINNAME check: $exists"
if [ $exists -eq 0 ]; then
echo "$BINNAME NOT running"
# --- 添加或修改以下行以启用更详细的调试日志 ---
export ANQICMS_LOG_LEVEL="debug" # 假设 AnQiCMS 响应 ANQICMS_LOG_LEVEL 环境变量
# 或者尝试更通用的 LOG_LEVEL 环境变量
# export LOG_LEVEL="debug"
# 将详细日志输出到专门的 debug.log 文件，方便区分
cd $BINPATH && nohup $BINPATH/$BINNAME >> $BINPATH/debug_running.log 2>&1 &
fi
在这里，我们通过 export ANQICMS_LOG_LEVEL="debug"（或类似的变量）来尝试开启调试模式。同时，我们将日志文件更改为 debug_running.log，以便将调试信息与常规运行日志分开，这在后期分析时会非常有帮助。
方法二：通过传递命令行参数启用详细日志
如果AnQiCMS支持通过命令行参数来控制日志级别（例如 --debug 或 --log-level debug），您可以在执行命令时将这些参数传递给可执行文件。修改后的启动命令可能如下所示：
#!/bin/bash
### check and start AnqiCMS
# author fesion
# the bin name is anqicms
BINNAME=anqicms
BINPATH=/www/wwwroot/anqicms # 请根据您的实际路径修改
# check the pid if exists
exists=`ps -ef | grep '\<anqicms\>' |grep -v grep |wc -l`
echo "$(date +'%Y%m%d %H:%M:%S') $BINNAME PID check: $exists" >> $BINPATH/check.log
echo "PID $BINNAME check: $exists"
if [ $exists -eq 0 ]; then
echo "$BINNAME NOT running"
# --- 添加或修改以下行以启用更详细的调试日志 ---
# 假设 AnQiCMS 响应 --debug 命令行参数
# cd $BINPATH && nohup $BINPATH/$BINNAME --debug >> $BINPATH/debug_running.log 2>&1 &
# 或者假设 AnQiCMS 响应 --log-level debug 命令行参数
cd $BINPATH && nohup $BINPATH/$BINNAME --log-level debug >> $BINPATH/debug_running.log 2>&1 &
fi
请注意，您可能需要查阅AnQiCMS的官方开发文档或源代码，以确认其具体支持的环境变量或命令行参数名称。因为提供的文档中并未明确说明AnQiCMS如何控制其内部日志级别。作为一位运营人员，在尝试这些通用方法时，保持探索和验证的心态是非常重要的。
修改完成后，保存 start.sh 文件。为了让修改生效，您需要先停止当前运行的AnQiCMS实例（如果存在），然后重新执行 start.sh 脚本来启动AnQiCMS。
停止AnQiCMS的命令示例（请根据您的 stop.sh 脚本路径和内容调整）：
./stop.sh
启动AnQiCMS的命令示例：
./start.sh
启动后，您可以通过查看 debug_running.log 文件来获取AnQiCMS产生的详细调试信息。例如：tail -f $BINPATH/debug_running.log。
请记住，在生产环境中长时间开启详细调试日志可能会对系统性能产生影响，并可能暴露一些敏感信息。因此，在完成问题排查后，建议您将 start.sh 脚本恢复到原先的配置，或至少将日志级别调回正常模式。
常见问题解答 (FAQ)
问：开启详细调试日志后，是否会影响AnQiCMS的运行性能？
答：是的，长时间开启详细调试日志通常会影响AnQiCMS的运行性能。因为程序需要花费额外的时间和资源来生成、格式化并写入大量的日志信息，这会增加CPU、内存和磁盘I/O的开销。在问题解决后，建议您及时关闭详细日志模式，以确保系统的**性能。
问：如果我修改了 start.sh 脚本但AnQiCMS仍然没有输出详细日志，我该怎么办？
答：如果在修改 start.sh 脚本并重启AnQiCMS后，您在日志文件中仍然没有看到更详细的输出，这可能意味着AnQiCMS应用程序本身并没有响应您尝试设置的环境变量或命令行参数。在这种情况下，您应该查阅AnQiCMS的最新官方开发文档，或者在AnQiCMS的社区论坛或GitHub仓库中查找关于如何启用更详细日志的特定说明。有时候，应用程序的日志级别控制可能通过其内部的配置文件而非外部启动参数来