mzhan017的博客

后来发现不是没有，而是被下面的代码覆盖了，虽然没有明写case语句，但是if判断里已经包含了，使用了大于小于的判断。今天又晕了一下，在看添加GRE隧道的代码，发现这个dev_ioctl里没有关于这个SIOCADDTUNNEL处理？

所以当抓不到包的时候，需要确认是不是这种架构。如果是，需要和开发确认，是需要什么用的vppctl命令来看包内容。原因是这个pod里的业务实现是使用了VPP+DPDK，绕过了内核。今天做了件晕事，在一个pod里用tcpdump抓网络包，怎么都抓不到。通过其他方式可以确定，这个包已经到了这个pod。所以为什么抓不到呢？

原因是使用nohup在后台运行一个程序，但是在点了回车键之后，期望tshark后台运行，但是要运行的tshark程序退出了。一开始还以为nohup不兼容当前系统导致回车直接退出。后来发现是tshark命令的参数有问题。

尝试在全局压力下的所有套接字之间保持一个公平，允许低于平均使用率的套接字升高，高使用内存的socket不让申请内存。

不知道大家有没有这种错觉，会将这两种解释搞混，给阅读源代码带来稍许的困惑。所以问题有可能是在自己独有一种困惑，但是怎么破解这种容易混淆的逻辑？后来想通了，可能是抽象概念和实物之间的一种区别。比如，高压之下与高压线之下。这里按照纯的字母意思理解就是在内存压力之下。

但是从函数名称，不能直接看出一个问题：这个功能是tcp用，还是udp也用？因为函数名称是：sk_stream_alloc_skb。前些天总结了Linux为socket多加了一个cache。修改完之后，就非常明显了，只有TCP协议使用这个功能。

今天遇到一个例子，是需要甄别的例子。里面的-bfilesize参数的单位，不一致。感觉像是问题语义解释出现了错误。所以还是需要认真的鉴别。

这里就是一个惯性的问题，在所有的程序语言里，如果两个字段中间有空格，需要加双引号才能表示他两个是一个整体。但在sysctl的配置文件里，这个习惯就不成立了。来修改ip_local_port_range。

导致随机事件出现，新起来的程序还是会kill这个文件里存的pid，但是这个pid已经不知道是属于哪一个进程了。如果这个pid没有被占用，倒是可以继续执行，但是如果pid是另一个程序的进程号，这就会导致问题。今天遇到一个随机事件，说一个程序的逻辑是开始运行会向一个文件写入执行时的pid，当下一次这个程序再重新启动的时候，可以根据个文件里的pid，kill之前的进程。问题是在研发测试的时候发现，不然真到了现场，不一定好debug这类问题。但是不巧，之前的进程已经终止，但是文件内容没有做相应的调整pid。

在问题分析的过程中发现产品里的一个统计计数出现了下面的锯齿型。而这个问题的表象之一是每隔一段时间，业务程序重启。所以产生这个锯齿形的原因之一就是业务程序重启，导致部分业务中断，出现下面这张图。另外一点，如果业务程序不重启，从图上的增长趋势，说明这个业务数据是一直不停的增加，也代表了某种资源在不停的泄露。这样看业务程序重启反倒是一种自我保护机制。接上回说，https://mzhan017.blog.csdn.net/article/details/142689870；

测试的时候，用到了很多的dummy路由，可用使用下面的小程序来添加。放到这里，仅供参考。

这样就有两套路由的信息，一个在软件内存，一个在内核系统。如果操作系统里的路由表里的记录和软件内存中记录不一致，需要做增删的操作，以确保应用于操作系统在路由数据和内存一致。如果加了校验，也就意味着，所有用到指针的函数，都需要这种校验，代码量就上来了，导致性能下降，出错概率增加，维护成本增高等等后续的问题。上面这个例子就严重依赖内核netlink的行为，如果内核发生变化，也要做相应的调整，其实这一块的代码量不小。在这个问题的处理过程中，发现软件路由audit机制的处理，存在一个小问题，引发的一个小的个人思考！

大体的问题是，现场使用的TCP socket量比较大，最终导致分配的内存超过了tcp_mem里的hard limit。此时socket，在epoll_wait的情况下，还是会有write事件可用，也就是从内核得到的信息是可以执行发送操作，但是因为内存到极限，分配不到skb内存；来来回回的要了好几次日志之后才要的perf，有点晩了。建议大家，如果在本地相同的环境使用perf没有问题的时候，还是需要使用perf来分析比较困难的现场问题，对CPU的消耗不大，最多也就是3~5%的CPU消耗。当然也得是对口的问题！

3GPP24.229选择wlan的标准是24.302.

但是上面这个命令执行的结果是在远程主机执行 echo level=2，然后ssh执行的结果放到了当前执行ssh命令的/proc/debug文件。今天做了一个晕事，在python脚本里写了一个调用远程主机的一个命令。想着是往这个虚拟主机的/proc/debug文件里写入 level=2；

logoutPassword:

另一个是关于重名的趣事，也是在昨天，在一个MS teams的会话框，写了一句，说：Jack会做某某事；这个重名的问题也是非常的严重，比如在印象里，公司里姓刘的Leo有六七个，当然还有其他Leo：Leo Wang, Leo Yang， Leo Zhang，…在和一个同事结伴写脚本代码的时候，代码里需要用kill命令向一个进程发信号，中间要使用一个标记变量来标记kill的操作是否已经完成，这位同事给这个变量起了一个名称是：kill_mark，很好的变量名，可以做到顾名思义，是杀死的标记。一个是关于重名的错觉。

最近遇到一个客户现场的问题，这个问题的发生是不定时的一个问题，就是不知道什么时候才会出现。这次遇到的例子，是说，发现现场支持人员对于这个脚本语言技能的掌握是非常的参差不齐。从个人的角度看，这个是技术支持的一个基本技能，就是大家必须都掌握的一个技能。有时候形成这种依赖后，会形成一个结果：给不愿意学习这项技能的人一个非常好的借口/由头，“自己不会，而他会”！而且：这个脚本完成之后，可以作为一个成功的工具，后面再遇到此类问题的时候，肯定也会有帮助。所以每次的技术支持是成长的一次机会，不如趁机学一下这项技能！

二十年间，平台一直在变迁，但是设计从未改变，遇到过类似的问题也有多起，但是每次都是浅聊，没有后文！因为产品的整体代码已经适应了这种不合理的设置（所以这种苦难源就会变得非常合理起来），如果要改变，需要做很多的回归测试，以及承担回归测试不完整的风险。产品里的很多线程/进程的优先级设置的很高，甚至高过了内核运行程序的优先级，高过了产品内警告处理程序的运行，高过日志打印的程序。”，经典的原因在于，有了“or”，才有了选择的机会，不管选择哪一个，都会变成我们的历史，变成我们的基因，变成我们未来的基石；

可以将tcpdump抓的包，重新拿来，再发出去（replay的一个过程），可以用来模拟特定的场景，来分析问题/性能，等。

如果直接使用notepad++，这个转义字符也算再长度里，但是再python内部\x0d算是一个字符。所以需要注意这种串长度的计算。过程是，组装byte串的时候，整个字符串里有转义字符\x0d。今天办了一件晕事，导致测试结果与预期不一致。

在 WSL 中执行 Git 操作时杀毒软件疯狂运作的现象，通常是因为 WSL 与 Windows 共享文件系统，导致杀毒软件对文件系统的变化进行扫描。通过调整杀毒软件的设置、优化 WSL 的操作方式，或者在 WSL 内部本地操作，可以减少杀毒软件的频繁运作，从而改善性能和使用体验。

如果不是单门搞研究，学过模拟/数字电路，很多人可能不会注意这一点。

事实上，技术挑战更多地集中在可预测性和稳健性上，而不是效率上。安全关键型嵌入式系统，例如客机的航空电子控制系统，被迫进入一种极端形式的“封闭箱”心态。例如，为了确保电传操纵飞机的 50 年生产周期，飞机制造商被迫一次性购买 50 年的微处理器供应量，以运行嵌入式软件。为了确保保持经过验证的实时性能，这些微处理器必须在同一条生产线上使用相同的掩模制造。如果不重新进行（极其昂贵的）软件验证和认证，系统将无法从未来 50 年的技术改进中受益。显然，与可预测性相比，效率几乎无关紧要，而可预测性。

（https://www.36kr.com/p/1807344619579905）”，值得一看！大体意思是，DARPA/ARPA-H组织了一次研究竞赛，要通过AI来自动检查，修复软件层的安全漏洞/弱点。这个和最近项目组做的AI版的代码检查有点类似，不过这个层次更深一步。反正其他的也看不了，我就想看看这个house.gov吧，试试运气，不曾想看到了一条，公共公开信息，里有关于官员的财务状况披露报告。想着也是，国家安全最重要！而且，这个https://aicyberchallenge.com/，也访问不了。

记得很多年前自己就犯过同样的错误。逻辑错误是这个样子，循环处理多条数据记录，在开始循环之前定义了一个全局变量，用来保存数据记录的业务属性值，这个全局变量的内容应该是按照数据内容来决定，用过之后要重新初始化，但是却忘记了在循环开始的时候初始化，导致下一次用的时候使用到了上一次循环的内容。最近遇到一种代码逻辑错误，应该算是一种普遍适用的错误，记录在此。

而是在用我不小心将iphone手机的充电线，的纯铁包围的那一头插进去之后发生的。然后在用这个usb接口，就不工作了。其实也不是突然失效的，

其实throw后面的参数根本不需要括号的存在，所以后面的【(string(“abc”)).c_str()】这一堆是一个整体。第一眼，看成了调用函数throw()，然后throw的返回值做了成员函数c_str()调用。将下面这一语句：throw(string(“abc”)).c_str();今天做了件晕事，之前写c++的throw语句写少了。

在 C 语言中，检查文件是否存在可以使用标准库函数，例如 fopen、access、或 stat。access 函数可以检查文件的可访问性。如果文件存在且可读，返回 0，否则返回 -1。总结：这三种方法都可以有效地检查文件是否存在。stat 函数可以获取文件的状态信息，如果文件存在返回 0，否则返回 -1。使用 fopen 打开文件，如果返回的指针不是 NULL，则表示文件存在。access: 更加高效，仅检查文件的存在性和可访问性。stat: 获取文件详细信息的同时检查文件存在性。

如果可用关注到，并按照说明/方法来先解决警告，完全可用避免问题分析的链路的拉长与问题分析时间的拉长，相对的客户印象也会好很多！如果不关注警告，总是想靠着下一级来解决，这个方式就不可避免的带来很大的负面印象！今天这个例子，说客户现场，软件使用的时候碰到一个问题，按照流程，走到研发，研发费了半天劲，发现是设备的网络设置有问题，网络不通，导致高可靠性的两个服务在不停的做切换，从而导致这个问题！另一方面，就这个错误而言，也是需要总结一个trouble/shooting的总结，和网络不通做关联！

既然没有明确标识不粘层的脆弱性，必然会导致有一部分人（没有这个意识），会误用铁锅铲和不粘锅搭配，这个对于不粘锅来说就非常的危险，因为容易将不粘层破坏掉。烙饼的不粘锅，上面有一个重要部件，是表面的一层不粘涂料，这一层比较脆弱，所以这一层的硬度肯定不如铁或者其他金属和瓷器。还要看这一部分人是否会亲自刷锅，以及要注意到破坏掉的涂层，然后才可能会联想/思考/逻辑反推其中的逻辑。也就是说这种默认的意识是如此的普及，以至于，在买锅的时候，商品不会再明显的未知，或者有可能都没有什么特殊说明，不能用硬物。

上面两个选项的文档，需要到gcc的使用手册里找。专门找llvm/clang的文档，可能找不到相应的解释说明。

这个问题的原因是说这个二进制文件的编译/链接版本和当前使用的addr2line所属的binutils版本有差别，导致内容解析出现问题。所以在使用addr2line的时候一定要注意，不是说只要系统里addrline这个命令，就可以了，还需要看当前addr2line的版本是否对应二进制文件的编译链接使用的binutils版本，如果兼容就可以正确的解析调试信息，如果不兼容就会出现标题中的问题。之前总结过addr2line的一个问题：gnu:binutils: addr2line显示行号有问题？

只要是使用的第三方软件是Redhat提供的rpm包，就就可以在这里提问题。

看着这个代码的目的是只注册一次sighandler，但是这个判定是否可以保证一次？但是根据代码看，其实不会有关键区的读写，所以即使有同步问题，也不会产生什么特别的影响。所以代码没有问题，但是这是一个坑。

这就是做的比较晕的事情。有问题就应该在有问题的环境做debug，而且是非常仔细的检查。而不是想着倒回去，作比较，这样会破坏有问题的环境。今天办了一件晕事，同事在做升级测试的时候遇到一个网络不通的问题，经粗略查看，应该是网络问题，路由器没有回复ARP的reply。一交流，好像是没有别的好办法，就做了降级，看看之前的状态。升降级的操作比较费事。结果尴尬了，降回去就没问题了。

但是intel的技术支持，却让找Cisco的组装厂商？这个是什么业务逻辑？Cisco和intel还有支持协议关系？比如下面这个链接里说看到Linux服务器的内核日志，看到i40e打了一个错误日志。

这两天发现，使用的Thinkpad T14笔记本，键盘上有四个键失灵“R/T/4/6”，怎么点都不出来。才刚刚过三年质保期。不得不说运气太寸了，质保刚过，键盘就失灵了！没办法，公司IT说可以找厂家外修，但是需要费用。或者内修，在库房找一个旧的笔记本，换一下键盘。那就内修吧，节省一些成本。修电脑的是一个大姐，拿起螺丝刀开始撬笔记本的键盘，在哪里撬呀撬，蹦的键盘满是头皮屑，和碎头发/胡渣！

这样一解释，问题就十分的明显，就是进入本地的包，没有通过IPsec的完整性校验，那么问题的下一步就是要看为什么校验失败，是对方发的数据有问题？因为在工作中，英语是非常重要的一门基础技术，所有的产品代码/第三方开源软件都是英语书写，包括代码逻辑，变量/函数/类定义，注释描述，日志打印，文档的书写；即使这些渠道都没有，（以现代的网络发展，我觉着不可能，词典肯定是有，网络搜索引擎肯定是有，大模型肯定是有），所以猜也要猜个出来，就看上不上心了！作为一名程序员，英语的必备性是不可或缺，尤其是在一个外企！

但是调用temp.h文件中的函数A（）是这样写的，功能是判断是不是宏定义了CC，如果宏定义了就返回true否则返回false。后来通过深入交流，发现这个文件名称是开源库里的，所以根本就不需要例如，直接写开源库文件名就好了，不需要temp的举例。最近在工作中也是遇到一例，如果是开问题单，分析的人当然是希望可以看到稍微具体点的测试基本步骤，如果这个没有，而只是给出大体的步骤和现象，那就需要自己从日志里巴拉巴拉，或者和测试人员再深入交流一下。原因之二是，答题人的知识盲区，也是理解问题的一个关键。