Nginx源码分析之--auto/include脚本

微信公众号:Nginx源码分析
关注可了解更多的Nginx知识。任何问题或建议,请公众号留言;
关注公众号,有趣有内涵的文章第一时间送达!

回顾

上一篇文章我们详细的分析了auto/feature脚本的作用,该脚本的主要作用是测试宿主系统是否支持某个特性。
辅助脚本
下面我们分析上图中最后一个脚本文件auto/include

auto/include 脚本

测试当前的宿主操作系统中是否存在某个头文件。

输入参数

ngx_include: 待测试的头文件

输出参数

ngx_found: 表示是否存在该头文件,如果为yes表示存在该头文件。
若为no,表示不存在。

功能

测试当前的宿主操作系统中是否存在某个头文件。

示例

下面是一个示例。
这个例子用于测试当前的操作系统中是否包含 unistd.h头文件。

ngx_include="unistd.h";      . auto/include
脚本内容
echo $ngx_n "checking for $ngx_include ...$ngx_c"

cat << END >> $NGX_AUTOCONF_ERR

----------------------------------------
checking for $ngx_include

END


ngx_found=no

cat << END > $NGX_AUTOTEST.c

$NGX_INCLUDE_SYS_PARAM_H
#include <$ngx_include>

int main() {
    return 0;
}

END


ngx_test="$CC -o $NGX_AUTOTEST $NGX_AUTOTEST.c"

eval "$ngx_test >> $NGX_AUTOCONF_ERR 2>&1"

if [ -x $NGX_AUTOTEST ]; then

    ngx_found=yes

    echo " found"

    ngx_name=`echo $ngx_include \
              | tr abcdefghijklmnopqrstuvwxyz/. ABCDEFGHIJKLMNOPQRSTUVWXYZ__`


    have=NGX_HAVE_$ngx_name . auto/have_headers

    eval "NGX_INCLUDE_$ngx_name='#include <$ngx_include>'"

    #STUB
    eval "NGX_$ngx_name='#include <$ngx_include>'"

else
    echo " not found"

    echo "----------"    >> $NGX_AUTOCONF_ERR
    cat $NGX_AUTOTEST.c  >> $NGX_AUTOCONF_ERR
    echo "----------"    >> $NGX_AUTOCONF_ERR
    echo $ngx_test       >> $NGX_AUTOCONF_ERR
    echo "----------"    >> $NGX_AUTOCONF_ERR
fi

rm $NGX_AUTOTEST*
脚本分析

我们以示例中测试unistd.h的代码分析这个脚本。

1).向终端和NGX_AUTOCONF_ERR中输出测试信息

echo $ngx_n "checking for $ngx_include ...$ngx_c"

cat << END >> $NGX_AUTOCONF_ERR

----------------------------------------
checking for $ngx_include

END

我们之前分析的几乎所有脚本文件的第一步都是这个功能。主要是方便查找错误使用。

2). 初始化一些变量

ngx_found=no

上面初始化一个ngx_found,这个变量表示的是当前测试的头文件是否存在。默认设置为no.

3).生成自动测试文件

cat << END > $NGX_AUTOTEST.c

$NGX_INCLUDE_SYS_PARAM_H
#include <$ngx_include>

int main() {
    return 0;
}

END

根据传进来的入参ngx_include参数生成自动测试程序。
本例中生成的测试程序如下:

#include <unistd.h>

int main() {
    return 0;
}

4).编译自动测试程序

ngx_test="$CC -o $NGX_AUTOTEST $NGX_AUTOTEST.c"

eval "$ngx_test >> $NGX_AUTOCONF_ERR 2>&1"

上面的脚本把第3)步生成的自动测试程序进行编译。编译后的可执行文件为objs/autotest.

5). 执行自动测试程序并处理相应的逻辑

if [ -x $NGX_AUTOTEST ]; then

    ngx_found=yes

    echo " found"

    ngx_name=`echo $ngx_include \
              | tr abcdefghijklmnopqrstuvwxyz/. ABCDEFGHIJKLMNOPQRSTUVWXYZ__`


    have=NGX_HAVE_$ngx_name . auto/have_headers

    eval "NGX_INCLUDE_$ngx_name='#include <$ngx_include>'"

    #STUB
    eval "NGX_$ngx_name='#include <$ngx_include>'"

else
    echo " not found"

    echo "----------"    >> $NGX_AUTOCONF_ERR
    cat $NGX_AUTOTEST.c  >> $NGX_AUTOCONF_ERR
    echo "----------"    >> $NGX_AUTOCONF_ERR
    echo $ngx_test       >> $NGX_AUTOCONF_ERR
    echo "----------"    >> $NGX_AUTOCONF_ERR
fi

我们分析一下上面的脚本。
①. 如果自动测试程序不能执行,那么会执行下面的else逻辑。

    echo " not found"

    echo "----------"    >> $NGX_AUTOCONF_ERR
    cat $NGX_AUTOTEST.c  >> $NGX_AUTOCONF_ERR
    echo "----------"    >> $NGX_AUTOCONF_ERR
    echo $ngx_test       >> $NGX_AUTOCONF_ERR
    echo "----------"    >> $NGX_AUTOCONF_ERR

这部分脚本和我们之前分析的错误处理基本上都一样。都是保存错误现场,便于查找错误。

②.如果自动测试程序可执行
首先把ngx_found设置为yes,表示当前操作系统包含unistd.h头文件。
设置ngx_name变量。这个变量的生成规则也比较简单,管道符后面的tr命令是把ngx_include中的小写字母替换成对应的大写字母,把小数点.替换为下划线_。所以这里的ngx_name变量的值就会被设置为UNISTD_H.

③.NGX_AUTO_HEADERS_H添加宏定义
在上面的第②.步中,生成了一个ngx_name变量。紧接该脚本调用auto/have_headers(我们之前分析过该脚本,不懂得朋友可以看看之前的文章)向NGX_AUTO_HEADERS_H中增加一个宏定义。

#define NGX_HAVE_UNISTD_H 1;

通过这个宏定义,说明了当前操作系统包含此头文件。

④. 紧接着的两个eval语句生成了另外两个输出变量。

    eval "NGX_INCLUDE_$ngx_name='#include <$ngx_include>'"

    #STUB
    eval "NGX_$ngx_name='#include <$ngx_include>'"

这两个变量分别是:

NGX_INCLUDE_UNISTD_H="#include <unistd.h>"
NGX_UNISTD_H="#include <unistd.h>"

我们在前面分析过的一些脚本中,在生成自动测试程序的时候就会使用到这两个变量。现在我们知道这两个变量是怎么来的吧?

6). 删除临时文件

rm $NGX_AUTOTEST*

总结

我们通过unistd.h的例子详细的分析了auto/include脚本的功能。这个脚本的作用就是测试在当前的宿主系统上面是否含有某个头文件。在测试成功之后,会输出若干变量,这样就可以在其他脚本中使用到这些变量。

到现在为止,我们已经把开篇图中的所有脚本已经全部分析过了。后面的文章我们会接着分析nginx的源码,敬请期待。顺便关注我的个公众号(Nginx源码分析),第一时间接收最新文章。

后面的文章我们会接着分析nginx的源码,敬请期待。顺便关注我的个公众号(Nginx源码分析)。

<think>好的,我现在需要帮助用户分析他们运行`sudo find / -name "nginx.conf" 2>/dev/null`后得到的多个nginx.conf文件路径。用户之前的问题是关于如何确定正确的Nginx配置文件位置,现在他们提供了查找结果,里面有几个可能的路径,需要我解释这些结果并指导他们确定正确的配置文件。 首先,我要理解用户的需求。他们可能在配置Nginx时遇到问题,或者需要确认哪个配置文件是当前正在使用的。用户之前尝试过用`nginx -V`来查找配置路径,但没有成功,现在通过find命令找到了多个路径,需要帮助筛选。 接下来,我需要分析用户提供的路径。给出的路径有: 1. `/root/nginx/nginx-rtmp-module-1.2.2/test/nginx.conf` 2. `/root/nginx/nginx-1.25.5/conf/nginx.conf` 3. `/usr/local/nginx/conf/nginx.conf` 4. `/www/server/nginx/nginx-rtmp-module/test/nginx.conf` 5. `/www/server/nginx/conf/nginx.conf` 6. `/www/backup/file_history/www/server/nginx/conf/nginx.conf` 首先,我需要排除测试或备份文件。比如路径中包含`test`或`backup`的可能是测试用例或备份文件,不太可能是当前使用的配置。例如,路径1和4中的`test`目录下的nginx.conf,通常是模块的测试配置文件,而不是实际使用的。路径6看起来像是备份文件,因为路径中有`backup/file_history`。 剩下的可能性较大的路径是: - `/root/nginx/nginx-1.25.5/conf/nginx.conf`:这可能是在用户自己编译安装Nginx时生成的配置文件,尤其是如果用户手动下载并编译了Nginx 1.25.5版本,这个路径可能对应源码安装的位置。 - `/usr/local/nginx/conf/nginx.conf`:这也是常见的源码安装的默认路径,通常当用户通过源码编译安装且没有指定其他路径时,配置文件会在这里。 - `/www/server/nginx/conf/nginx.conf`:这个路径看起来像是通过某些第三方脚本或面板(如宝塔面板)安装的Nginx的配置路径,很多控制面板会自定义安装目录到`/www/server`下。 接下来,用户需要确定哪个是当前正在使用的配置文件。我需要建议用户使用之前提到的`nginx -t`命令来测试配置,这会显示实际加载的配置文件路径。如果用户运行`nginx -t`,输出中会显示正在使用的配置文件,例如“configuration file /etc/nginx/nginx.conf syntax is ok”,这样就能明确知道正确的路径。 如果用户没有权限运行`nginx -t`,可能需要使用`sudo`。此外,检查Nginx进程的启动参数也是一个方法,通过`ps aux | grep nginx`查看主进程是否带有`-c`参数指定配置文件,例如`-c /www/server/nginx/conf/nginx.conf`,这样可以直接确认。 另外,用户可能安装了多个Nginx实例,比如通过不同方式安装的,这时候需要确认当前运行的Nginx二进制文件的位置,使用`which nginx`或者`ps aux | grep nginx`找到二进制路径,再根据该路径推断配置文件的默认位置。 最后,需要提醒用户,如果存在多个配置文件,修改错误的文件不会生效,因此确认正确的路径非常重要。建议用户优先检查`/www/server/nginx/conf/nginx.conf`,因为第三方面板常用此路径,同时结合`nginx -t`的输出来验证。</think>根据你提供的 `find` 命令结果,系统中存在 **多个 `nginx.conf` 文件**,这表明可能存在以下情况: --- ### **路径分析** 1. **测试/备份文件(可忽略)** - `/root/nginx/nginx-rtmp-module-1.2.2/test/nginx.conf` - `/www/server/nginx/nginx-rtmp-module/test/nginx.conf` - `/www/backup/file_history/www/server/nginx/conf/nginx.conf` **说明**:这些是 **Nginx RTMP 模块的测试配置文件** 或 **历史备份文件**,与当前运行中的 Nginx 无关。 2. **源码编译安装路径** - `/root/nginx/nginx-1.25.5/conf/nginx.conf` - `/usr/local/nginx/conf/nginx.conf` **说明**:可能是你通过源码编译安装 Nginx 时生成的默认配置文件,但若未实际运行此版本,则非当前生效配置。 3. **重点怀疑路径** - `/www/server/nginx/conf/nginx.conf` **说明**:此路径常见于通过 **第三方脚本(如宝塔面板、LNMP一键包)** 安装的 Nginx,极有可能是当前正在使用的配置文件。 --- ### **如何确认实际生效的配置文件?** #### **方法一:通过 `nginx -t` 验证配置** 运行命令查看 Nginx 实际加载的配置文件路径: ```bash sudo nginx -t ``` 输出示例: ``` nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied) nginx: the configuration file **/www/server/nginx/conf/nginx.conf** syntax is ok nginx: configuration file /www/server/nginx/conf/nginx.conf test is successful ``` **第一行**会显示当前配置文件路径(即使权限错误也会输出路径)。 #### **方法二:查看 Nginx 进程参数** 运行命令检查进程启动时指定的配置文件: ```bash ps aux | grep nginx | grep master ``` 输出示例: ``` root 1234 0.0 0.1 12345 6789 ? Ss 12:34 0:00 nginx: master process **/www/server/nginx/sbin/nginx -c /www/server/nginx/conf/nginx.conf** ``` 若存在 `-c` 参数,则直接显示配置文件路径。 --- ### **最终结论** 根据路径特征和常见安装方式,**当前生效的配置文件应为 `/www/server/nginx/conf/nginx.conf`**。建议按以下步骤操作: 1. **验证配置语法**: ```bash sudo nginx -t -c /www/server/nginx/conf/nginx.conf ``` 2. **查看配置关联文件**: 配置文件通常包含 `include` 指令加载其他配置(如虚拟主机),例如: ```nginx include /www/server/nginx/conf/vhost/*.conf; ``` 3. **若需修改配置**: 直接编辑 `/www/server/nginx/conf/nginx.conf`,修改后执行 `sudo nginx -s reload` 重载配置。 --- ### **其他注意事项** - **多版本共存**:若系统中存在多个 Nginx 实例,需通过 `which nginx` 确认当前运行的二进制文件路径,再结合 `ps aux` 进一步分析。 - **权限问题**:操作配置文件时可能需要 `sudo` 提权。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值