分类目录归档:技术

Libpcap 落地包转发及性能调优

近期接到一个需求,需要使用 libpcap 从某网卡抓包发送到另一张网卡,关于 libpcap 的使用方法在这里不再赘述,网上有很多教程,本文最后会给出一个示例程序。这里记录一个转发效率性能调优的方法。

在写好程序后,发现 Ping 的延时很高,优化了一个参数后得到了极大的改善了。

https://imagehost-cdn.frytea.com/images/2021/03/17/_16159857327845a539b65d50119ba.png

发现是自己在使用这个函数打开网络设备时的超时时间设定不合理导致的:

函数名称: pcap_t *pcap_open_live(char *device, int snaplen, int promisc, int to_ms, char *ebuf)
函数功能:获得用于捕获网络数据包的数据包捕获描述字。
参数说明:device参数为指定打开的网络设备名。snaplen参数定义捕获数据的最大字节数。promisc指定是否将网络接口置于混杂模式。toms参数指*定超时时间(毫秒)。ebuf参数则仅在pcapopen_live()函数出错返回NULL时用于传递错误消息。

我将其中的第四个参数,由之前的 1000 改为 1 ,性能得到极大改善。下面给出示例程序:

/*************************************************************************
        > File Name : pcap_example.c
        > Author : TL Song
        > EMail : songtianlun@frytea.com
        > Created Time : Thu Feb 18 18:57:20 2021
     ************************************************************************/
    #include <stdio.h>
    #include <string.h>
    #include <pthread.h>
    #include <pcap.h>

    #define RECV_DEVICE      "ens3"
    #define RECV_DEVICE_SEND "docker0"
    #define RECV_FILTER      "arp or icmp"

    #define dPrint(fmt, ...) do{fprintf(stderr, "[%s:%d] " fmt "\r\n", __FUNCTION__, __LINE__, ##__VA_ARGS__);}while(0)

    int main()
    {
        char err_buf[PCAP_ERRBUF_SIZE];
        struct bpf_program fp_recv;      /* The compiled filter expression */
        char filter_recv[] = RECV_FILTER;  /* The filter expression (filter 53 port)*/
        pcap_t *handle_recv;
        pcap_t *handle_recv_send;
        bpf_u_int32 mask_recv;       /* The netmask of our sniffing device */
        bpf_u_int32 net_recv;        /* The IP of our sniffing device */
        u_char *pkt_data = NULL;
        int rst;
        struct pcap_pkthdr header;
        struct pcap_pkthdr *p_header = &header;

        printf("Recv Device: %s\n", RECV_DEVICE);

        /*Step1, Open the session in promiscuous mode*/
        handle_recv = pcap_open_live(RECV_DEVICE, BUFSIZ, 1, 1, err_buf);
        if (handle_recv == NULL) {
            fprintf(stderr, "Couldn't open device %s: %s\n", RECV_DEVICE, err_buf);
            return 0;
        }

        handle_recv_send = pcap_open_live(RECV_DEVICE_SEND, BUFSIZ, 1, 1, err_buf);
        if (handle_recv_send == NULL) {
            printf("Couldn't open device %s: %s\n", RECV_DEVICE_SEND, err_buf);
            return 0;
        }

        /*Step2, get network mask*/
        if (pcap_lookupnet(RECV_DEVICE, &net_recv, &mask_recv, err_buf) == -1) {
            fprintf(stderr, "Can't get netmask for device %s\n", RECV_DEVICE);
            net_recv = 0;
            mask_recv = 0;
        }

        /* Step3, Compile and apply the filter */
        if (pcap_compile(handle_recv, &fp_recv, filter_recv, 0, net_recv) == -1) {
            fprintf(stderr, "Couldn't parse filter %s: %s\n", filter_recv, pcap_geterr(handle_recv));
            return 0;
        }
        if (pcap_setfilter(handle_recv, &fp_recv) == -1) {
            fprintf(stderr, "Couldn't install filter %s: %s\n", filter_recv, pcap_geterr(handle_recv));
            return 0;
        }

        /* Step4, get frame. */
        while(1){
            pkt_data = (unsigned char * )pcap_next(handle_recv, p_header);
            rst = pcap_sendpacket(handle_recv_send, pkt_data, p_header->caplen);
            printf("Send to %s ret : %d\n", RECV_DEVICE_SEND, rst);
        }

        /* Step5, cleanup */
        pcap_freecode(&fp_recv);
        pcap_close(handle_recv);
        pcap_close(handle_recv_send);
        dPrint("Capture complete.");
        return 0;
    }

参考文献

一键在 vs code online 中打开任意 github 仓库

之前有大佬开发过一个项目 [github1s](https://github.com/conwnet/github1s) ,利用 GitHub action ,仅需在任意 github 仓库在 github 后面加上 1s 即可在一个在线的 VS code 中打开这个项目。

https://imagehost-cdn.frytea.com/images/2021/09/03/2021-09-03-5.51.4487ec1eade813be27.png

就在前不久,Github 官方发布了类似的功能,进一步简化了这个过程,仅需在仓库的 web 页面,按下 . 键,没错就是键盘上那个句号,github 就会打开一个在线的 VS code 并开启该仓库,您就可以更方便的浏览这个仓库了。

https://imagehost-cdn.frytea.com/images/2021/09/03/2021-09-03-5.54.000522906cfa16b653.png

两个方式原理类似,都是跳转到另一个网址,之后使用该路径中的地址获取到仓库代码并显示,不得不说,这个功能真的是用起来太爽了,各位好好使用。

参考文献

虚拟机 img 镜像密码修改

本文介绍使用 libguestfs-tools 修改镜像文件密码的方法。

步骤

# 环境
# CentOS Linux release 7.9.2009 (AltArch)
# 鲲鹏 ARM 服务器

第一步:检查并修改qemu访问虚拟机镜像的权限

修改 qemu 配置文件 /etc/libvirt/qemu.conf,将 user = "root"group = "root" 注释取消,并重启 libvirtd 或重启宿主机。

$ vim /etc/libvirt/qemu.conf
- #user = "root"
- #group = "root"
+ user = "root"
+ group = "root"

systemctl restart libvirtd

第二步:安装工具

# 安装libguestfs-tools
$ yum install libguestfs-tools 
$ systemctl start libvirtd

第三步:修改密码

# 以下两组命令貌似均可,但是实测我的环境仅第二个命令可用

$ virt-customize -a CentOS-7-x86_64-GenericCloud.qcow2 --root-password password:xxx
$ virt-sysprep --root-password password:123456 -a *.qcow2

# 若以下错误
# cannot access storage file (as uid:107, gid:107)permission denied
# 说明您第一步没有做,给一下权限再尝试

# 示例
[root@compute-arm-01 stl]$ virt-sysprep --root-password password:123456 -a bionic-server-cloudimg-arm64.img 
[   0.0] Examining the guest ...
[   5.4] Performing "abrt-data" ...
[   5.4] Performing "backup-files" ...
[   5.8] Performing "bash-history" ...
[   5.9] Performing "blkid-tab" ...
[   5.9] Performing "crash-data" ...
[   6.0] Performing "cron-spool" ...
[   6.0] Performing "dhcp-client-state" ...
[   6.0] Performing "dhcp-server-state" ...
[   6.0] Performing "dovecot-data" ...
[   6.0] Performing "logfiles" ...
[   6.1] Performing "machine-id" ...
[   6.2] Performing "mail-spool" ...
[   6.2] Performing "net-hostname" ...
[   6.2] Performing "net-hwaddr" ...
[   6.3] Performing "pacct-log" ...
[   6.4] Performing "package-manager-cache" ...
[   6.5] Performing "pam-data" ...
[   6.5] Performing "passwd-backups" ...
[   6.5] Performing "puppet-data-log" ...
[   6.6] Performing "rh-subscription-manager" ...
[   6.6] Performing "rhn-systemid" ...
[   6.7] Performing "rpm-db" ...
[   6.8] Performing "samba-db-log" ...
[   6.8] Performing "script" ...
[   6.8] Performing "smolt-uuid" ...
[   6.9] Performing "ssh-hostkeys" ...
[   6.9] Performing "ssh-userdir" ...
[   6.9] Performing "sssd-db-log" ...
[   7.0] Performing "tmp-files" ...
[   7.0] Performing "udev-persistent-net" ...
[   7.1] Performing "utmp" ...
[   7.1] Performing "yum-uuid" ...
[   7.1] Performing "customize" ...
[   7.2] Setting a random seed
virt-sysprep: warning: random seed could not be set for this type of guest
[   7.3] Setting the machine ID in /etc/machine-id
[   7.3] Setting passwords
[   8.7] Performing "lvm-uuids" ...

参考文献

GDB 调试 QEMU 源码跟踪 QMP 协议执行

接上文,通过跟踪 libvirt 的源码,找到 virsh domblkinfo 最终是使用 QMP 协议从 QEMU 获取到关键字为 query-block 的数据,其中带有 wr_highest_offset 字段,该字段被 libvirt 认定为 磁盘利用率中 Allocation 值的来源。

今天就尝试在 QEMU 中找到获取 wr_highest_offset 字段的方法。

环境准备

  • QEMU 4.0
  • Centos
  • 鲲鹏 ARM

首先需要编译 QEMU 加入函数表,重新编译 QEMU在其中加入该字段即可,编译方法可以参考源码目录:

./configure --enable-debug

跟踪前需要定位到 QEMU 中填充该字段的函数,首先在源码中全局搜索 wr_highest_offset ,最终确定 block/qapi.c 文件中的 bdrv_query_bds_stats 函数最有可能是填充该字段的位置,下面就来跟踪这个函数的走向吧。

跟踪记录

一个虚拟机在宿主机中表现为一个 QEMU 的进程,在这里仅保留一个虚拟机,查询该虚拟机状态时 libvirt 回使用 unix socket 的方式发往该进程监听的 unix socket 服务。因此跟踪该虚拟机所在进程即可。

# ps -aux | grep qemu
qemu     2185346  0.6  0.5 3562240 333440 ?      Sl   10:05   2:20 /usr/bin/qemu-system-aarch64 -name guest=instance-000001bb,...imestamp=on
root     2472547  0.0  0.0 110784  2496 pts/3    S+   16:03   0:00 grep --color=auto qemu

GDB 开始跟踪:

gdb qemu-system-aarch64 2185346

在之前找到的目标函数处打上断点:

(gdb) b bdrv_query_bds_stats

之后 c 继续执行,尝试查询一下磁盘状态。

$ virsh domblkinfo 25 vda --human

Breakpoint 1, bdrv_query_bds_stats (bs=0x3b549940, blk_level=true) at /root/stl/qemu-4.0.0/block/qapi.c:509
509         BlockStats *s = NULL;

会发现终端卡住了,此时 gdb 中断了进程,说明我们找对函数了,下面我们继续追踪吧。

发现这个函数是在 qmp_query_blockstats 中被调用多次,最终得出结果。

544     }
(gdb) n
qmp_query_blockstats (has_query_nodes=false, query_nodes=false, errp=0xffffe3963110) at /root/stl/qemu-4.0.0/block/qapi.c:609
609                 s->has_device = true;
(gdb) p s->stats->wr_highest_offset 
$3 = 3072

下面主要就是跟着源码来看了,本文主要是讲了如何使用 GDB 跟踪 QEMU 源码,若有疑问欢迎留言。

参考文献

GDB 调试 libvirt 源码之 domblkinfo 命令源码跟踪记

最近发现环境中 KVM 虚拟机磁盘利用率查不准,使用 virsh 命令查看磁盘使用情况得到如下结果:

# virsh domblkinfo 20 vda --human
Capacity:       2.000 GiB
Allocation:     2.000 GiB
Physical:       2.000 GiB

显然是有问题的,正常的数值三个应该不通,进入系统查看磁盘使用率也仅有 2% 左右,因此试图通过检查源码的方式查看是否正确。

  • libvirt: 5.6.0
  • os: Centos

跟踪记录

首先找到 libvirtd 的 PID:

ps -aux | grep libvirtd
root      1907  0.0  0.0 1385796 25116 ?       Ssl  Aug26   5:22 /usr/sbin/libvirtd --timeout 120

使用 GDB 开始跟踪他:

gdb libvirtd 1907

首先在源码中全局搜索 domblkinfo 关键字,找到该命令的执行函数: tools/virsh-domain-monitor.c→cmdDomblkinfo

分析源码找到获取信息的函数 src/libvirt-domain.c -> virDomainGetBlockInfo

if (virDomainGetBlockInfo(dom, device, &info, 0) < 0)
    goto cleanup;

if (!cmdDomblkinfoGet(ctl, &info, &cap, &alloc, &phy, human))
    goto cleanup;
vshPrint(ctl, "%-15s %s\n", _("Capacity:"), cap);
vshPrint(ctl, "%-15s %s\n", _("Allocation:"), alloc);
vshPrint(ctl, "%-15s %s\n", _("Physical:"), phy);

这其中的 info 包含了所需信息,看一下填充该字段的 virDomainGetBlockInfo 函数实现,用 GDB 跟一下它吧.

跟踪 src/libvirt-domain.c -> virDomainGetBlockInfo

先打个断点:

(gdb) break virDomainGetBlockInfo
Breakpoint 1 at 0x7f4d4394a760: file libvirt-domain.c, line 6094.

再打开一个终端,执行一下命令:

[root@compute-01 ~]# virsh list
 Id   Name                State
-----------------------------------
 2    instance-000001b6   running
 3    instance-000001b8   running
 4    instance-000001b9   running

[root@compute-01 ~]# virsh domblkinfo 4 vda

此时会发现终端卡住了,看一下 GDB 已经将程序中断,单步调试看一下:

[Switching to Thread 0x7f4d32ef0700 (LWP 1918)]

Breakpoint 1, virDomainGetBlockInfo (domain=domain@entry=0x7f4cfc00aeb0, disk=0x7f4cfc00cc60 "vda", 
    info=info@entry=0x7f4d32eefac0, flags=0) at libvirt-domain.c:6094
6094    {
(gdb) n
6097        VIR_DOMAIN_DEBUG(domain, "info=%p, flags=0x%x", info, flags);
(gdb) n
6094    {
(gdb) n
6097        VIR_DOMAIN_DEBUG(domain, "info=%p, flags=0x%x", info, flags);
(gdb) n
6099        virResetLastError();
(gdb) n
6101        if (info)
(gdb) n
6102            memset(info, 0, sizeof(*info));
(gdb) n
6104        virCheckDomainReturn(domain, -1);
(gdb) n
6105        virCheckNonEmptyStringArgGoto(disk, error);
(gdb) n
6106        virCheckNonNullArgGoto(info, error);
(gdb) n
6110        if (conn->driver->domainGetBlockInfo) {
(gdb) n
6112            ret = conn->driver->domainGetBlockInfo(domain, disk, info, flags);
(gdb) s
qemuDomainGetBlockInfo (dom=0x7f4cfc00aeb0, path=0x7f4cfc00cc60 "vda", info=0x7f4d32eefac0, flags=0)
    at qemu/qemu_driver.c:12413
12413   {

发现在 6112 行跳到了另一个函数,继续跟踪它.

跟踪 src/qemu/qemu_driver.c -> qemuDomainGetBlockInfo

(gdb) n
12421       virCheckFlags(0, -1);
(gdb) n
12413   {
(gdb) n
12414       virQEMUDriverPtr driver = dom->conn->privateData;
(gdb) n
12421       virCheckFlags(0, -1);
(gdb) n
12419       qemuBlockStatsPtr entry = NULL;
(gdb) n
12414       virQEMUDriverPtr driver = dom->conn->privateData;
(gdb) n
12421       virCheckFlags(0, -1);
(gdb) n
12423       if (!(vm = qemuDomObjFromDomain(dom)))
(gdb) n
12426       cfg = virQEMUDriverGetConfig(driver);
(gdb) n
12428       if (virDomainGetBlockInfoEnsureACL(dom->conn, vm->def) < 0)
(gdb) n
12431       if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_QUERY) < 0)
(gdb) n
12434       if (!(disk = virDomainDiskByName(vm->def, path, false))) {
(gdb) n
12440       if (virStorageSourceIsEmpty(disk->src)) {
(gdb) n
12448       if (!virDomainObjIsActive(vm)) {
(gdb) n
12460       if (qemuDomainBlocksStatsGather(driver, vm, path, true, &entry) < 0)
(gdb) n
12463       if (!entry->wr_highest_offset_valid) {
(gdb) n
12466           if (virStorageSourceGetActualType(disk->src) == VIR_STORAGE_TYPE_FILE &&
(gdb) n
12468               info->allocation = entry->physical;
(gdb) n
12466           if (virStorageSourceGetActualType(disk->src) == VIR_STORAGE_TYPE_FILE &&
(gdb) p info->allocation
$2 = 0
(gdb) n
12470               info->allocation = entry->wr_highest_offset;
(gdb) n
12484       if (entry->physical == 0 || info->allocation == 0 ||
(gdb) p info->allocation
$3 = 32870912
(gdb) p entry->wr_highest_offset
$4 = 32870912

至此,我们知道了 info -> allocation 的值来自 entry->wr_highest_offset ,接下来查看源码, entry->wr_highest_offset 的值应该是在这里被赋予的:

if (qemuDomainBlocksStatsGather(driver, vm, path, true, &entry) < 0)
  goto endjob;

下面将断点打在 qemuDomainBlocksStatsGather 看一下其中的 entry->wr_highest_offset 是在哪里被赋值.

跟踪 src/qemu/qemu_driver.c -> qemuDomainBlocksStatsGather

将之前的断点删除,打上新的断点

(gdb) info breakpoints 
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00007f4d4394a760 in virDomainGetBlockInfo at libvirt-domain.c:6094
        breakpoint already hit 1 time
(gdb) delete 1
(gdb) break qemuDomainBlocksStatsGather
Breakpoint 2 at 0x7f4d208e3700: file qemu/qemu_driver.c, line 11427.

之后在 GDB continue ,之后一直按回车,直到程序正常运行了,再执行一下获取磁盘信息的命令,继续跟踪。

Breakpoint 1, qemuDomainBlocksStatsGather (driver=driver@entry=0x7f4d180f99b0, vm=0x7f4d100b8890, 
    path=path@entry=0x7f4d0c00ae50 "vda", capacity=capacity@entry=true, retstats=retstats@entry=0x7f4d336f0980)
    at qemu/qemu_driver.c:11427
11427   {
(gdb) n
11428       qemuDomainObjPrivatePtr priv = vm->privateData;
(gdb) 
11429       bool blockdev = virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV);
(gdb) 
11439       if (*path) {
(gdb) 
11440           if (!(disk = virDomainDiskByName(vm->def, path, false))) {
(gdb) 
11445           if (blockdev) {
(gdb) 
11448               if (!disk->info.alias) {
(gdb) 
11458       qemuDomainObjEnterMonitor(driver, vm);
(gdb) 
11459       nstats = qemuMonitorGetAllBlockStatsInfo(priv->mon, &blockstats, false);
(gdb) 
11461       if (capacity && nstats >= 0) {
(gdb) 
11465               rc = qemuMonitorBlockStatsUpdateCapacity(priv->mon, blockstats, false);
(gdb) 
11468       if (qemuDomainObjExitMonitor(driver, vm) < 0 || nstats < 0 || rc < 0)
(gdb) 
11471       if (VIR_ALLOC(*retstats) < 0)
(gdb) 
11474       if (entryname) {
(gdb) 
11475           if (!(stats = virHashLookup(blockstats, entryname))) {
(gdb) 
11481           **retstats = *stats;
(gdb) p stats
$12 = (qemuBlockStats *) 0x7f4d0c001000
(gdb) p *stats
$13 = {rd_req = 712, rd_bytes = 17435136, wr_req = 130, wr_bytes = 418816, rd_total_times = 527027278, 
  wr_total_times = 86798718, flush_req = 20, flush_total_times = 94396427, capacity = 2147483648, 
  physical = 2147483648, wr_highest_offset = 32870912, wr_highest_offset_valid = true, write_threshold = 0}
(gdb) c
Continuing.

分析这一调用过程,发现我们跟踪的 restats 变量来自 stats,而该值在这一行被填充:

11475           if (!(stats = virHashLookup(blockstats, entryname))) {

值来自哈希表查询结果,从 blockstats 中查询 entryname ,而该哈希表在这两行被赋值:

11459       nstats = qemuMonitorGetAllBlockStatsInfo(priv->mon, &blockstats, false);
11465       rc = qemuMonitorBlockStatsUpdateCapacity(priv->mon, blockstats, false);

之后就可以跟踪源码了,经过一番探索,发现他们最终都调用了同一个函数来从 QEMU 获取设备信息,即 src/qemu/qemu_monitor_json.c -> qemuMonitorJSONQueryBlock ,看一下它的函数实现:

static virJSONValuePtr
qemuMonitorJSONQueryBlock(qemuMonitorPtr mon)
{
    virJSONValuePtr cmd;
    virJSONValuePtr reply = NULL;
    virJSONValuePtr devices = NULL;

    if (!(cmd = qemuMonitorJSONMakeCommand("query-block", NULL)))
        return NULL;

    if (qemuMonitorJSONCommand(mon, cmd, &reply) < 0 ||
        qemuMonitorJSONCheckReply(cmd, reply, VIR_JSON_TYPE_ARRAY) < 0)
        goto cleanup;

    devices = virJSONValueObjectStealArray(reply, "return");

 cleanup:
    virJSONValueFree(cmd);
    virJSONValueFree(reply);
    return devices;
}

继续探索会发现 libvirt 在这里调用了 QEMU 提供的 QMP 协议,其中的查询关键词为 query-block ,返回的结果中含有 wr_highest_offset 字段。

最终得到一张 libvirt 查询磁盘使用情况的调用栈示意图:

https://imagehost-cdn.frytea.com/images/2021/09/02/domblkinfoac4ecdcf5caa1926.png

如果继续探索,可能就需要去跟踪 QEMU 源码了,下篇文章见。

参考文献

附件

libvirt-domblkinfo-命令源码调用栈 .xmind

解决 Clash for windows 端口为 0 导致无法使用

今天更新完 Windows 重启后发现上不了网了,检查 clash for windows 发现监听端口为 0

https://imagehost-cdn.frytea.com/images/2021/08/30/20210830095030627b1fa801f19241.png

这就不正常了,检查了一下 `C:\Users\

\.config\clash\logs` 的日志,发现这行报错: “`perl level=error msg=”Start Mixed(http and socks) server error: listen tcp 127.0.0.1:7890: bind: An attempt was made to access a socket in a way forbidden by its access permissions.” “` 貌似是端口无法被正常绑定,网上找了一下原因,发现遇到该问题的人不少,大致这样解决: `CMD` 执行这行指令 `netsh int ipv4 show dynamicport tcp` 发现起始端口变成了1024。 管理员身份运行 CMD 执行这些命令: “`bash # 这两条命令来自博客 https://blog.csdn.net/tian2342/article/details/108934646 netsh int ipv4 set dynamicport tcp start=49152 num=16383 确定。 netsh int ipv4 set dynamicport udp start=49152 num=16383 确定。 # 这条命令来自 https://github.com/Fndroid/clash_for_windows_pkg/issues/671 netsh int ipv4 set dynamic tcp start=49152 num=16384 “` 然后检查结果 “`bash netsh int ipv4 show dynamicport tcp “` 端口正常后**重启计算机,恢复正常**。 ## 参考文献 – [WIN10更新后端口显示为0的解决方法 #671](https://github.com/Fndroid/clash_for_windows_pkg/issues/671) – [关于Windows端口没被占用提示An attempt was made to access a socket in a way forbidden by its access permissions](https://blog.csdn.net/tian2342/article/details/108934646) – [Clash端口显示为0的解决方法](https://www.cnblogs.com/anyview/p/15056008.html)

Perl 程序后台执行示例

最近阅读 PVE 源码发现一处源码这样使用了 fork() 方法:

$spid = fork();
    if (!defined ($spid)) {
        die "can't put server into background - fork failed";
    } elsif ($spid) { # parent
        exit (0);
    }

自己写示例发现这种方法可以使程序进入后台执行状态,大概原理是 fork 子进程,退出主进程,使得程序被 1 号父进程接管,在终端表现则是进入了后台执行状态

以下是实例代码:

#!/usr/bin/perl

sub mainThread() {
    print "---------- Main Thread! ------------\n";
    $spid = fork();
    if (!defined ($spid)) {
        die "can't put server into background - fork failed";
    } elsif ($spid) { # parent
        exit (0);
    }
    for(;;)
    {
        print "Hello, world in main thread!\n";
        sleep 1;
    }
}

mainThread();

看下进程状态:

https://imagehost-cdn.frytea.com/images/2021/08/26/_1629948977368e83558ffb3dfcdb2.png

退出程序则是指定 PID 即可:

$ kill -9 3300

参考文献

Perl 面向对象之基类(use base)

use base somemodule;

# 相当于以下两句的结合:

BEGIN{
    use somemodule ();
    push @ISA, qw(somemodule);
}

# 也可以同时 use base 两个或者两个以上的模块,即多继承,例如:

use base qw(Foo Bar);

BEGIN {
    use Foo ();
    use Bar ();
    push @ISA, qw(Foo Bar);
}
  • Perl 里 类方法通过 @ISA 数组继承,这个数组里面包含其他包(类)的名字,变量的继承必须明确设定。
  • 多继承就是这个 @ISA 数组包含多个类(包)名字。
  • 通过 @ISA 只能继承方法不能继承数据

参考文献

Perl 模块路径指定(调试环境)

在调试 Perl 测试程序时,常常需要在测试路劲执行 Perl 脚本,相应的 .pm 模块测试程序也需并不在 Perl 默认的模块路径下,使用以下语句即可指定模块检索路径。

#!/usr/bin/perl
use lib './';
use Person;
# Person 包模块与当前脚本同级,可用上面两行代码指定包位置
...

参考文献

QEMU 编译报错 undefined reference to g_app_info_launch_default_for_uri_finish 解决过程

编译 QEMU 时报如下错误:

/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_app_info_launch_default_for_uri_finish'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_type_check_instance_is_fundamentally_a'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_app_info_launch_default_for_uri_async'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_strv_contains'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_list_model_get_type'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_drive_is_removable'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_application_get_resource_base_path'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_log_structured_standard'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_type_get_instance_count'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_list_model_get_n_items'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_file_enumerator_iterate'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_param_spec_get_name_quark'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libgtk-3.so: undefined reference to `g_list_model_get_item'
collect2: error: ld returned 1 exit status
make[1]: *** [qemu-system-x86_64] Error 1
make: *** [subdir-x86_64-softmmu] Error 2

先看一下报错的动态链接库依赖了哪些库:

$ ldd /lib64/libgtk-3.so       
        linux-vdso.so.1 =>  (0x00007ffc89762000)
        libgdk-3.so.0 => /lib64/libgdk-3.so.0 (0x00007f19938ab000)
        libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f19936a7000)
        libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x00007f1993499000)
        libX11.so.6 => /lib64/libX11.so.6 (0x00007f199315b000)
        libXi.so.6 => /lib64/libXi.so.6 (0x00007f1992f4b000)
        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f1992d45000)
        libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 (0x00007f1992b3c000)
        libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f1992805000)
        libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x00007f19925dd000)
        libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f19923b7000)
        libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x00007f1992188000)
        libwayland-client.so.0 => /lib64/libwayland-client.so.0 (0x00007f1991f79000)
        libepoxy.so.0 => /lib64/libepoxy.so.0 (0x00007f1991c4d000)
        libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x00007f1991a37000)
        libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f19917f1000)
        libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f19915af000)
        libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f199120f000)
        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f1990fbe000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f1990ca8000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f19909a6000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f199078a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f19903bc000)
        libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f19901b9000)
        libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f198ffae000)
        libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f198fda3000)
        libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f198fba0000)
        libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f198f99d000)
        libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f198f75d000)
        libwayland-cursor.so.0 => /lib64/libwayland-cursor.so.0 (0x00007f198f555000)
        libwayland-egl.so.1 => /lib64/libwayland-egl.so.1 (0x00007f198f353000)
        libXext.so.6 => /lib64/libXext.so.6 (0x00007f198f141000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f198ef39000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f198ed35000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f198ead3000)
        libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f198e814000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f198e5ec000)
        libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f198e343000)
        libEGL.so.1 => /lib64/libEGL.so.1 (0x00007f198e12f000)
        libpng15.so.15 => /lib64/libpng15.so.15 (0x00007f198df04000)
        libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f198dd00000)
        libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f198daf2000)
        libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f198d8e7000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f198d6d1000)
        libGL.so.1 => /lib64/libGL.so.1 (0x00007f198d445000)
        libatspi.so.0 => /lib64/libatspi.so.0 (0x00007f198d214000)
        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f198cfc4000)
        libffi.so.6 => /lib64/libffi.so.6 (0x00007f198cdbc000)
        libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f198cb1f000)
        libthai.so.0 => /lib64/libthai.so.0 (0x00007f198c913000)
        libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f198c6f7000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f198c4cd000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f198c2c8000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f198c0a1000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f198be87000)
        libmount.so.1 => /lib64/libmount.so.1 (0x00007f198bc44000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f198ba2e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f199449d000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f198b81e000)
        libXau.so.6 => /lib64/libXau.so.6 (0x00007f198b61a000)
        libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f198b364000)
        libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f198b132000)
        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f198af01000)
        libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f198acd3000)
        libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f198aa93000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007f198a88e000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f198a668000)
        liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f198a459000)
        libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00007f198a1d8000)
        libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f1989fd3000)
        libdw.so.1 => /lib64/libdw.so.1 (0x00007f1989d82000)
        libattr.so.1 => /lib64/libattr.so.1 (0x00007f1989b7d000)
        libelf.so.1 => /lib64/libelf.so.1 (0x00007f1989965000)

观察输出,所有依赖的动态链接库都有指向一个内存地址,说明所依赖的链接库都已经被加载入内存,排除了链接库不存在情况,下面就有可能是某个链接库有问题了,接下来做两件事:

  • 使用 objdump -T <lib name and path> |grep <funcname> 命令检索报错函数属于哪一个链接库;
  • 使用 find / -name <lib name> 命令查找是否有哪一个报错链接库在系统的动态链接库搜索目录中有多个;

经过一番检索,发现 [libgio-2.0.so](http://libgio-2.0.so) 在系统so检索目录有两个,分别是 /usr/local/lib/libgio-2.0.so/lib64/libgio-2.0.so ,其中 /lib64 为系统默认链接库存放位置,而 /usr/local 为编译安装库的默认安装位置,移除/usr/local/lib/libgio-2.0.so 之后再次尝试编译发现报错减少了。

此时发现系统曾编译安装了 glib ,可能是那时引入了一些错误的 so 库,因此进入编译目录 make uninstall 移除此前安装的错误的库,再次尝试编译发现编译通过。

总结

本次编译错误排查了很久,最后在大佬的协助下终于解决,此类缺少依赖错误排查错误思路可以总结为 检查链接库是否存在 -> 检查是否存在重复链接库 -> 移除错误链接库

参考文献