输入netstat –ntlp | grep nginx查看nginx的通信端口。

输入wget htt:\\10.190.130.78:8007就测试到配置是否成功。

2.6.在Firewall启动状态下运行Nginx

在Firewall启动的情况下，其他客户端无法访问到htt:\\10.190.130.78:8007。

输入netstat -ntlp | grep nginx查看nginx的占用端口

在其他客户端中输入wget http://10.190.130.78:8007就可以访问成功。

3.设置自定义开机系统服务

 

CentOS 7 使用systemd替换了SysV。Systemd目的是要取代Unix时代以来一直在使用的init系统，兼容SysV和LSB的启动脚本，而且够在进程启动过程中

更有效地引导加载服务。

systemd的特性有：

支持并行化任务

同时采用socket式与D-Bus总线式激活服务；

按需启动守护进程（daemon）；

利用 Linux 的 cgroups 监视进程；

支持快照和系统恢复；

维护挂载点和自动挂载点；

各服务间基于依赖关系进行精密控制。

 

检视和控制systemd的主要命令是systemctl。该命令可用于查看系统状态和管理系统及服务。详见man 1 systemctl。

输入vim /usr/lib/systemd/system/nginx.service进入文件编辑。

将以下内容拷贝到nginx.service文件中，然后保存。

[Unit]

Description=nginx servicedaemon

After=network.target

[Service]

Type=forking

PIDFile=/usr/local/nginx/logs/nginx.pid  #nginx安装路径下的nginx.pid文件

ExecStart=/usr/local/nginx/sbin/nginx

ExecReload=/usr/local/nginx/sbin/nginx-s reload

ExecStop=/usr/local/nginx/sbin/nginx-s stop

PrivateTep=true

[Install]

WantedBy=multi-user.target

保存文件后，启动nginx服务器会出现错误。必须要输入systemctl daemon-reload，重载后台服务。

输入systemctl daemon-reload，重载后台服务。可以使用systemctl命令对nginx进行操作

如果需要更详细的配置，请参考：

https://www.freedesktop.org/software/systemd/man/systemd.service.html

使用单元

一个单元配置文件可以描述如下内容之一：系统服务（.service）、挂载点（.mount）、sockets（.sockets）、系统设备（.device）、交换分区（.swap）、文件路径（.path）、启动目标（.target）、由 systemd 管理的计时器（.timer）。详情参阅 man 5 systemd.unit。

使用 systemctl 控制单元时，通常需要使用单元文件的全名，包括扩展名（例如 sshd.service）。但是有些单元可以在systemctl中使用简写方式。

如果无扩展名，systemctl 默认把扩展名当作 .service。例如 netcfg 和 netcfg.service 是等价的。

挂载点会自动转化为相应的 .mount 单元。例如 /home 等价于 home.mount。

设备会自动转化为相应的 .device 单元，所以 /dev/sda2 等价于 dev-sda2.device。

注: 有一些单元的名称包含一个 @ 标记， (e.g. name@string.service): 这意味着它是模板单元name@.service 的一个实例。 string 被称作实例标识符, 在 systemctl 调用模板单元时，会将其当作一个参数传给模板单元，模板单元会使用这个传入的参数代替模板中的 %I 指示符。在实例化之前，systemd 会先检查 name@string.suffix 文件是否存在（如果存在，应该就是直接使用这个文件，而不是模板实例化了）。大多数情况下，包换 @ 标记都意味着这个文件是模板。如果一个模板单元没有实例化就调用，该调用会返回失败，因为模板单元中的 %I 指示符没有被替换。

例如：systemctl start <单元>

编写单元文件

systemd单元文件的语法来源于 XDG桌面入口配置文件.desktop文件，最初的源头则是MicrosoftWindows的.ini文件。单元文件可以从两个地方加载，优先级从低到高分别是：

/usr/lib/systemd/system/: 软件包安装的单元

/etc/systemd/system/: 系统管理员安装的单元

注意: 当systemd运行在用户模式下时，使用的加载路径是完全不同的。

处理依赖关系

使用systemd时，可通过正确编写单元配置文件来解决其依赖关系。典型的情况是，单元A要求单元B在A启动之前运行。在此情况下，向单元A配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依赖关系是可选的，可添加 Wants=B 和 After=B。请注意 Wants= 和 Requires= 并不意味着 After=，即如果 After= 选项没有制定，这两个单元将被并行启动。

依赖关系通常被用在服务（service）而不是目标（target）上。例如， network.target 一般会被某个配置网络接口的服务引入，所以，将自定义的单元排在该服务之后即可，因为 network.target 已经启动。

服务类型

编写自定义的 service 文件时，可以选择几种不同的服务启动方式。启动方式可通过配置文件 [Service] 段中的 Type= 参数进行设置。

Type=simple（默认值）：systemd认为该服务将立即启动。服务进程不会fork。如果该服务要启动其他服务，不要使用此类型启动，除非该服务是socket激活型。

Type=forking：systemd认为当该服务进程fork，且父进程退出后服务启动成功。对于常规的守护进程（daemon），除非你确定此启动方式无法满足需求，使用此类型启动即可。使用此启动类型应同时指定 PIDFile=，以便systemd能够跟踪服务的主进程。

Type=oneshot：这一选项适用于只执行一项任务、随后立即退出的服务。可能需要同时设置 RemainAfterExit=yes 使得 systemd 在服务进程退出之后仍然认为服务处于激活状态。

Type=notify：与 Type=simple 相同，但约定服务会在就绪后向 systemd 发送一个信号。这一通知的实现由 libsystemd-daemon.so 提供。

Type=dbus：若以此方式启动，当指定的 BusName出现在DBus系统总线上时，systemd认为服务就绪。

Type=idle: systemd会等待所有任务(Jobs)处理完成后，才开始执行idle类型的单元。除此之外，其他行为和Type=simple 类似。

type的更多解释可以参考systemd.service(5)。

3.1.设置开机服务