1. docker save 默认save该镜像的所有版本,而不是最新版本
记录salt的一个问题
现象:
cpu使用 接近100%
strace 跟踪结果
1 2 3 4 |
poll([{fd=9, events=POLLIN}], 1, 0) = 0 (Timeout) poll([{fd=9, events=POLLIN}], 1, 0) = 0 (Timeout) poll([{fd=9, events=POLLIN}], 1, 0) = 0 (Timeout) ... |
进程调用栈:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
Thread 3 (Thread 0x7fba3bdbe700 (LWP 31517)): #0 0x0000003967ee8ef3 in epoll_wait () from /lib64/libc.so.6 #1 0x00007fba3f043add in ?? () from /usr/lib64/libzmq.so.3 #2 0x00007fba3f06104b in ?? () from /usr/lib64/libzmq.so.3 #3 0x00000039682079d1 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003967ee88fd in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fba3b3bd700 (LWP 31518)): #0 0x0000003967ee8ef3 in epoll_wait () from /lib64/libc.so.6 #1 0x00007fba3f043add in ?? () from /usr/lib64/libzmq.so.3 #2 0x00007fba3f06104b in ?? () from /usr/lib64/libzmq.so.3 #3 0x00000039682079d1 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003967ee88fd in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fba49651700 (LWP 31457)): #0 0x0000003ea80695aa in ?? () from /usr/lib64/libpython2.6.so.1.0 #1 0x0000003ea80d72b7 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #2 0x0000003ea80d5a94 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #3 0x0000003ea80d7647 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #4 0x0000003ea80d5a94 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #5 0x0000003ea80d7647 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #6 0x0000003ea80d5a94 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #7 0x0000003ea8060917 in ?? () from /usr/lib64/libpython2.6.so.1.0 #8 0x0000003ea80d1308 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #9 0x0000003ea8060917 in ?? () from /usr/lib64/libpython2.6.so.1.0 #10 0x0000003ea80d1308 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #11 0x0000003ea8060917 in ?? () from /usr/lib64/libpython2.6.so.1.0 #12 0x0000003ea80d1308 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #13 0x0000003ea8060917 in ?? () from /usr/lib64/libpython2.6.so.1.0 #14 0x0000003ea80d1308 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #15 0x0000003ea80d7647 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #16 0x0000003ea80d5a94 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #17 0x0000003ea80d7647 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #18 0x0000003ea80d5a94 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #19 0x0000003ea80d7647 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #20 0x0000003ea80d7722 in PyEval_EvalCode () from /usr/lib64/libpython2.6.so.1.0 #21 0x0000003ea80f1b9c in ?? () from /usr/lib64/libpython2.6.so.1.0 #22 0x0000003ea80f1c70 in PyRun_FileExFlags () from /usr/lib64/libpython2.6.so.1.0 #23 0x0000003ea80f315c in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.6.so.1.0 #24 0x0000003ea80ff892 in Py_Main () from /usr/lib64/libpython2.6.so.1.0 #25 0x0000003967e1ed5d in __libc_start_main () from /lib64/libc.so.6 #26 0x0000000000400649 in _start () |
从调用栈来看,就算有bug也是libzmq的bug
端口重定向工具
fpipe: tcp or udp (without encrypt)
http://www.mcafee.com/cn/downloads/free-tools/fpipe.aspx
spipe: only for tcp
http://www.enet.com.cn/article/2009/0625/A20090625491131.shtml
stunnel:
https://www.stunnel.org/index.html
关于redis短连接问题
场景:
PHP通过phpredis(https://github.com/phpredis/phpredis)循环执行如下操作:
1 2 3 4 5 6 7 8 |
<?php while(true) { $r = new Redis(); $r->connect(...); $r->auth(...); $r->set(...); $r->get(...); } |
发现connect会出现大量超过1s的情况,甚至超过3s;但是,如下图抓包所示:两次请求之间间隔了3s才发送syn请求,并且没有失败,也就是说,并非syn丢包所致,而是因为某种原因导致根本没有发送syn包;但是外部表现却是connect花费了很多时间(3s);
所以,从此推断,连接超时未必就一定是网络的问题,你们究竟会是什么原因导致client端3s后才发送syn的呢?
阅读源码发现: redis的connect用的是php提供的connect方法:php_stream_xport_create
其实,fsockopen用的也是该方法,如此的话,不放通过如下脚本直接测试connect:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<?php $errno = 0; $error = ""; $i = 0; while(true) { $i++; $time_start = microtime(1); $fp = fsockopen("10.172.90.108", 6379, $errno, $error, 5); $time_end = microtime(1); $time_use = $time_end - $time_start; if ($time_use > 1) { echo "timeout: $time_use ($i)\n"; } if ($fp) fclose($fp); } |
结果如下:
- connect超过1s的还挺不少的
- 前面300多次的时候连续出了好几次超过1s的,你们怎么会从374到13489一直没出错呢?而且,运行程序的时候也能感觉到,从第374到第13489花费时间很短的,难道这个区间根本没有发生真正的连接? strace 跟踪统计发现,确实connect了,就是说,一般情况下,connect是很快的
- 该问题可能发生在PHP中,也可能发生在glibc中,也可能发生在系统层面,排查办法:
- 写一个C的,如果不出现问题,那么就是PHP的问题;如果依然如此,很可能是系统问题
salt-cp 不能传二进制问题
问题:
salt-cp copy 了一个9MB的字体文件,结果就把内存耗光了,不解;
突然想起哪里又说salt-cp不能处理二进制文件,翻下代码看看:(注意这里的fopen)
/usr/lib/python2.6/site-packages/salt/cli/cp.py
让go get 支持gitlab
参考文章: https://baokun.li/archives/go-get-proxy/
在你的nginx中添加配置:
1 2 3 4 5 6 7 8 9 |
if ($args ~* "^go-get=1") { set $condition goget; } if ($uri ~ ^/([a-zA-Z0-9_-]+)/([a-zA-Z0-9_-]+)/.*$) { set $condition "{condition}path"; } if ($condition = gogetpath) { return 200 "<!DOCTYPE html><html><head><meta content='your.domain.com/$1/$2 git http://your.domain.com/$1/$2.git' name='go-import'></head></html>"; } |
注意:修改你自己的域名
另:
- 可能你自己的gitlab没有配置https,那么可以给go get 添加 -insecure 选项即可
- 可能你的gitlab仓库需要输入用户名和密码,那么你可以改成public的就好了
centos 修改时区
1 |
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime |
rpm打包
关于docker
- docker create -it 其中 -it选项,如果没有的话,docker exec 进去,top时会报 TERM environment variable not set. 错误 ; 其实没有关系,手动 export TERM=xterm-256color 就可以了;其实, -it 选项和1号进程为 /bin/bash 是密切相关的; 如果1号进程不是 /bin/bash 的话,-it选项没有屁用
- docker 的CMD 其实是1号进程,一定不能立即就会退出的进程,如: service sshd start 就不行,如下脚本就可以:
123456#!/bin/bash# this is a start shell for containnerservice sshd startwhile :; dosleep 10000done
- 容器可以自杀: 容器内进程使用root kill -9 1 默认是杀不死1号进程的,但是:
当strace -p 1 的时候,kill -9 1 是可以杀死1号进程的 (难道说这是个bug?)
因为docker stop时是先给1号进程发送sigterm,是在不行才kill -9 ; 所以,1号进程最好能合理处理sigterm信号,最后退出;然而,容器内的root进程是有权限给1号进程发送sigterm信号的,所以,容器自杀其实是很方便的 - 改进版的1号进程
myinit.c
123456789#include <stdlib.h>#include <unistd.h>int main(int ac, char **av) {while(1){sleep(10000);}return 0;}
gcc -o myinit myinit.c
myinit.sh
1234#!/bin/bash# this is a start shell for containnerservice sshd startexec /sbin/myinit
- 其实还不够
你会慢慢发现,ssh连接失败,因为:sshd接到连接请求之后,检查是否session太多了(默认最大10个),超过了就不伺候了,直接断开; 为什么会太多了?sshd每次接到连接请求,会fork => fork (两次fork)出来一个子进程处理请求,就因为是两次fork,这个新的sshd进程便“过继”给了1号进程;但是上面的1号进程还不够成熟,不会带孩子,当这个新的sshd进程退出的时候,就需要1号进程来做一些处理(如:清理进程表项),但是1号进程还不会,于是新的sshd进程会处于 <defunct>状态;而sshd的祖先还以为该session还没结束,就不再接受新的请求了,解决办法:添加信号处理,如下:
1234567891011#include <stdlib.h>#include <unistd.h>#include <signal.h>int main(int ac, char **av) {signal(SIGCHLD, SIG_IGN);while(1){sleep(10000);}return 0;}
参考资料:
https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/
https://github.com/phusion/baseimage-docker/blob/rel-0.9.16/image/bin/my_init
dockerd 提供了init 和init-path的选项,允许配置是否启动一个指定的(默认的)init进程, 该进程就是为了转发信号和收割僵尸进程 的 - 上面sshd对于连接请求是两次fork的说法不太对,见下图:
99、134进程并没有立即退出(不过,一旦意外退出,则 101、136将会被1号进程收养)
还有一种情况为:sshd被restart了,这时候30号进程退出,99、134被1号进程收养,如下:
由于我重启了sshd,再次连接就会失败,如下:
为什么呢?
稍后再查,至少可以确定的是,启动容器时候启动的sshd是可以正常服务的,登录进去重启的sshd是不能正常服务的
see also : https://docs.docker.com/engine/examples/running_ssh_service/
关于docker的内存限制:
- 如果每个docker容器限制最大使用4G,则可能会使用超过4G,(似乎是使用了交换分区了)
- 如果宿主机有64G内存,则允许docker容器内存总和大于64G,(这个不会也和交换分区有关吧)
- 文档说–memory-swap=-1 就禁止使用交换分区了,但是测试发现还是使用了1倍内存的交换分区
缅怀一下阿里云云引擎
学习一下人家下线产品是咋写的:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
阿里云云引擎ACE产品转型下线公告 尊敬的阿里云用户: 您好。 自ACE产品上线以来,我们致力于为用户提供更好的服务以及体验。 今日,我们非常遗憾的通知您,由于产品体系升级,阿里云云引擎ACE产品将于2016年5月12日整体下线,届时ACE产品(包括扩展服务)将全部停止服务(整体下线安排见后)。我们推荐您使用云服务器ECS、弹性web托管、容器服务等其他云计算产品。 在此期间,ACE产品团队将会: 1、 如选择使用ECS或弹性web托管服务,我们将提供相应的代金券; 2、 在用户管理控制台为您提供数据下载的快速通道,您可通过此快速通道进行数据下载\备份以及迁移的工作(如您选择阿里云其他产品的,阿里云并将提供对应的迁移方案); 3、 针对未到期的包年包月ACE产品,阿里云将启动退款程序(具体方案将通过站内信或邮件发送给您)。 请在ACE服务到期日之前安排好数据,逾期将无法找回。 如您在下线过程中遇到问题,可直接从阿里云用户中心—工单管理—提交工单-云引擎ACE提交工单。 因产品体系升级给您带来不便,我们深表歉意。 再次感谢您对阿里云的支持! 阿里云计算有限公司 2016年4月6日 常用Q&A 1、云引擎ACE为什么要下线? 答:您好,非常抱歉,由于产品体系升级,业务调整影响,云引擎ACE将不再提供服务。 2、已买了云引擎ACE的包年包月某某版本,在2016年4月6日以后服务还未到期,产品下线了怎么办? 答:您好,已购用户一方面我们会根据您购买ACE的不同语言针对性的推荐阿里云其它产品并提供对应的迁移方案,另一方面会启动退款程序,已购用户的邮箱或者站内信、短信4月6日会统一收到通知,请收到的用户及时查到您的手机、邮箱或阿里云账户中心 3、已买了按量付费云引擎ACE,产品下线了怎么办? 答:您好,一方面我们会根据您购买ACE的不同语言针对性的推荐阿里云其它产品并提供对应的迁移方案,另一方面我们已争取替代产品的最大化代金券,已发放至您的账号,您可以直接用来购买新产品 4、产品下线了,我的应用数据怎么办 答:您好,5月12正式下线之前,我们会一直提供数据下载快速通道,您可以随时做好数据下线和备份工作,若您选择阿里云其他产品,我们提供推荐产品的迁移方案,您可直接根据方案迁移数据 5、我的应用正好在你产品下线期间到期了怎么办? 答:您好,为了保证用户体验,在4月6日-5月12日期间到期的客户可以继续使用应用直至5月12日产品正式下线为止。 6、你们产品下线,推荐我购买其他产品有没有优惠? 答:您好,我们已争取其他产品的最大化优惠代金券,已发放至您的账号,您可以直接用来购买新产品,代金券有效期为30天,请及时使用 。 7、下线期限,包年包月超过流量套餐配置外流量还收费吗? 答:您好,4月6日-5月12日针对超套餐的流量系统仍计费,超出部分按照¥0.80/GB收费,基本版和普通版每个月50GB免费公网流出流量,流入流量免费,专业版每个月80GB免费公网流出流量,流入流量免费 |