Tags
- Airchina
- Android
- Anti-Spam
- Bluetooth
- bugs
- ChinaSouthern
- Django
- DNS
- Enterprise
- fastcgi
- Hainanair
- HAM
- HongKong
- InnoDB
- IPTV
- iSCSI
- kubernetes
- large-scale
- lighty
- Linux
- Logging
- Macao
- Meituan
- MM
- MySQL
- nginx
- Oracle
- Outdoor
- Percona
- Photo
- postfix
- Python
- RedHat
- Sentry
- systemd
- Traffic
- Travel
- Virtualization
- xtrabackup
- 信用卡
- 奥运
- 美食
- 规范化
- 软件工程
Meta
Blogroll
Mine
Tag Archives: Linux
GNU和BSD版本的xargs 分隔符不同
例子：list=”a b c d e”; echo $list |xargs -n1 -I{} echo begin {} end 在Mac上执行结果：begin a endbegin b endbegin c endbegin d endbegin e end 在Linux上执行结果：begin a b c d e end 我这里的需求是有一堆输入，要分别以其为参数，执行一些命令，无论是否成功都要对所有目标执行，所以1 “一些命令”我选用shell function来实现，在其中读了$1作为本次处理的目标2 “所有目标”我选用xargs；如果选Parallel还得额外安装 结果发现xargs在切分“以空格为分隔符”的字符串的时候，GNU版本默认不切分，结果把整个“含空格分隔符的字符串”传给函数，执行了一次，而函数里又选了$1作为本次执行目标，其综合结果就是只对列表中第一个目标执行了一遍 更惨的是我对比的时候是在Mac上做的对比，怎么看怎么顺眼…… 最后请教同事，用xargs的-d参数解决的 GNU … Continue reading
昨天遇到collectd exec插件的bug，顺便发现他们不按套路出牌啊
先说症状： collectd exec插件调用的几个外部脚本，其中总会随机有一个缺少COLLECTD_HOSTNAME和COLLECTD_INTERVAL环境变量。 搜了一下是这个bug https://github.com/collectd/collectd/issues/3041 然后我好奇啊，就读了一下修改前后的代码，发现collectd不按套路出牌。 带有bug的版本： 先setenv()设置主进程自己的环境变量，然后尝试fork()，如果成功，在子进程里execvp()；主进程重新unsetenv()恢复主进程自己的环境变量。在多个exec密集执行的时候，都会访问主进程的环境变量，会有race condition，偶尔会发生前一个exec插件刚unsetenv()然后后一个exec插件开始fork()的情况，丢失环境变量。 修复后的版本： 先fork()，在子进程里准备环境变量数组，尝试execvpe()带签署环境变量数组作为参数，执行新进程（execvpe()为GNU专有扩展），或者先设置extern char **environ指针指向准备好的数组，然后execvp()执行新进程直接继承。 别人家套路： 先准备环境变量数组，然后fork()，在子进程里execve()并使用前述环境变量数组作为参数。
supervisor泄漏进程案例分析
起因 前几天使用 salt ‘*’ test.ping 的时候发现响应内容中有一些“某某minion was already deleted from tracker, probably a duplicate key“的提示信息。刚开始误以为是salt-key管理有问题，尝试删除再重新accept，但是依然会出错。到该minion上检查，发现上面运行了两套salt-minion*三层进程树，一共6个进程，其中一套的PPID为1，另一套的Parent是supervisord。 然后就开始研究这种情况是怎么产生的，发现有两种可能： 第一种可能 supervisor本身不被systemd监管，被SIGKILL信号杀死时，因为SIGKILL由内核直接处理，所以并没有机会关闭下属的进程，导致下属salt-minion进程树泄漏。而且不但salt-minion进程树泄漏，连同样被supervisor监管的另一个服务也一并泄漏，二者的PPID都变成了1号。 不过，如果supervisor本身被systemd监管，在其主进程被杀死时，systemd会给整个service slice cgroup里所有进程补刀，所以并不会泄漏进程；如果supervisor是被SIGTERM信号杀死，它也会给下属子进程发信号，一般也不会泄漏进程。 第二种可能 supervisor没有受到影响，正常运行；supervisor监管的salt-minion三层进程树的其中最高层进程（也就是supervisord的直属子进程）被SIGKILL信号杀死，随即，第二层进程exit(1) （不明原因，可能需要看一下salt-minion源码），导致第三层进程变成孤儿。经检查源代码的_spawn_as_child()函数，supervisor针对其监管下的每一个服务，都是采用 fork() + setpgid() +execve() 的方式来启动的，在调用setpgid()改变了process group id之后，第三层进程的孤儿收养关系就不再归属于supervisord进程，而是归属于1号进程。 随后supervisor会重启salt-minion服务，产生新的3个进程，加上之前剩下的，一共4个。 结论 考虑到观察到6个进程而不是4个，实际发生的大概是前一种情况 supervisor虽然有“能力”处理进程退出之后马上重启的工作，但是因为使用了setpgid()把下属服务与自己隔离，没使用cgroup机制把下属服务单独圈起来，又不具备1号的神圣地位，其实它并不知道到底下属了多少、哪些进程，从机制原理上就根本无法保证所有下属的孤儿进程都被其reap。还是建议不要在严肃场合使用 1号进程神圣，所有的服务进程监管工作都应该交给1号进程来处理
滥用crond触发systemd-login故障一例
故障现象 2021年1月20日接到通知，要把systemd升级到219-73.tl2.10或以上、并把rsyslog一起升级，以修复/var/log/messages无日志内容的bug。经实验，发现使用yum升级两个软件包之后，systemd-logind的可执行文件也被更新，导致该服务处于原可执行文件已删除的状态，所以我提议，在升级步骤中增加重启systemd-logind服务的动作。在Ansible playbook里，因为不能表达“大于219-73.tl2.10“这种范围型版本号，所以就明确指定systemd的版本为当前yum能自动安装到的最新版本219-78.tl2.3 2月1日由同事执行更新操作之后，大部分节点都正常工作，但有两台发生重启事故，另有一台上的 35777 systemd-login进程占内存高达4～6G。这三台恰好是一组elasticsearch的三台master节点，均为C8机型，即16G内存的kubernetes容器。 检查修复 我尝试重启剩余的这台的system-logind，发现新进程3851号仍然占6G内存。查看/proc/3851/smaps，该区域为heap；用pmap命令查看，显示为[ anon ]。对比正常服务器的同一个内存区域，才244K而已。 检查三台故障机及其宿主机的日志，发现大量oom记录，其中重启的两台所属宿主机的kubelet也发生故障重启：Feb 1 18:43:50 TENCENT64 kubelet: panic: runtime error: invalid memory address or nil pointer dereference 先gcore一份保留故障现场。由于操作系统组同事不登录上来观察，仅提供重启进程等建议，我只好自己做检查。根据建议，检查了dbus服务（dbus-daemon进程），发现也是可执行文件被删除的状态。检查yum日志，发现在去年6月升级了dbus包，但是服务进程是3月5日启动的，也就是升级包的时候并没有重启这个服务。再次尝试重启systemd-logind，新进程14278号，发现用内存VmPeak: 5270484 kB；但是过了一会儿再观察，发现增加到了VmPeak: 6599828 kB。这说明内存的增长是一个过程，虽然增长比较快，但并不是一下子就6G的。于是我决定strace一下它。 先关闭systemd-logind服务。使用命令strace -ff -s 1000 -p 1挂在systemd主进程上做跟踪，并用-o参数把多个进程的跟踪记录分别写在文件里。然后启动systemd-logind服务。这样，strace可以跟踪到 1号进程clone+execv执行systemd-logind的瞬间，以及systemd-login最开头的行为。检查systemd-login的strace记录，发现大量访问 /run/systemd/session/ 目录下面文件的动作。检查该目录，发现大量残留文件。搜索，发现 https://www.jianshu.com/p/343a072e2521 … Continue reading
经典错误——使用/etc/security/limits.conf配置文件 和 ulimit -n命令
很多以讹传讹的半桶水文章，都教人修改/etc/security/limits.conf配置文件来放宽“打开的文件数量”限制，如果可以再多一滴水的话，还会加一句“重启后生效”。 其实，使用这个配置文件，和使用ulimit -n命令一样，属于很经典的错误。 设置或放宽“打开的文件数量“限制，其本质是调用了setrlimit()函数，设置了RLIMIT_NOFILE资源。在有特权的程序中调用这个函数，可以提高上限（放宽限制），而普通权限的程序只能自己勒死自己和新生的子进程。 而/etc/security/limits.conf这个配置文件是怎么生效的呢？其实用dpkg -S或rpm -qf查一下就很容易知道，这个文件是pam_limits.so的配置文件，而pam_limits.so是在/etc/pam.d/中被login和sshd等多个配置文件声明将要被调用的。 系统开机的时候，1号进程init“自然而然”是root身份运行，其下属的getty/login和sshd进程，也都是root身份。这些程序都可以随意调用setrlimit。当身份认证（部分工作由PAM来做，所以可以读shadow文件）完成之后，login和sshd的子进程会为用户准备好session（网络登录调用pam_mkhomdir建设HOME目录、pam_limits模块设置rlimit、pam_env模块读取/etc/environment设置环境变量，甚至显示motd这种功能也是PAM模块实现的）并将自己降级到登录的用户身份，再启动一个shell给用户使用。 /etc/security/limits.conf 只对“调用过pam_limits.so“的登录过程有效。但并不是所有场景都经过这个过程的。而ulimit命令呢，它本身只是shell是一个内部命令而已，只对“该shell进程”及随后新产生的子进程有效。 但是需要放宽rlimit的程序，往往不是在shell中由用户手工运行的程序，而是提供大规模网络服务的后台进程。它们所需的rlimit，要在init脚本、service unit文件中设置；支持从root身份启动的服务，一般都有自行设置rlimit的能力。 如果不理解上面的内容，就容易引发一些莫名其妙的故障。比如之前我在FreeWheel工作的时候，前辈为后台服务写的的init脚本里没有调用ulimit -n命令，而在root用户的~/.bash_profile里有这个命令。造成的后果，就是开机自动启动该服务的时候，启动的是一个打开文件数量受限，以至于无法保持很多socket的网络服务，而当运维人员登录进去手工重启服务之后，又莫名其妙变好了，以至于没法检查这个故障到底是怎么发生的。
在嵌入式开发板上使用蓝牙耳机
简单记录一下： 安装 bluez pulseaudio-module-bluetooth 软件包 pulseaudio是用户级后台服务，视情况可能需要手工-D启动之 bluetoothctl命令进入交互式界面，先scan on 等看到蓝牙耳机之后，pair和connect到蓝牙耳机的MAC地址，看到连接成功之后scan off并退出bluetoothctl pactl list sinks查看设备，看看它支持哪些profile，有可能需要通过pactl set-card-profile将其切换到a2dp aplay -Dpulse 指定pulse虚拟设备播放文件 还没搞定录音。看起来话务耳机在handfree等模式似乎需要特殊步骤激活录音模式？
hostname和dnsdomainname命令
先讲结论： 忽略已经过时的NIS/YP相关内容（/sbin/sysctl kernel.domainname、/bin/domainname、/bin/nisdomainname、/bin/ypdomainname等） /bin/hostname、/sbin/sysctl kernel.hostname 和 /bin/uname -n 是一码事，都是本机的主机名 /bin/dnsdomainname 命令会把上述主机名按“第一个点”分成两端，输出后一段。这是简单的字符串处理的结果，在内核和DNS层面均无正式意义。 /etc/resolv.conf文件里的search或domain指令，用于从本机访问外部短主机名时，补充域名的后缀部分。 hostname命令： 通过gethostname(2)函数读到本机的主机名。在glibc的情况下，gethostname(2)不是syscall而是标准库函数，转而调用uname(2) （我不太确认调用的是glibc uname还是syscall uname）。根据 https://github.com/torvalds/linux/blob/master/Documentation/sysctl/kernel.txt#L285 的说法，/proc/sys/kernel/hostname、sysctl hostname 和hostname命令应该是功能相同的。 hostname -d 或者 dnsdomainname 命令： 根据/etc/host.conf指定的顺序，先尝试/etc/hosts然后尝试DNS，查找自己的主机名。如果能找到，把第一段去掉之后，输出剩下的部分。这个输出不具备内核意义，只是主机名经过字符串处理之后的派生结果 hostname –fqdn命令： getaddrinfo()函数查询到的ai_canonname strace观察到的行为是去DNS查一下主机名（如果主机名是短形式，按需补充/etc/resolv.conf里声明的search/domain后缀）对应的A记录，只要能查到，即使返回的IP地址不是本机的也不管，就以这个主机名作为结果。 hostname –all-fqdn命令： 拿自己的IP地址们循环调用getnameinfo()函数（strace/tcpdump观察到的具体行为是去DNS查PTR记录），并全部输出
墨菲定律之多处保存必然会出现不一致——谈Linux上的时区问题
技术部的工作日报，原本是早晨9点发，脚本换了一台服务器运行之后变成17点了。算算时差也知道是时区问题。 检查了一下， /etc/timezone 内容误为 Etc/UTC，而 /etc/localtime 是从 /usr/share/zoneinfo/Asia/Shanghai 复制过来的，二者不一致。date命令使用 /etc/localtime 而 cron 按 /etc/timezone 文件执行，于是造成了执行时间不对的问题 另外需要注意的是，cron 只在开始运行时读取一次该文件，而每分钟唤醒时不再读取，所以改过文件之后还得重启该服务；又得注意的是，service cron stop 似乎并不会终止cron进程，所以……你懂的 以上就是墨菲定律之：多处保存，必然会出现不一致
不能念叨啊，一念叨就出事——兼谈xen的network-bridge脚本问题
昨晚还说呢，如果今天一天没事，这周就算安全过去了，@sgub 和@chifeng 都告诫我说不能念叨这事，今天果然！ 下午，同事远程关闭错了机器。重新开机之后，发现 xenbr0 网桥没有了。看了一下，是 /etc/xen/scripts/network-bridge 没成功运行造成的。这个脚本用默认路由所在的网卡做一个网桥，然后把虚拟机接在这个网桥上，以便使虚拟机能直接上网。但我们的服务器却有俩公网IP和俩默认路由，就把那个脚本搞糊涂了。 其实这俩默认路由是路由器上的同一个接口的两个 IP 地址，连 MAC 都一样的。我删除掉其中一个默认路由，再运行network-bridge 脚本，就成功了。
其实SYSOP手段也不是万能的，今天被迫动了一下dnsmasq的源码
今天发现电信通拦截DNS请求，把热门流量导向其内部 squid 缓存服务器。今天主要发现有两个，一个是新浪微博的 css 文件所在的域名 timg.sjs.sinajs.cn 被指向了 124.207.162.88 ，另一个是……查看某个视频的时候，浏览器状态栏提示从 124.207.162.83 下载数据，跟新浪微博被拦截的域名指向同一个 IP 段。但是页面里并没有写是从哪个域名下载视频的。于是乎，我想从公司网关的 dnsmasq 上取得数据，却意外的发现 –log-queries 参数无效，开启该参数后，按文档说明发 USR1 信号给 dnsmasq ，syslog 里却没看到 cache dump。 找了一台 Debian 看了看，是可以的。于是我立即习惯性的阴暗的认为是 RedHat 的软件质量问题。找了一套原装正品源码，编译后发现行为也是一样的。无奈了，SYSOP 手段也不是万能的，只好开始看源码。 源码里搜索 log-queries 找到 getopt 这个步骤，找到其内部名字 OPT_LOG。然后在源码文件里找这个，发现了 cache.c 文件里的 cache_dump 函数中，关于 … Continue reading