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
Author Archives: JulyClyde
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()并使用前述环境变量数组作为参数。
滥用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
浅谈用过的几台120相机
之前回老家的时候,发现家里多出一台海鸥4A相机,于是2019年要过来玩了几下,开始尝试玩120反转片。但是因为最初两卷拍暗了,以及经历其中有一张拍不下去只能过卷,所以对这台机器充满了怀疑,就搁置了,又买回一台Bronica ETRSi,然后过了几个月又买了一台Mamiya M645Pro。玩了几卷之后,觉得有必要浅谈一下这几台相机的使用感受,以便将来回忆和复习。 先简单介绍一下这几台相机: 海鸥4A:竖式外观一体式、两个镜头联合皮腔对焦、腰平取景、镜间快门、过卷联合快门镜头上弦(打开多重曝光之后可以只上弦)、自动停片(固定6*6画幅)、双反相机 Bronica ETRSi:“前后长”外观模块式、螺旋对焦、选配眼平测光取景器、过卷联合快门镜头上弦(打开多重曝光之后可以只上弦)、镜间快门、自动停片(固定6*4.5画幅)、单反相机,外观是“前后长”的 Mamiya M645Pro:“前后长”外观模块式、螺旋对焦、选配眼平非测光取景器、过卷联合快门上弦(打开多重曝光之后可以只上弦)、焦平面快门、自动停片(固定6*4.5画幅)、单反相机 120中画幅胶卷,宽度6厘米,所以成像尺寸的一个边固定为6厘米,不过120的优势是另一个边长度可变,有6*6、6*7、6*8、6*9、6*4.5等多种画幅。拍摄完成之后,胶卷会在另一个轴上重新卷起来,并用背纸贴封条保护起来,不同于135胶卷拍摄完成之后退回硬质保护壳的那种做法。 双反相机因为取景和拍摄的两个镜头上下排列(左右排列、眼平取景、无反光板那种相机叫旁轴,不叫双反),机身纵向尺寸较长,内部空间大,新旧胶卷可以上下排列;考虑到腰平取景,拍摄正方形或者landscape形状照片,导致画幅尺寸不超过6*6。 而模块化单反很多都是“前后长”的外观,从前到后分别是镜头、反光镜箱(即机身)、胶卷后背三个组件,反光镜日常呈45度反射,拍摄时上翻到水平,所以反光镜箱的上下方并没有更多的空间需求,比成像面积稍微大一点点而已;胶卷后背的尺寸一般也就和机身一致,导致胶卷在后背里需要经过一个omega形状的弯曲才能放置。很多人因为不理解这个扭曲的走向,把胶卷装反,用背纸去接收光,最终拍摄失败。 说说快门的区别:海鸥4A和Bronica ETRSi都是镜间快门,即快门是镜头的一部分。好处是可以在任意快门速度上实现闪光同步,坏处是镜头必须用与机身适配的型号,且安装拆卸镜头的时候要求机身镜头均已上弦。Mamiya M645是焦平面快门,取下胶卷后背即可看到机身后面的布帘,对这种相机,其实随便插个能完成光线调节的东西在前面都能拍。 反光镜的区别:海鸥4A、Bronica ETRSi拍摄之后都是反光镜不复位的,到下次上弦的时候镜子才重新回到45度;M645Pro拍摄之后就回镜,对于高频抓拍略有一点点好处。 多重曝光:ETRSi和M645Pro,其多重曝光开关其实就是个离合器,把胶卷后背的齿轮和机身齿轮分开,就能实现只上弦不过卷的功能;海鸥4A的我没看明白是咋回事,都隐藏在机器里面了。 闪光灯:海鸥4A只能用PC线接闪光灯,且没有合适的安装位置,你需要一位摄影助理;ETRSi可以通过PC线,也可以通过选配的过片手柄上的ISO热靴;M645Pro机身左侧自带一个ISO热靴,但是Sony MI接口闪光灯的接口略微长一点儿,而M645Pro的热靴插口最前面有“墙”,导致插不到规定深度,电路无法接通。 快门线:海鸥4A和ETRSi可以插机械快门线,也就是像自行车闸线似的那种,外面管道里面伸出钢丝那种;M645Pro需要一种特殊接口的电子快门线接通左侧的开关,在闲鱼我只看到一家卖这个的。 自拍倒计时:海鸥4A在镜头上;ETRSi在镜头上;M645Pro在快门按钮旋转到倒计时模式。 电池:海鸥4A不需要电池;ETRSi需要4LR44给电磁快门、测光取景器供电,没有电的时候提供一个固定速度的安全快门;M645Pro也需要4LR44电池,但是没电的时候就完全不能用了。 RB67,貌似中间的后背适配板是不带机械传动的,胶卷过片、镜头上弦、反光板翻转三个动作分离。 海鸥4A,网上流传说如果先上弦再改快门速度,会断弦,我还没敢试……
Posted in 默认分类
Leave a comment
配置管理 vs provisioning 及配置管理工具的几点随想
关于“怎么构建一个确定的运行环境”这件事,有多个流派,其中一个是配置管理,另一个是provision流。 配置管理流派,适合于物理服务器、虚拟机等等,有机会长期存活的环境。因为它们有机会长期存活,在其生命周期里需要使用技术手段去维持一个有序可控的状态,排除软件运行时累计的旧日志和临时数据、手工操作带来的计划外变更等等影响。 而provision流派,直接从模版构建一个(容器或虚拟机)实例起来运行,用完就扔,基本上没有重新调整的价值。这种东西往往依赖于服务注册与发现机制,因为在它真正起来运行之前,网络通信方面的参数无法被外界预知,外界不知道如何跟它通信;对于日志和数据,也提倡使用显式远程的方式去访问。 再说说配置管理工具的几点随想: 我最近一年在给下属的一个公司做一些产品运维工作,其中遇到把设备投放到客户的网络环境去运行这种情况。考虑到网络通信的问题,我只好选择了“反向连接”的saltstack软件。在通信的角度来考虑,配置管理工具可以分为:master主动连接minion(ansible等)、minion主动连接master(puppet、saltstack等) 今天听师兄说他的一个同事因为认知问题,把一批机器glibc给删掉了。尝试恢复的时候,他发现ansible无法正常运行(我猜想sshd启动python的时候因为缺glibc而失败了),只好改用saltstack。因为saltstack的salt-minion是长期运行的,一旦启动之后,外部依赖较少,才能在glibc被删除这么极端的条件下苟活。在“有没有agent”的角度考虑,配置管理工具可以分为:有agent(saltstack、puppet、cfengine等)和无agent(ansible等) 另外,其实还有一个分类角度,就是主动和被动。saltstack和ansible是主动式的,运维工程师可有更多的主动权,可以用手工指定minion,或者指定批次规模分批执行等手段,控制变更的节奏;cfengine、puppet等是agent定时刷新式的(虽然听说也可以主动?不过我经验较少还没用过),得按定时器来,这种情况下就得运维工程师多看监控了,一不小心,死都不知道怎么死的。
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记录),并全部输出
为什么有些系统是动作式的而非描述式的?
接手一个旧系统,上线发布是“拷贝文件过去,替换掉,重启服务”这样的,而不是“把编译好的东西打包,发上去安装,包的scripts部分带有重启动作”。 是否打包、包里包含什么,很有讲究: 查询当前版本号:XXX -v vs rpm -qi XXX 重启服务:killall XXX && sleep 30 && XXX vs /sbin/service XXX restart 删除软件:rm -fr XXX vs rpm -e XXX 安装依赖: ldd XXX |xargs -n1 yum provides |xargs yum -y install vs rpm -i XXX … Continue reading
免签过境韩国、坐船去日本手记
我总有一种不愿意走回头路的情结,虽然给自己找了许多麻烦,依然乐此不疲。 这一次,经@tigerWu 提醒,我打算从韩国坐船去日本,以期获得一个日本的“上陆许可”。虽说日语里上陆就是入境的意思,但在汉语看来,有明确的从下到上的方向指示,也就是说得从海里上来才算。 去韩国驻华大使馆网站看看,中国公民持日本旅游非团体签证可以免签证过境韩国并给予30天入境期,查验标准是下一段“机票”。但我想坐船啊!那会不会是翻译有问题呢?要知道韩国大使馆上的汉语文件基本上行文都狗屁不通。再去看看韩国出入境管理局的网站,其英文版写了“flight ticket”。 这么看来是没戏了?我不甘心,就给“国民申闻鼓”写信,等不及回答又给出入境管理局的immigration contact center打电话,第一次问仁川机场进、釜山海港出,被拒了。不过比较有意思的是这个呼叫中心并不是直接做出行政解释,而是客人报告了自己的行程计划之后,她们代为向入境口岸当局咨询。考虑到中国对外国人的72小时免签证政策限定外国人不能离开口岸城市,我就尝试咨询釜山机场进、釜山口岸出,获得了允许,遂立刻买票,但为时已晚,只买到了没有头等舱的一架飞机的商务舱。(插播八卦:东航卖大韩航空的票比大韩自己卖的便宜)与此同时,我之前向韩国信访局“国民申闻鼓”递交的信访“是否可以空进海出,没指定具体口岸咨询”也收到了回答,我还到处求爷爷告奶奶找人翻译,后来发现其实有汉语翻译版的回答,就是:不限定转乘空路或海路。我把这一页打印出来了。 2月4日,大韩KE830,办理登机牌遇到了麻烦,地服代理请示大韩航空工作人员,我出示联程船票和信访记录之后拿到登机牌;中国边检出境,按规定应该查验联程客票,但都没理我就直接把中国出境章盖在了日本签证旁边。 到釜山机场,iPad丢了,于是落了单,在后面跟机组一起,机组走专用通道,我走外国乘客通道,是一位大妈入境官。入境官翻了半天,我主动提醒我是visa free transit资格,然后出示票。该女入境指着班次号问:这是flight吗?我说是ship,她拿不准,就问韩国人通道那个男入境官,然后我就被提到那个通道受审去了。因为JR九州beetle航运公司的船票确认页只写“釜山发”没说去哪儿,男入境官不能确认这是正确的票,我又重申了我从Busan international ferry Terminal走,要去日本的Fukuoka,但他还是将信将疑,又问我是不是crew,我说不是之后,被拉出来去条凳上坐着(传说中的边检小黑屋?),入境现场指挥官,一位大妈过来问我,入境期间准备去哪儿玩,我说JSA(也就是板门店)她说板门店很远啊你知道吗,我说我做坐韩国高铁KTX,我有KR PASS,一种外国人专用的票。然后各位入境官扔下我不理,带着护照走了!!!这时船票在他们手里,信访函在我手里。过了一会儿,指挥官和男入境官把我带到入境通道,先盖章,然后手写了截止日期,又写了个不知道是TS还是TIS的字在入境章下面,这时还扣着,又说了我几句应该详细说明啊什么什么的,然后才用摄像头拍照,又说了我几句,最后主动和我握手,这事入境官的表情是很友好的。 2月8日,我提了行李到釜山火车站,经案内所工作人员指点,到站后去坐去往ferry的shuttle bus,但是没找到,只好打了个出租车去。一打吓一跳,原来google maps标的那个terminal现在已经不用了,新的在站后的左前方(东北),出租车到南边路口掉头从我到港口。巧的是,好像韩国人找零算法和美国人一样,出租车费2800、咖啡4800,我给整几千加三百,他们很难理解我是要一个500硬币找零。值得注意的是,港口的指示牌写boarding为“登机、搭乘”,写“便名”为“flight”,甚至有个指示牌写“快速船 登机口 flyer gate”我一直以为flight是飞机航班,而船班叫voyage呢!! 日本入境,边检极其顺利,其中问了我要去哪儿,我说福冈、仙台、东京,问我是飞过去吗,我说我有JR PASS,坐火车去,就给我贴了从海里上博多港陆地的“上陆许可”一枚,其实和上次大阪关西机场的只差下边的地名不一样。海关,又跟上次一样搜我的箱子,我长得有那么像走私犯吗?而且那个女关员还钓鱼执法,问我是不是住本地,我说不是啊我是中国人,然后就问那海关卡上那个地址是什么,我说那是hotel;然后又问我去哪些地方玩;最后甚至指着签证问这是什么,我说那是签证啊!!然后就过关了。他们是在考察什么? 结论:由于韩国出入境管理局各口岸部门执行政策不一致,目前这么走并不是一个很靠谱的方案,而且边检入境问话有时会有陷阱,比如问我是不是crew、问境内怎么交通之类的,稍有不慎就有可能被认为是有问题的。韩国边检把我扔在冷板凳好几分钟,谁知道是去打电话核实船票还是打电话请示政策去了…… 《中国合伙人》教导我们:真实、自信、具体、合理,是签证的基本思想基本哲学,我的行程是真实的,就不怕核查、我的行程是符合信访回信解释的,也应该能进去。 不过我觉得,我得以自己的真实经历,去督促船运公司把票写清楚,不要只写起点站。 2月8日,写于博多
Sentry整理杂记
本讨论均基于Sentry 7.7版本 插件机制 自带插件 src/sentry/plugins/ 每插件一个目录 自带插件loader:src/sentry/conf/server.py 里的 INSTALLED_APPS tuple 外装插件loader:utils/runner.py 里的 install_plugins()函数,对iter_entry_points()遍历并将其加入 INSTALLED_APPS tuple 中 外装插件注册:插件的 setup.py 里执行注册 entry_points 的过程: 例:https://github.com/getsentry/sentry-groveio/blob/master/setup.py 参考资料:https://pythonhosted.org/setuptools/pkg_resources.html #!/usr/bin/env python import pkg_resources for ep in pkg_resources.iter_entry_points(‘sentry.apps’): print str(ep) for ep in pkg_resources.iter_entry_points(‘sentry.plugins’): print str(ep) sentry-jira … Continue reading
某种情况下PATH不生效的问题
今天遇到的情况,我同事在 virtualenv 里执行 gunicorn 运行 Django app,出来的 Django 错误信息却是 /usr/local/ 路径下面那套 Python 里的: 2015-09-18 15:32:47 [11538] [ERROR] Error handling request Traceback (most recent call last): File “/usr/local/lib/python2.7/dist-packages/gunicorn/workers/sync.py“, line 131, in handle_request respiter = self.wsgi(environ, resp.start_response) File “/usr/local/lib/python2.7/dist-packages/django/core/handlers/wsgi.py“, line 236, in … Continue reading