Manjusaka

随手记录一些关于用户态栈回溯（Unwind）的一些杂记和想法。 正文昨晚三点过刚吃完药躺在床上休息的时候，突然想到了 @yihong0618 的之前在群里的一个想法 我在想 eBPF 能不能 trace libpq 的协议，好像还没有人做过 我最开始的一个想法是 现在主流做法还是 ptrace 系的东西（gdb 那套），你要用 eBPF 去 trace libpq 肯定没问题，就和 Grey 用 uprobe 去 trace go 一样，手算 cast。但是这里另外一个问题是 libpq 的符号信息不一定够。我倾向你可以这样试一下，你改一下 libpq 源码，关键地方走 USDT（我看你之前用过） 不过后续我师父出来有了一个提醒 如果目标是 trace libpq.so 的调用情况，那应该目前就可以做到。.so 相比 executable 有几个优势： 它一定有动态符号表 它一定有 .eh_frameuprobe 恰好又是 attach to the binary offset 而不是 process address，所以第一个优势完美匹配 uprobe，甚至绕开...

最近工作强度有点大，写篇 Linux 相关的水文放松下 这个问题实际上是来源于在群里和人的一个讨论。一个基本常识是，子进程退出后，父进程会收到 SIGCHLD 信号，然后父进程可以通过 wait 或者 waitpid 等系统调用来获取子进程的退出状态。那么，子进程退出后，父进程有可能会收不到信号吗？答案毫无疑问是 yes 的 本文就来聊个其中一个比较好理解的场景 BTW 本文代码都基于最新分支的 Linux 源码 正文先来看一段代码Fuck，哦不，Shut up，我们先来看一段代码 123456789101112131415161718192021222324252627import osimport timeimport signalcount = 20result = 0print(os.getpid())def sigc_handler(*args): global result result+=1 os.waitpid(-1, 0) time.sleep(1)def sig_int(*args): passdef abc(): fo...

很多时候，帮助人不需要那么多理由

優しさを失わないでくれ。弱い者を労り互いに助け合い。

人生嘛，Homelab 图个乐子

实际上 IaC 这个概念的出现已经很久了，所以写篇水文来简单聊聊 IaC 的过去，现在，和将来 IaC 的过去实际上 IaC 的历史其实足够悠久。首先来看一下 IaC 的核心的特征 最终的产物是 machine readable 的的产物。可能是一份代码，也可能是一份配制文件 基于 machine readable 的产物，可以进一步依赖已有的 VCS 系统（SVN，Git）等做版本管理 基于 machine readable 的产物，可以进一步依赖已有的 CI/CD 系统（Jenkins，Travis CI）等做持续集成/持续交付 状态的一致性，或者称为幂等性。即理论上来讲，基于同样一份 Code，同一套参数构建出的产物，其最终的行为应该是一致的 实际上通过 IaC 这样的一些核心特征，我们现在能明白 IaC 兴起的原因。IaC 实际上的兴起，大背景是在千禧年之后，互联网世界迭代的速度愈发的快速，这个时候传统的手工式的维护面临着几个问题 交互式变更所引入的人的因素太大，导致了变更的不可控性 人工变更面对愈发快速的 Infra 迭代力有不逮 交互式的变更导致管控的难做，...

本来这篇文章是要在 2022 最后一个工作日前写完的，但是拖延癌发作，到现在才写完。不过还是发出来，希望里面的内容能帮到大家 背景介绍这个重构项目如果从我第一个超大型重构 PR 算起（22年12月11日），到现在已经历史一个半月了。目前重构进度已经超过了 80%，超过6+位贡献者集体贡献。这绝对是个不小的工程了 那问题来了，我为什么要发起这个重构项目呢？ 在重构项目之前，nerdctl 项目存在一个很大的问题，即 command 的入口处，flag 的处理和逻辑耦合的问题，比如用 nerdctl apparmor 系列的代码来举一个例子 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687package mainimport ( "bytes" "errors" ...

愿每个人心里，都盛开着永不凋零的蓝莲花 从2021年11月第一次发起刷题公益计划，到现在也一年多时间了。起初是为了让大家有一些特殊的动力去刷题，所以有了这样的基础规则 1题一元人民币，在打卡后向公益基金捐款。 基金池最开始由群主承担，后续有超过25位+群友集体捐款 再后来，这个群就发展成了基于技术的各种闲聊群，推荐番毒害群友群。 到目前也差不多一年多时间了，写个简报回顾一下 一、刷题公益计划截至目前，从2021年11月开始，到2022年6月作为一个阶段的结束。 共计捐款 1625 元人民币 在2022年6月，经过群友同意，再经过一轮扩资后，蓝莲花小组向一个村小项目捐款 6000 元人民币 前不久得到反馈，这笔钱已经用在应该用的地方了。开心 二. 技术分享从2022年6月开始，群友决定在群内以一周两次的频率进行分享，截至目前举行了八次分享 SRE 二三事 当前端在讨论字体时，我们在讨论什么 编译原理入门到出家 OLAP 入门出家 简单聊聊家庭网络 Homelab 101 稳定性建设101 物联网简介 三. 开源项目截至目前，群友的足迹包括不仅限于 Vue SW...

好久没写水文了，新年第一篇水文总得写一下，完成下 OKR，正好最近帮群友查了一个特殊的 No space left on device 问题，记录一下。 问题半夜接到群友求助，说自己的测试环境遇到了点问题，正好我还没睡，那就来看一下 问题的情况很简单， 用 docker run -d --env-file .oss_env --mount type=bind,src=/data1,dst=/cache {image} 启动了一个容器，然后发现在启动后业务代码报错，抛出 OSError: [Errno 28] No space left on device 的异常 这个问题其实很典型，但是最终排查出来的结果确实非典型的。不过排查思路其实应该是很典型的线上问题的一步步分析 root casue 的过程。希望能对看官就帮助 排查首先群友提供了第一个关键信息，空间有余量，但是就 OSError: [Errno 28] No space left on device 。那么熟悉 Linux 的同学可能第一步的排查工作就是排查对应的 inode 情况 执行命令 1df -ih 我...

本来想在农历年前交年终总结的，不过想了想，去年的年终总结就因为太懒导致我鸽了。所以这个“双年”怎么也得总结下2022了。不过说起来怎么还没去字节，就开始 ego 了起来。 开篇实际上每年都在觉得这一年很魔幻，但是下一年总会跳出来说“这一年更魔幻”。不过这也是人生的乐趣吧。 看了下20年总结的标题叫做”但行好事，莫问前程“，去年一下想不起标题，群内求助了下，发现”Stay Simple，Stay Naive“这个标题还不错，挺适合作为去年的总结与展望的。不过在写下这点文字的时候发现当年 +1S 的对象也已经仙去了。怎么说心里也还是有点很奇怪的感觉在里面。 不过，一日膜法，终身膜法，所以就还是 Naive 的 +1S 吧 生活去年从年初开始，我从太极图形离职后，就开始进入了我数字游民的生活。作为一个 FreeLancer，可能最大的好处就在于说免去了通勤的时间后，我可以有更多的时间做自己的事（睡大觉（不是 在离职之后，和女朋友一起换了一个新的房子，有着很大的落地窗的露台，采光很好，所以让我在这里有时间安心做一些自己的事情 所以去年在有自己的时间的情况下，我开始看之前没有怎么涉猎...