pcj_888的博客

如题

Iptables multiport rule supports at most 15 ports

如题

Microk8s ingress启动失败定位案例

如题

查看网卡连接，找不到name为eth0的连接，只显示’Wired connection 1’从Centos7升级到Rocky9后, 发现网卡eth0的IP不正确。centos7使用的网卡配置文件是ifcfg-files(升级到Rocky 9后，需要把eth0网卡重新配置一下。)，而RHEL9使用的是keyfiles(，发现找不到网卡配置文件。

查看虚拟机启动日志，发现eth1居然先于eth0 UP，所以系统自动分配给eth1的metric更小(优先级更高)。登录Vmware串口，先确认sshd进程是否启动，通过ps查看sshd进程运行进程正常, netstat查看22号端口LISTEN，这一步没问题。虚拟机重启后，SSH连接失败，提示"Connection time out"，重启之前SSH连接还是正常的。抓包，确认是否收到SSH请求报文，排除防火墙设置的原因。从抓包结果看，只有收的包，没有发出去的包。

k8s中的pod域名解析失败定位

microk8s启动失败，microk8s.daemon-containerd服务启动失败，报“Failed to start Service for snap application microk8s.daemon-containerd”Vmware VM设置里勾选网卡状态为connect，再设置主网卡IP, Gateway, DNS，重启microk8s问题解决。

在Vmware虚拟机上，执行如下Shell代码获取VM类型。直接定义全局变量保存字符串，回避echo语句的副作用。，这个返回的结果是错误的。

命令查路由表，发现eth0的默认路由Metric值为100，小于eth1的Metric(101)，这说明eth0默认路由优先级更高，curl https://www.baidu.com。以下命令设置eth0的默认路由metric值为200，大于eth1的默认路由metric(101)RHEL9 双网卡环境，两个网卡配置如下：(访问百度失败，发现网络不通。修改重启后仍有效 (配置写在。修改重启后仍有效 (配置写在。有两种方法，任选其一即可。

删除此文件后重启microk8s，发现问题解决。文件出错原因可能是因为机器被异常下电，导致文件损坏。根据错误日志中"segment。"的信息，找到出错的文件。和正常环境对比，发现。

网络不通的时候，可以正常工作的nameserver 10.204.16.18恰好在第4条，所以DNS解析失败。手动配置eth1的DNS后，网络不通，通过抓包发现是eth1的DNS server配置有误，解决方法：删掉第二、三行这两个系统自动生成的v6 dns server，保证。，RHEL9上删除nameserver可以使用。里的nameserver记录不超过3条即可。在网络不通的时候，查看。

Rocky Linux 9.2环境，手工配置了为30秒，但重启后发现没有显示菜单，未出现30秒倒计时。

RHEL9 Fatal glibc error: CPU does not support x86-64-v2

【代码】[GDB] 在Docker中使用GDB调试的方法。

背景介绍GDB不仅可以用来调试程序，还可以直接修改被调试程序的二进制文件。这种方式相比于改源码重新编译、gdb attach有什么优势呢？考虑以下企业生产环境中的几个调试场景：需要修改的二进制文件是其他领域的，你没有源码和编译工程，让相关领域出调试对接件比较费时，但你只想临时改一行别人的代码，几分钟内完成验证。调试环境上，使用gdb attach进程方式有困难：被调试的服务（进程）没有启动断点(可定位性很差)，或者gdb手动拉起的方法非常复杂，等服务正常启动后再attach已经赶不上打断点的时机

一、问题描述进程收到SIGABRT信号异常退出，异常调用栈显示__stack_chk_fail二、原因分析和定位思路原因分析： __stack_chk_fail说明发生了缓冲区溢出，canary被破坏。这说明代码设置GCC编译选项fstack-protector，开启了栈保护机制canary定位思路：先通过反汇编找到canary在栈上的存放地址。用GDB对canary的存放地址打数据断点，定位出导致栈破坏的指令，再结合C代码具体分析。三、定位过程以下给出一个简化案例：一个可执行程序tes

问题描述root进程调sem_open(XXX, O_CREAT, 0666, 1)创建信号量后，非root进程使用sem_open打开同一个信号量失败，报Permission Denied错原因分析非root进程调用sem_open， 以O_CREAT方式打开信号量，需要同时有对该信号量文件的读权限 + 写权限。ll /dev/shm/sem.semname 查看信号量文件权限，发现权限为0644，缺少其他用户写权限。这个权限与sem_open中指定的权限值0666不一致。为什么sem_open

问题现象gdb调试core文件或进程时，出现加载so库符号失败，错误信息如下warning: Could not load shared library symbols for ../libadd.soDo you need "set solib-search-path" or "set sysroot"?执行info sharedlibrary，查看Syms Read字段为No, 表示对应so库符号加载失败。$ pwd /home/gdb(gdb) info sharedlibraryF

什么是隐式函数声明C语言中，函数调用前不一定要声明。如果没有声明，编译器会自动按照一种隐式声明规则，为调用函数的C代码产生汇编代码。忽略隐式函数声明警告的危害隐式声明函数恰好在库中存在，这种情况可参考 https://www.jb51.net/article/78212.htm编译so库时会出现未定义符号，导致加载该so的程序执行出错。举例如下:// add.cint add(in...

错误现象在编写使用select函数的TCP和UDP回射程序，出现UDP的sendto错误，现象如下：服务端正常启动后，调用select函数监听TCP和UDP套接字, 可以正常处理TCP请求。UDP客户端可以连接到服务端，但接收标准输入后无回显，阻塞于recvfrom。解决过程经排查，发现服务端处理UDP请求的代码有问题，如下:typedef struct sockaddr ...

#问题描述：运行C程序发生段错误后，没有core文件生成，调试不便#生成core文件步骤：输入ulimit -a，查看系统core文件大小限制，如第一行core file size值为0，表示没打开core dump设置...