从Nginx配置问题看软连接和硬连接

最近没事在捣鼓小项目，需要在服务器上安装nginx，本来只是一个命令的事情但却在重启的时候报错了。

apt-get install nginx

安装完成之后也显示了安装成功，但当重新配置nginx.conf然后重启的时候有个报错：

open() "/usr/share/nginx/nginx.conf" failed

但是我的nginx安装位置明明就不在这个路径，为什么会去share路径下查找配置文件呢？

nginx官网也都默认路径在/etc/nginx下面的。

The way nginx and its modules work is determined in the configuration file. By default, the configuration file is named `nginx.conf` and placed in the directory `/usr/local/nginx/conf`, `/etc/nginx`, or `/usr/local/etc/nginx`.

虽然不知道为什么会这样，但或许我们知道可以怎么解决它。

既然nginx想去share路径下查找config，而我配置的真实config在etc下，那只需要在share路径下链接etc下的nginx.conf就可以了。

所以，我们可以采用软连接or硬链接的方式。这里的话其实两种方式都可以，这里我选择了软连接

ln -s /etc/nginx/nginx.conf /usr/share/nginx/nginx.conf

执行完这个命令之后，就相当于在/usr/share/nginx路径下创建了指向 /etc/nginx/nginx.conf配置文件的指针文件。

当再次重启nginx的时候，就算nginx去share路径下寻找配置文件，其实查到的还是etc下面的配置文件。这样就没有问题了。

从这个小问题，我们可以顺便学习下硬链接和软连接的知识点。

索引节点

在Linux的文件系统中，保存在磁盘分区中的文件，不管是什么类型，系统都会给它分配一个编号，这个编号被称为索引节点编号（Inode Index），它是该文件或者目录在linux文件系统中的唯一标识。有了这个编号值，就可以查到该文件的详细内容。

硬链接

硬链接相当于是源文件的一个镜像文件，文件内容和源文件完全相同，也指向同一个索引节点。所以，当修改源文件或者镜像文件的时候，另一个文件的内容也会跟着响应的变更。当删除其中一个文件，因为索引节点还可以指向另一个文件，所以另一个文件仍然为有效状态。因此，该机制可以有效的防止误删操作。

硬链接只能在同一类型的文件系统中进行链接，不能跨文件系统。同时它只能对文件进行链接，不能链接目录。

软连接

软连接可以理解为指向源文件的指针，它生成的新文件并没有和源文件一样的内容。文件存放的内容其实是源文件的路径指向，通过这个方式可以快速定位到软连接所指向的源文件实体。所以当源文件被删除后，软连接生成的文件也会无效掉。但当我们重新对软连接生成的文件进行写入后，源文件就会被还原回来，但源文件的内容是我们新写入的内容而不是老的内容，这也说明了软连接产生文件存放的只是源文件的路径。

软链接常用来解决空间不足的问题，比如某个文件文件系统空间已经用完了，但是现在必须在该文件系统下创建一个新的目录并存储大量的文件，那么可以把另一个剩余空间较多的文件系统中的目录链接到该文件系统中。

软链接可以跨文件系统而链接，也可以同时对文件或目录进行链接。

二者区别

• 软链接以存放另一个文件的路径的形式存在，硬链接以文件副本的形式存在；
• 软链接可以跨不同的文件系统而链接，硬链接不可以；
• 软链接可以对目录进行链接，而硬链接不可以；
• 软链接可以对一个不存在的文件名进行链接，硬链接必须要有源文件。
• 删除软链接并不影响被指向的文件，但若被指向的原文件被删除，则相关软连接就变成了死链接
• 删除硬链接的话，只要索引节点的个数不为零，则不会对原始文件造成任何影响；

软连接和硬连接都通过ln命令来实现。

ln 参数 源文件或目录 目标文件或目录

-s 软链接（符号链接）

实践测试

首先在自己的一个工作目录下创建一个文件，然后对这个文件进行链接的创建：

$ touch myfile && echo "hello world" > myfile

现在我们创建了一个普通地不能再普通的文件了。然后我们对它创建一个硬链接，并查看一下当前目录：

$ ln myfile hard
$ ls -li

1186926 -rw-r--r--  2 root  root  May 24 15:43 hard
1186926 -rw-r--r--  2 root  root  May 24 15:43 myfile

在 ls 结果的最左边一列，就是文件的 inode 值，这两个文件就如同一个文件一样，inode 值相同，都指向同一个区块。

然后我们修改一下刚才创建的 hard 链接文件：

$ echo "New line" >> hard
$ cat myfile

hello world
New line

可以看到，这两个文件果真就是一个文件。

下面看看软链接（也就是符号链接）和它有什么区别。

$ ln -s myfile soft
$ ls -li

1186926 -rw-r--r--  2 root  root  May 24 15:43 hard
1186926 -rw-r--r--  2 root  root  May 24 15:43 myfile
1188507 lrwxr-xr-x  1 root  root  May 24 15:43 soft -> myfile

这个软链接的 inode 和源文件是不一样的，并且它的文件属性上也有一个 l 的 flag，这就说明它与之前我们创建的两个文件根本不是一个类型。而且后面会有一个soft指向myfile的标志。

下面我们试着删除 myfile 文件，然后分别输出软硬链接的文件内容：

$ rm myfile
$ cat hard

hello world
New line

硬链接产生的文件不受影响。

$ cat soft

cat: soft: No such file or directory

软链接显示无法找到该文件了。

我们再向这个软链接写点东西试试：

$ echo "Something" >> soft
$ ls

hard   myfile soft

可以看到，刚才删除的 myfile 文件竟然又出现了！这就说明，当我们写入访问软链接时，系统自动将其路径替换为其所代表的绝对路径，并直接访问那个路径了。

所以hard文件被自动生成，刚才写入soft的内容其实是被写入到hard中了。

$ cat hard

Something

通过这一波操作，大家应该也都掌握了软连接和硬链接了吧。

那么说回开头，为什么我选择了软连接而不是硬链接呢？

• 可以占用更少的空间
• 配置文件只会在etc目录下被更改而不会在share下被更改

当然，如果想通过硬链接来实现也是完全可以的。