PHPor 的Blog – 第62页

linux 之 fs.inotify

tail -f 时，有如下报错：

tail: inotify cannot be used, reverting to polling: Too many open files

1	tail: inotify cannot be used, reverting to polling: Too many open files

说明：tail -f 在远古的时候，是不断地轮询检查文件有没有更新，这个方式效率比较低；新石器时代，kernel提供了inotify机制，就是，你不需要总来问，只要你说一声，文件有更新的话我就通知你，strace 部分信息如下：

inotify_init()                          = 4
inotify_add_watch(4, "/data/logs/phpor.20160708.log", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1
fstat(3, {st_mode=S_IFREG|0666, st_size=858053, ...}) = 0
read(4,

inotify_init() = 4

inotify_add_watch(4, "/data/logs/phpor.20160708.log", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1

fstat(3, {st_mode=S_IFREG|0666, st_size=858053, ...}) = 0

read(4,

上面的错误是：需要notify的文件太多超过最大限制了，修改方式如下：

修改 fs.inotify.max_user_instances 到一个更大的值

docker 容器命令批量执行

docker容器相比完全虚拟机来讲，没有密码也能进去执行命令，还可以容易地批量执行，如下：

docker ps -q|while read id; do echo "hostname" | docker exec -i $id /bin/bash ;done

1	docker ps -q\|while read id; do echo "hostname" \| docker exec -i $id /bin/bash ;done

PAM配置ldap验证

PAM是linux上提供的一个可插拔认证模块，应该说还是比较强大、方便好用的，但是一旦配置不好，遇到问题也是不好解决的。

通过authconfig-tui图形界面配置是比较简单的，但是，现在有遇到问题了。

vsftpd通过ldap验证无法正常登录，如果去读pam的相关规范然后debugpam代码去发现问题将会花费很多的时间，怎么办呢？

首先，通过strace、tcpdump确认ftp验证确实走了ldap而且返回结果是正确的。

其次，确认ssh能正常登录

第三，比较ssh、vsftpd的pam文件，通过注释掉一些行来验证是哪些配置有问题
注释掉如下行，问题解决：

auth       required    pam_shells.so

1	auth required pam_shells.so

man pam_shells

NAME
       pam_shells - PAM module to check for valid login shell

SYNOPSIS
       pam_shells.so

DESCRIPTION
       pam_shells is a PAM module that only allows access to the system if the users shell is listed in
       /etc/shells.

       It also checks if /etc/shells is a plain file and not world writable.

NAME

pam_shells - PAM module to check for valid login shell

SYNOPSIS

pam_shells.so

DESCRIPTION

pam_shells is a PAM module that only allows access to the system if the users shell is listed in

/etc/shells.

It also checks if /etc/shells is a plain file and not world writable.

然后，cat /etc/shells

/bin/sh
/bin/bash
/sbin/nologin

/bin/sh

/bin/bash

/sbin/nologin

问题查到这里基本要结束了，因为记起我们的ldap中没有设置登录shell的属性

遗留问题：为什么ldap中缺少登录shell的时候，ssh登录没有问题？

文件同步

场景：

同步大量文件从A到B，先同步全量，在同步增量

scp同步文件也能同步目录，但是同步目录中的增量就不太好使了

scp 可以同步目录，但是是完全覆盖目标目录，保持和源一样，重复复制，目标目录中多余的文件会被删掉（rsync效果一样）
不期望同步正在写的文件（比如，认为修改时间在1分钟前的文件是可以同步的；当然不能完全避免同步的时候又突然有写入）

脚本：

#!/bin/bash
ip=xxx.xxx.xxx.xxx
ssh $ip 'find /data1/files/ -type f -mtime -1 -mmin +1' |while read f;do echo $f; d=`dirname $f`; [ ! -d $d ] && mkdir -p $d; scp $ip:$f $f;  done

#!/bin/bash

ip=xxx.xxx.xxx.xxx

ssh $ip 'find /data1/files/ -type f -mtime -1 -mmin +1' |while read f;do echo $f; d=`dirname $f`; [ ! -d $d ] && mkdir -p $d; scp $ip:$f $f; done

功能：将目标机器的文件同步到本地对应目录（这里是相同目录）

注意：

同步2天内、1分钟前修改过的文件
find命令的 -mtime 是以24小时为单位计算的，如:
1. 24小时前、48小时内： -mtime 1
2. 24小时内： -mtime 0
3. 48小时内：-mtime -1
-mmin 和 -mtime不太一样
1. 1分钟内： -mmin 1 （而不是 -mmin 0）

ARP单播问题

虚拟机桥接到宿主机的网卡，虚拟机访问宿主机时有如下arp包:

说明：

arp查询之后会在本地缓存一段时间，当缓存超过一段时间后，可能实际信息已发生变化，于是发送一个单播的arp查询请求校验一下；话说既然可能会失效了，那么删掉重新查一次不行吗？

正常的arp请求是不知道某IP在哪里，只好广播，谁是谁响应；由于广播的开销比较大，所以，当我知道很有可能某IP就在你那里的话，我不妨先发个单播包校验一下，如果确实发生变化了，就再发送广播包不迟

参考： http://www.ietf.org/rfc/rfc1122.txt

linux 之 futex

当我们strace -c pid的时候，经常会发现futex占用大量时间，如下图：

那么， futex究竟是个什么东西呢？

futex – Fast Userspace Locking system call

一般来讲，futex是用于多线程程序中线程同步使用的； futex本身不是一个锁，但是可以利用这个机制实现锁。

传统的多线程同步是这样的（不保证说的对）：

请求锁：

成功 –>干活 –> 干完 –> 发送信号给要加锁的线程

失败 –> 睡眠–> 收到信号–>继续请求锁

futex类似这样：

void waitUntilNotEqual(volatile int* addr, int value) {
    while (*addr == value) {}
}

void waitUntilNotEqual(volatile int* addr, int value) {

while (*addr == value) {}

}

系统调用之 restart_syscall

在我们使用strace的时候，经常会遇到如下情景：

你们 restart_syscall 究竟是个什么系统调用呢？什么时候会用到该系统调用呢?

一般情况下，如果遇到这种情况，那么使用pstack看看进程的调用栈，会发现，很可能该进程处于sleep状态。

下面有一个实验：

strace php -r 'sleep(5);'

1	strace php -r 'sleep(5);'

回车之后，当看到nanosleep({5, 0}, 立即ctrl-z，会发现程序stop了，然后，输入 fg（切换后台任务到前台，继续运行），这时，又一次看到了restart_syscall 了，如下：

或许可以这么解释：当程序收到一个信号时，离开正在执行的系统调用去处理信号，处理完信号（上面是直到收到一个sigcont信号才算处理完上刚才的信号），继续执行运来的系统调用，似乎就是通过restart_syscall 这个系统调用进入未完的那个系统调用的，所以说，看到restart_syscall意味着刚才的系统调用没有完成的时候被迫去做别的了；

为什么strace一个sleep的进程总会看到这个呢？

strace本身是先给正在执行的进程发了个信号（什么信号？….然后….），再然后发送SIGCONT信号让程序继续执行，于是，程序进入restart_syscall ; 当然，不是所有系统调用可以中断的，也不是所有系统调用中断后都能restart的，参考： man strace

总结：

你几乎永远没有机会去调用restart_syscall 这个系统调用的

参考资料： https://www.quora.com/What-are-the-use-cases-of-restart_syscall-system-call-on-Linux-Systems

linux源码在线看： https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/

gdb调试python

gdb对python的调试支持还是比较成熟的，如果gdb版本（>7）够高的话，gdb默认编译了对python的支持，可以直接:

gdb -p pid_of_python

1	gdb -p pid_of_python

当然，需要先安装对应版本的python-debuginfo

参考资料：

1. http://www.cnblogs.com/dkblog/p/3806277.html 这里的libpython.py 可能并不需要

在gdb可以使用generate-core-file命令生成一个coredump文件。之后可以用gdb –core来打开coredump文件进行debug。避免一直attach住进程，可以快速重启恢复服务
gdb-heap是gdb的一个扩展。可以打印Python的内存使用情况

mysql 数据导入导出

场景：

mysql导出导入大数据文件时，如果文件很大，导入时最好先把索引都去掉，如果导出时包含表结构，则在一个很大的文件上编辑表结构将非常麻烦，所以正确的做法：

1. 导出表结构（不包含数据）

mysqldump -d dbname tablename >tablename-schema.sql

1	mysqldump -d dbname tablename >tablename-schema.sql

2. 编辑表结构（去掉索引）

3. 创建表

cat tablename-schema-no-index.sql|mysqldump dbname

1	cat tablename-schema-no-index.sql\|mysqldump dbname

4. 导出表数据（不包含表结构）

mysqldump -t dbname tablename >tablename-data.sql

1	mysqldump -t dbname tablename >tablename-data.sql

5. 导入数据

cat tablename-data.sql|mysqldump dbname

1	cat tablename-data.sql\|mysqldump dbname

6. 添加索引

附：

解压大文件直接到mysql：

tar -zxf bigfile.sql.tgz -O |mysql

1	tar -zxf bigfile.sql.tgz -O \|mysql

如何知道灌到什么程度了？

tar 在解压的时候，使用的也是外部的解压程序（如：gzip），通过管道交互，可以查看gzip读的那个文件读到哪里了，如：

cat /proc/pid_of_gzip/fdinfo/0

1	cat /proc/pid_of_gzip/fdinfo/0

vagrant 之 insecure key

vagrant package 有两种方式，一种基于虚拟机名字的，一种基于vagratfile的。

对于自己安装的虚拟机，如果已经在使用privatekey的方式在登录了，那么package的时候，虽然该privatekey也能被打包，但是会认为该privatekey是打包的人提供的，不够安全，所以，会认为

正确的打包方式：

基于Vagrantfile打包，Vagrantfile中不要设置privatekey_path ，而是设置config.ssh.username 和 config.ssh.password ,并且虚拟机是开机状态
vagrant package –vagrantfile Vagrantfile –output my.box
此时，会自动生成一套全新的秘钥对，并且注入到虚拟机内，如下：
然后自动关机并打包