8月 072018
phpor
8月 062018
首先，nsenter想进入进程的名字空间看看都是失败的：
详细的关键信息如下：
看看进程在干啥：
wchan 显示不全，这样来看：
或者更直接的如下：
其实不知道为啥走到了这个系统调用，更好的办法：
直接看进程的内核栈：
大概是内存资源不太够吧，其实现在已经把进程从cgroup中迁移出来了，还是不行，给对应的cgroup添加更多的内存也是不行
试图将915的cpuset cgroup迁移到其它地方时，阻塞了，（难道某个事情没有完成时是不能切换cpu的？）,此时，连查看 /proc/915/cgroup 也要阻塞了：
此时也无法修改该cgroup的cpuset集合：
对应的该容器的xfs进程处于D状态：
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.7–startvm138fd168-b0ce-441e-9514-cf1145b6566e–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.8–startvmbd1542ca-323b-4cde-99ee-17bc8ae48f63–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.9–startvmef0063fc-e42d-4feb-beb4-6d86ab666ac1–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.10–startvmbcdf6b3d-6909-4040-bd68-0753f5c1d89c–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentwin7–startvm37305191-6f8b-498d-ac29-4155a838fca0–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.6–startvm0a9902dd-fbc1-4228-8b7f-281a0c4158e9–no-startvm-errormsgbox
参考：
8月 022018
办法1： 使用ps命令
进程已经活了多长时间了（Age）：
|
1 2 3 |
# ps -o '%c %t %p' -p 31930 COMMAND ELAPSED PID cobblerd 4-07:31:23 31930 |
这里的 %c %t 不太好记，直接man就好了，或者也可以：
|
1 2 3 |
# ps -o 'comm,etime,pid' -p 31930 COMMAND ELAPSED PID cobblerd 4-07:32:47 31930 |
关于ELAPSED 的格式： [[dd-]hh:]mm:ss
看来，这个格式是不能自定义的（比如： 折合成秒），肉眼看起来还是非常友好的，但是，程序处理起来就不大方便（比如： 比较大小，做减法等），当然，也可以写个脚本自己转换
办法2：
|
1 2 |
pid=31930 echo $(( ($(awk '{print $22}' /proc/self/stat) - $(awk '{print $22}' /proc/$pid/stat)) / $(getconf CLK_TCK))) |
相关参考：
8月 022018
UPX 是一个可执行文件压缩工具不同于其他的压缩软件，它：
- 只压缩可执行文件
- 压缩后的可执行文件依然是可以直接执行的文件，功能和没压缩的一样
- 不需要额外的解压缩工具，因为压缩可执行文件相当于给可执行文件套了个壳儿，解压缩的功能已经在压缩后的文件里面了
用途：
- 给病毒文件加壳
- 压缩二进制文件，方便下载
- 压缩docker镜像中的可执行文件，提高镜像分发效率
源码：
参考：
8月 012018
阿里云内网SLB使用：
ECS（A） —–> SLB(TCP) —–> ECS(B)
我们来看看数据包路径：
ECS（A）【 IP(A) –> IP(SLB) 】 ======> SLB (目的地址转换，源地址不转换） ========> ECS（B）【 IP(A) —-> IP(B) 】
那么， ECS（B）该如何回包呢？
因为ECS（B）认为数据包是从ECS（A）过来的，自然回包给ECS（A），而事实上ECS（B）是可以直接访问到ECS（A）的，于是乎，不经过SLB就直接回包了； 那么，数据包到了ECS（A）能被认可吗？
当然不会，因为ECS（A）只知道给SLB发送过请求，不知道给ECS（B）发送过请求。
所以， 对于这种情况，SLB的TCP模式是行不通的。同理，UDP模式也是不行的。
7月 272018
有些时候，我们通过如下方式执行命令：
|
1 |
var=1 cmd.sh |
这样，cmd.sh 中就能看到变量var ； 但是千万别写成：
|
1 |
var=1 cmd.sh $var |
这里的 $var 绝对不是1； 因为$var 是在var=1被解释之前解释的
如下：
7月 272018
办法1：
|
1 |
cat /proc/self/mountinfo |
或
|
1 |
cat /proc/self/mounts |
或
|
1 |
cat /proc/self/cgroup |
7月 252018
通过路由器的 ip flow-ordering （IP 流量排名）来监视：
在接口上添加：
ip flow-ordering internal 或
ip flow-ordering external
再设置统计周期：
ip flow-ordering stat-interval 10 #10s
通过 display ip flow-ordering statistic external 或
display ip flow-ordering statistic internal 来查看
如：
参考：
7月 242018
情景： 拿容器当虚拟机用，容器有内存也有swap
问题：
有些程序（Java）只用内存，swap闲着也不用，当内存用完时，由于有大量空闲的swap，所以不会oom，但是进程申请内存被阻塞，该进程的cmdline读取不了，就影响宿主机ps，top
7月 202018
场景： 有个同学不知道因为啥，将容器内部的 /sys/fs/cgroup 挂载到了外面的某个目录； 但是这个目录是很有用的，不想随便被挂载，如何从image中去掉呢？
docker没有给出一个方便的方法， https://github.com/gdraheim/docker-copyedit 给了一个办法，原理如下：
每个image都是有一个manifest.json 文件的，相关配置信息都在这里了，但是你看不到image文件，更无从去谈修改manifest.json 文件了，所以：
- 先通过docker save 命令将image导出成tar文件：
1docker save docker-registry.i.bbtfax.com/bee_centos7 -o /data1/centos7.tar - 在用tar命令解压文件
1tar xf /data1/centos7.tar -C /data1/centos7/ - 在解压后的文件中找到manifest.json 文件，这个文件可能不是你最终要修改的，里面的Config标识了配置文件的位置，应该就是该文件旁边的一个json文件
- 修改配置文件
- 重新打包image
1cd/data1/centos7/ ; tar cf ../centos7.modify.tar . - 导入image
123# docker load -i centos7.modify.tarThe image phpor.net/bee_centos7:latest already exists, renaming the old one with ID sha256:b14fe97b3bc959677c252e74e0ae318fa26028ac78d236a0973c3e235bf7a68b to empty stringLoaded image: phpor.net/bee_centos7:latest
我这里因为已经存在了同名的image，所以，旧的image的名字就被抢走了，但是ID没有变，新导入的image有自己新的ID