本节书摘来自华章出版社《构建高可用Linux服务器 第3版》一 书中的第2章，第2.4节，作者：余洪春 ，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.4 系统维护时应该注意的地方
无论是自己的内网开发机器还是线上的生产机器，我们在操作时都应该谨慎，否则系统很容易发生Crash的情况。就算我们能用备份很快恢复，在恢复时间之内，我们也会损失大量的数据，而且如果万一恢复不了，那就是灾难性的了。
2.4.1 服务器硬件改动进入了Emergency模式
同事在处理一台CentOS 5.8服务器时，他在机器上移走了一块硬盘，然后就直接启动机器，忽然发现系统进了Emergency模式，于是他连忙跑过来找我。我第一句就是问他：你改动了硬件没？他说他移走硬盘后就直接启动了，不是跟Windows Server 2003一样吗，有什么问题？我跟他讲解了一下Linux系统下/etc/fatab的语法及作用，最后边操作边告诉他整个解决步骤，如下所示。
1）在Emergency模式下输入root密码进入单用户模式。
2）修改/etc/fstab文件时会出现“Read-only file system”，如何处理？重新将其装载成读写模式，命令如下：
mount -o remount,rw /
这句话的作用是将/分区设置成可读写。
3）编辑/etc/fatab文件，将移除的硬盘用#号屏蔽掉，然后重启服务器，故障解除。
2.4.2 如何以普通用户的身份编辑无权限的文件
如果普通用户用vim编辑nginx.conf等配置文件，保存的时候会提示：没有root权限，解决办法是在保存时加上以下命令：
:w !sudo tee %
这条命令的含义是把当前编辑的文件内容当做标准输入并输入到命令sudo tee文件名里去。也就是将sudo保存为当前文件名，这是一个相当管用的命令，不过这个命令比较拗口，我采用谐音记忆的方法记住了它，其实多练习几次自然就熟悉此命令了。
2.4.3 在Linux下配置最大文件打开数的方法
在Linux下部署应用（特别是Squid服务器时）的时候，有时会遇上“Socket/File:Cant open so many files”问题；这也会影响服务器的最大并发数。其实Linux是有文件句柄限制的，而且Linux默认不是很高，一般都是1024，如果是生产服务器用，很容易就会达到这个数量。
1.查看方法
我们可以用“ulimit-a”命令来查看所有限制值，命令如下所示：
ulimit-a
命令显示结果如下所示：
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16126
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16126
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
其中open files(-n)1024是Linux操作系统对一个进程打开的文件句柄数量的限制（也包含打开的套接字数量，可影响MySQL的并发连接数目）。这个值可用ulimit命令修改，但ulimit命令修改的数值只对当前登录用户目前使用的环境有效，系统重启或用户退出后就会失效。
系统的总限制是在：/proc/sys/fs/file-max。我们可以通过cat命令查看其目前的值，修改/etc/sysctl.conf也可以控制这个数值。
另外还有一个知识点，使用/proc/sys/fs/file-nr可以看到整个系统目前使用的文件句柄数量。
查找文件句柄问题的时候，还有一个很实用的程序lsof。可以很方便看到某个进程打开了哪些句柄，也可以看到某个文件/目录被什么进程占用了。
2.修改方法
若要令修改ulimits的数值永久生效，则必须修改配置文档，可以将ulimit修改命令放入/etc/profile里面，不过，这个方法实在不方便。还有一个方法是修改/etc/sysctl.conf。我修改后测试过，发现它不会改变用户的ulimits-a，只改变/proc/sys/fs/file-max的值。
而我以前的做法是修改/etc/security/limits.conf，其中有很详细的注释，文件内容修改如下所示：
* soft nofile 32768
* hard nofile 65535```
这样可以将文件句柄限制统一改成软32768，硬65536。配置文件最前面的内容是指domain，设置为星号代表全局，另外你也可以针对不同的用户做出不同的限制。这里要值得注意的是：其中的硬限制是实际的限制，而软限制，是warning限制，它只会给出warning；其实ulimit命令本身就分软硬设置，加-H就代表硬限制，加-S就代表软限制。默认显示的是软限制，如果运行ulimit命令修改时没有加上-H或-S，就是两个参数一起改变。
不过，这种做法仅对当前配置有效，如果重启系统，则完全失效。正确的做法应该是“编辑/etc/rc.loal文件”，在其后添加如下内容：
ulimit -SHn 65535
注意 如果想使shell及系统重启以后系统的最大文件打开数的修改值均生效，建议以上两个步都操作。
我们可以用以下脚本nginx_limit.sh来查看nginx进程能打开的最大文件打开数，内容如下：
for pid in 'ps aux |grep nginx | grep -v grep| awk '{print$2}''
do
cat /proc/${pid}/limits |grep 'Max open files'
done
如果是非nginx的其他进程，可以用下面的方法来判断，命令如下所示：
cat /proc/2976/limits | grep "Max open files"
命令显示结果如下所示，表示修改是生效的：
Max open files 65535 65535 files
其中，2976为httpd进程的pid值，我们可以通过ps命令得到，这种方法可以精确得到当前进程打开文件的最大打开数。
####2.4.4 在crontab下正确防止脚本运行冲突
如果某脚本要运行30分钟，可以在crontab里把脚本间隔设为至少一小时来避免冲突。而比较糟的情况是可能该脚本在执行周期内没有完成，接着第二个脚本又开始运行了。如何确保只有一个脚本实例运行呢？一个好用的方法是利用lockf（FreeBSD 8.1下为lockf，CentOS 5.8下为flock），在脚本执行前先检测能否获取某个文件锁，以防止脚本运行冲突。
lockf的参数如下。
-k：一直等待获取文件锁。
-s：silent，不发出任何信息，即使拿不到文件锁。
-t seconds：设定timeout的时间是seconds秒，如果超过时间，则自动放弃。
执行以下crontab计划任务前，需获取临时文件create.lock的文件锁，此项crontab计划任务的内容如下（以FreeBSD 8.1 x86_64举例说明）：
*/10**** (lockf -s -t 0 /tmp/create.lock /usr/bin/python /home/project/cron/create_tab.py
>> /home/project/logs/create.log 2>&1)
