Operation not permitted引发的惊魂72小时

最新推荐文章于 2024-09-23 06:30:00 发布
最新推荐文章于 2024-09-23 06:30:00 发布
阅读量1.9w 收藏 3
点赞数 4
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dog250/article/details/9373715
版权

0.问题及描述

在测试产品的时候，莫名其妙发现了我们的主进程VPNd会出现以下的报错：
2013-07-18 13:05:13  www.1.com/192.168.200.220:65527 write UDPv4 []: Operation not permitted (code=1)
2013-07-18 13:05:13  www.1.com/192.168.200.220:65527 write UDPv4 []: Operation not permitted (code=1)
2013-07-18 13:05:13  www.1.com/192.168.200.220:65527 write UDPv4 []: Operation not permitted (code=1)
2013-07-18 13:05:13  www.1.com/192.168.200.220:65527 write UDPv4 []: Operation not permitted (code=1)
2013-07-18 13:05:13  www.1.com/192.168.200.220:65527 write UDPv4 []: Operation not permitted (code=1)
这种报错“但不经常，也不绝对”，上周末测试了两天，没有报错，可是周一就不行了，狂报错误！这种棘手的问题最可恶了。
        我排查问题的时候，第一步绝对是google，如果没有结果再按照自己的风格深入进去，能多深入就多深入，一旦有了解决的办法，我会发表在我所有博客上，这样以后别人再google的时候就会多一个答案，互联网时代的知识其实就是如此方式积累的。
        google了好久，没有什么创造性的结论，大量的关于这个错误的描述都是iptables DROP掉了数据包。其实我十分想找到一个和iptables无关的答案，直觉告诉我一旦找到了，错误原因基本就是那个(因为我的iptables规则根本就没有DROP掉任何东西)，可是我没有找到！没法发，只能自己来了。惊魂72小时就这样开始了！三天内，我连续两天搞到深夜，白天也几乎不想搭理任何人，要不是因为昨晚喝酒后作业，估计要减少10小时吧，不管这么说，这72小时还是值得纪念的。

1.证明是别的原因而不是iptables

ftrace是一个好东西，这个我早就说过，它很简单，一般的发行版都支持，于是我做了下面的动作企图得到调试信息： 
mount -t debugfs debug /sys/kernel/debug
然后看看有哪些东西可以为我所用。看了available_tracers，没有function，因此无法调式内核函数的调用堆栈，于是看看event，发现了kfree_skb，我们知道，一旦一个数据包被丢弃，肯定是要free掉的，因此它可以用： 
echo skb:kfree_skb >/sys/kernel/debug/tracing/set_event
可是一旦一个数据包成功到达用户socket或者成功从网卡发出，也是需要free掉的，所以就需要将后面两类free给过滤掉，可是怎么过滤呢？如果此时启用trace，cat /sys/kernel/debug/tracing/trace后发现会有一大堆类似下面的输出：
<...>-14297 [002]  1286.492153: kfree_skb: skbaddr=ffff88007c1e0100 protocol=2048 location=$kfree_skb调用的地址
怎么办呢？由于无法tracestack，那就就只能将上述的“kfree_skb调用的地址”在/proc/kallsyms中找了，注意，/proc/kallsyms中不可能有哪个函数完全匹配上面“kfree_skb调用的地址”，因为kallsyms中是内核函数的地址，而kfree_skb仅仅是内核函数中的调用，因此需要在“kfree_skb调用的地址”下方找最接近的函数。
        按照上面的过滤方式，一次次的发现正常的kfree_skb，然后将其echo到下面的文件中：
/sys/kernel/debug/tracing/event/skb/kfree_skb/filter
最终我得到了一个很长的过滤表达式： 
echo "location!=0xffffffffa026d04a && location!=0xffffffffa026c82a &&location!=0xffffffff812d6a6f && location !=0xffffffff812a092c &&location!=0xffffffff812aa03e && location != 0xffffffff812f726f &&location!=0xffffffffa01ee3af &&location!=0xffffffff812aaf82 && location!=0xffffffff812965a3 &&location != 0xffffffff812f622c &&location!=0xffffffff812c8324 && location!=0xffffffff812aace1 && location!=0xffffffff81294ef7 && location!=0xffffffff812a12b8 &&location!=0xffffffffa026d04a" >/sys/kernel/debug/tracing/event/skb/kfree_skb/filter
然后再次启动trace： 
echo 1 >/sys/kernel/debug/tracing/event/skb/kfree_skb/enable
为了使信息持续输出，写了下面的命令，写得不好是因为当前我只想赶紧定位问题，完全不在乎规范了： 
while true; do echo $(date); cat trace|grep -v FUNCTION|grep -v "tracer: nop"|grep -v "#              | |       |"|grep -v "#";>trace;sleep 4;done
上述命令的目的是持续输出最新的调试信息并且每次输出完把老的删除。
        然后就是漫长的等待，等待问题的重现。成小时成小时的等待...终于重现了，结果就是大量的：
<VPNd>-xx [002]  2876.582821: kfree_skb: skbaddr=ffff88007c1e0100 protocol=2048 location=ffffffff812b2887
查询kallsyms，发现它真的就是nf_hook_slow，而这个函数正是Netfilter的核心函数，难道真的是iptables导致的？我还是不相信！但是不能有更详细的信息了，要是能把stack打出来该多好啊！！

2.需要更加详细的信息

很显然，没有function trace支持的内核无法通过ftrace得到更加详细的信息了，其实我现在就是想得到问题重现时调用nf_hook_slow时的堆栈。重新编译内核肯定能解决，但是场面过于宏大，于是想办法自己hack一个，于是编写了下面的模块： 
#include <linux/types.h>
#include <linux/module.h>
#include <linux/smp_lock.h>
//#include <linux/netfilter.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("ZhaoYa <marywangran@126.com>");
MODULE_DESCRIPTION("Xtables: DNAT from ip-pool");

//准备替换掉nf_hook_slow
int (*orig_nf_hook_slow) (u_int8_t, unsigned int, struct sk_buff*, struct net_device*, struct net_device*, int (*okfn)

(struct sk_buff *), int) = 0xffffffff8126a910;
char code[200] = {0};

int (*_nf_hook_slow) (u_int8_t, unsigned int, struct sk_buff*, struct net_device*, struct net_device*, int (*okfn)(struct

sk_buff *), int);
int new_nf_hook_slow(u_int8_t pf, unsigned int hook, struct sk_buff *skb,
                 struct net_device *indev,
                 struct net_device *outdev,
                 int (*okfn)(struct sk_buff *),
                 int hook_thresh)
{
    //先调用原来的nf_hook_slow
        int ret = _nf_hook_slow(pf, hook, skb, indev, outdev, okfn, hook_thresh);
        //如果被DROP了就打印堆栈
    if (ret = 1) {
                dump_stack();
        }
        return ret;
}

static int __init pool_target_init(void)
{
    //0xffffffff8126a910是原始nf_hook_slow的地址，
    //由于还要使用该处的代码，覆盖前先保存在别处
        char *addr = 0xffffffff8126a910;
    //由于需要重写0xffffffff8126a910，防止内核设置了只读，
    //故需要修改PTE页表项
        char *pte = 0xfffffffff126a161;
        lock_kernel();
        unsigned long value =*pte;
        value = value|0x02;
        *pte = value;
    //先将原始函数保存在code里面，200这个长度是原始nf_hook_slow的地址
    //和它下面一个函数地址的差值多一点，由于代码中肯定有return，因此多
    //复制一些没关系，少了就不行。
        memcpy(code, orig_nf_hook_slow, sizeof(code));
    //用新的nf_hook_slow覆盖原来函数的地址
        memcpy(addr, new_nf_hook_slow, 40);
      //保存原始函数的新地址
        _nf_hook_slow = code;
        unlock_kernel();
        return 0;
}

static void __exit pool_target_exit(void)
{
        char *addr = 0xffffffff8126a910;
        lock_kernel();
        memcpy(addr, code, sizeof(code));
        unlock_kernel();
}

module_init(pool_target_init);
module_exit(pool_target_exit);

代码乱七八糟的，由于在原有的一个nat模块上更改(便于使用它的Makefile)，因此命名也不合常理。加载之，报错，panic！！
        ...
        直到现在仍然没有编译新内核的勇气
        ...
        心中的气愤达到了要崩溃的地步，终于决定重新编译内核了！

3.重新配置并编译内核以及所有模块

下午2点开始，重新配置内核，新增的配置如下：
< CONFIG_FRAME_POINTER=y
< CONFIG_HAVE_FTRACE_NMI_ENTER=y
< CONFIG_FTRACE_NMI_ENTER=y
< CONFIG_FUNCTION_TRACER=y
< CONFIG_FUNCTION_GRAPH_TRACER=y
< CONFIG_FTRACE_SYSCALLS=y
< CONFIG_STACK_TRACER=y
< CONFIG_WORKQUEUE_TRACER=y
< CONFIG_DYNAMIC_FTRACE=y
< CONFIG_FUNCTION_PROFILER=y
< CONFIG_FTRACE_MCOUNT_RECORD=y
这样就可以支持function trace了！然后make-kpkg编译之。漫长3小时后，还没有编译完，我的虚拟机真的不行了。要下班了，匆匆回家，以前从来没有这么早过，在路上可以换换心情。发现我的心理素质还不错，路上结掉了《罗马人的故事：最后一搏》，超级崇拜君士坦丁！
        回家吃完晚饭，又开始了惊魂之旅，通过VPN接入公司的机器，发现终于编译完成，于是赶紧先提交到SVN上，大概九点多，准备用新内核调试，由于兴奋喝了半瓶酒，酒后作业不管干什么都很危险，不仅仅是开车。在升级内核时，一下子把grub也给换掉了，reboot没有成功，公司机器又不支持IPMI远程开机，这下悲催了...只能早早睡了！

4.新的ftrace以及stack trace

今天早上赶紧到公司，配置好了新的环境，升级了新的内核，终于可以一窥究竟了，等待问题重现后，打印了以下信息：
          <...>-27369 [002]  2876.582821: kfree_skb: skbaddr=ffff88007c1e0100 protocol=2048 location=ffffffff812ad914
           <...>-27369 [002]  2876.582825: <stack trace>
 => kfree_skb
 => nf_hook_slow
 => T.889
 => ip_output
 => ip_local_out
 => ip_push_pending_frames
 => udp_push_pending_frames
 => udp_sendmsg
           <...>-27369 [002]  2876.583069: kfree_skb: skbaddr=ffff88007c1e0c00 protocol=2048 location=ffffffff812ad914
           <...>-27369 [002]  2876.583074: <stack trace>
 => kfree_skb
 => nf_hook_slow
 => T.889
 => ip_output
 => ip_local_out
 => ip_push_pending_frames
 => udp_push_pending_frames
 => udp_sendmsg
          <idle>-0     [002] 11979.770335: kfree_skb: skbaddr=ffff88002f3f5200 protocol=2048 location=ffffffff812ad914
          <idle>-0     [002] 11979.770338: <stack trace>
 => kfree_skb
 => nf_hook_slow
 => ip_local_deliver
 => ip_rcv_finish
 => ip_rcv
 => netif_receive_skb
 => br_handle_frame_finish
 => br_nf_pre_routing_finish
.....大量的br_nf_pre_routing_finish起始的stack到达ip_local_deliver后被Netfilter丢弃
        起初，我以为都是VPNd发出的数据包被DROP，现在看来bridge接收的数据包也会被DROP(此时的进程是内核本身即0号idle进程，其实它并不idle，新内核的所有内核线程都在idle的工作队列里)，从以上堆栈看，ip_local_deliver以及ip_output对应的HOOK点分别应该是INPUT以及POSTROUGING，由于我并没有在这两个Chain上添加任何iptables的DROP策略，鉴于对Netfilter的理解比较深入，因此我觉得是内核本身隐含的一些HOOK函数导致的，为了找到是哪个隐含的HOOK函数，就有必要跟一下代码，由于使用ftrace输出大量的信息会遇到薛定谔猫的问题，因此决定静态浏览代码。
        这里有一个疑点，那就是起初我以为丢包都是VPNd进程造成的，可是从ftrace的结果看来，大量的丢包是ilde进程的softirq中造成的，很明显是数据包的接收进程造成了丢包；还有一个疑点，那就是通过查看/proc/net/snmp文件，发现其OutDiscards字段在问题重现即Operation not permitted的时候有所增加，而OutDiscards的增加仅仅在确定的地方被调用。在没有全面分析问题之前，这两个疑点说明了两个问题，一是ip_local_out函数确实有丢包，二是可能是一个全局问题导致了这个丢包，因为并不是仅仅在发送数据的时候丢包。
注解：如果看上述堆栈，会发现br_nf_pre_routing_finish-br_handle_frame_finish-netif_receive_skb跟实际不一样，这是因为我修改了nf_bridge的缘故，我的目标是先让bridge去call iptables的PREROUTING，然后再基于mark绝对是否进行bridge的redirect。

5.遍历Netfilter的OUTPUT以及POSTROUTING

遍历代码的过程是痛苦的，无非就是找到内核隐含的HOOK函数中，在什么情况下会DROP掉数据包，并且还要在INPUT以及POSTROUTING这两个点上。最后__nf_conntrack_confirm引起了我的注意，因为数据包在离开协议栈的时候，会调用confirm，这个是为了将NEW状态的conntrack添加到conntrack哈希中，恰恰这个confirm也正是在INPUT以及POSTROUTING这两个点上，这两个点正是数据包离开协议栈的点！更加幸运的是，竟然在该函数中找到了DROP： 
int
__nf_conntrack_confirm(struct sk_buff *skb)
{
    ...
    //如果标示为NEW的conn在双向的哈希表中找到了相同的，则DROP
    hlist_nulls_for_each_entry(h, n, &net->ct.hash[hash], hnnode)
        if (nf_ct_tuple_equal(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple,
                      &h->tuple))
            goto out;
    hlist_nulls_for_each_entry(h, n, &net->ct.hash[repl_hash], hnnode)
        if (nf_ct_tuple_equal(&ct->tuplehash[IP_CT_DIR_REPLY].tuple,
                      &h->tuple))
            goto out;
...
out:
    NF_CT_STAT_INC(net, insert_failed);
    spin_unlock_bh(&nf_conntrack_lock);
    return NF_DROP;
}
浏览代码到此为止，因为我找到了可以调试的东西了，如果那条路不通，再继续看代码。这个东西就是：
NF_CT_STAT_INC(net, insert_failed);
这是一个内核计数器，名称是insert_failed，于是借助于procfs的net/stat目录观测。

6.定位到insert_failed计数器

通过查看/proc/net/stat/nf_conntrack，发现了下面的事实：
XXXX-SSL-GATEWAY:/proc/net# cat stat/nf_conntrack
entries  searched found new invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error  expect_new expect_create expect_delete
00002236  00692e45 024a9466 001e1713 00008ab5 00008007 001cad74 001c9b8d 001e087b 00000e7f 00000000 00000000 000004a1  00000000 00000000 00000000
00002236  0067bfee 0241465c 001db7e0 00008853 00007756 001f1fe9 001f1265 001daab2 00000d19 00000000 00000000 0000049b  00000000 00000000 00000000
00002236  00656b68 02332e99 001d3312 00008026 00007795 001d9498 001d8a18 001d2575 00000d8f 00000000 00000000 00000482  00000000 00000000 00000000
00002236  0062d343 02261842 001cccef 00007ca2 0000792a 001c4ac9 001c3e58 001cbff6 00000ceb 00000000 00000000 000004a5  00000000 00000000 00000000
# 此处的时间内，问题重现了
XXXX-SSL-GATEWAY:/proc/net# cat stat/nf_conntrack
entries  searched found new invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error  expect_new expect_create expect_delete
000021c9  006b559d 0259312e 001ecf50 00008e14 00008023 001d83fa 001d7298 001ec0b8 00000e7f 00000000 00000000 000004a3  00000000 00000000 00000000
000021c9  0069b52e 024fdc33 001e6eb1 00008be5 00007760 001fb89d 001faa7c 001e6181 00000dab 00000000 00000000 000004a1  00000000 00000000 00000000
000021c9  006765ca 02416a16 001de7ab 0000835f 000077a8 001e49e8 001e3f81 001dda05 00000d98 00000000 00000000 00000485  00000000 00000000 00000000
000021c9  0064d066 0233c2d7 001d7e55 00007f83 0000792c 001cfbb9 001cef3c 001d715c 00000ceb 00000000 00000000 000004a5  00000000 00000000 00000000
注意上面的insert_failed计数器的递增，说明什么？说明正是那个__nf_conntrack_confirm函数将数据包DROP了。
        问题定位了，下面就是解决它了！出去抽根烟，理一下思路。

7.丢弃ftrace，开始用conntrack工具

至此，不再需要ftrace了，暂时不需要了，因为下面的工作我很自信，也会用比较YD的方式去解决，关掉ftrace以防薛定谔猫的惊现！ 
echo 0 >/sys/kernel/debug/tracing/event/skb/kfree_skb/enable
umount /sys/kernel/debug
要调试conntrack，只有conntrack-tools，因此敲入下面的命令： 
conntrack -E -e DESTROY
这样就可以监控conn的销毁事件了。又来了拦路虎，由于系统连接数过多，马上就报错了：
WARNING: We have hit ENOBUFS! We are losing events.
This message means that the current netlink socket buffer size is too small.
Please, check --buffer-size in conntrack(8) manpage.
conntrack v1.0.0 (conntrack-tools): Operation failed: No buffer space available
这下没辙了，于是又写了一个命令： 
while true;do echo $(date);cat ip_conntrack|grep 192.168.200.220|grep udp;echo ;echo;sleep 2;done
将Operation not permitted相关的IP地址以及协议过滤出来，持续展示。在问题重现的瞬间：
2013年 07月 18日 星期四 13:02:15 CST
udp      17 179 src=192.168.200.220 dst=192.168.101.242 sport=16796 dport=61194 packets=161510 bytes=27474312 src=192.168.101.242 dst=192.168.200.220 sport=61194 dport=16796 packets=140004 bytes=36911621 [ASSURED] mark=100 secmark=0 use=2


2013年 07月 18日 星期四 13:02:18 CST
2013年 07月 18日 星期四 13:02:22 CST
conntrack突然消失了，这就不对了，还剩下179秒才到期，怎么会被删除呢？下一步其实又要看代码了，看一下都在哪里调用删除conntrack的动作，但是我觉得已经没有必要了，因为我已经知道了答案，在我们的产品中，前期为了解决一个问题，调用了conntrack -F命令...
        实际上，即使我不知道调用conntrack -F，也还是能定位了确实有人调用了conntrack -F的。通过观察上面的ftrace输出就会发现，每次只要udp_sendmsg造成的DROP的同时，都会有大量的br_nf_pre_routing_finish造成的DROP，反过来也一样，导致我曾经想过二者是不是一方的发生导致了另一方的发生，后来我发现它们没有什么关系，那么这能证明什么呢？--------------- 证明一定有大量的conntrack同时被删除的情况------------ 如果内核中有自动的大量信息被同时删除，那一定是缺陷，设计者不会做如此不平滑的事情的。一般而言都是丢弃当前的。这就说明一定是用户态有人通过系统提供的接口手工调用了删除操作，罪魁祸首，当然是conntrack -F了！

8.没办法了，只靠想了

现在问题还没有解决，需要想一下就是conntrack被删除，如何能导致数据包在__nf_conntrack_confirm被DROP呢？这样反过来确认一下，可以尽可能排除其它的因素。这个也没办法再调试了，只能靠想了，但是前提是你需要对Netfilter对conntrack的处理极其精通，我给出一张时序图来说明问题吧：
注意__nf_conntrack_confirm的注释“如果标示为NEW的conn在双向的哈希表中找到了相同的，则DROP”

连接是双向的，而conntrack却只有一个是问题的关键，由此看来，还是TCP的有状态conntrack比较完美。
        这个问题真的很不好重现，我试着手工调用了几次conntrack -F，并不是每次都能重现，甚至连续好几次执行才能重现。必须卡在上图的那些时间点，问题才能重现，因此这是个“但不经常，也不绝对”的问题！！
       通过上图，我们可以发现，在多处理器环境下更容易发生这个问题，因为在多处理器情况下，问题的重现不仅仅取决于udp发送进程的

schedule，还取决于其它处理器上网络数据包接收进程的执行。

9.尴尬的解决方式

为何尴尬？问题不是解决了吗？是的，问题解决了，但是解决方式确实很尴尬，就是去掉了conntrack -F而已，太TMD没有技术含量了。然而对于技术痴迷者而言，这惊魂72小时确实让我学到了很多东西，也让我明白以后应该试着不把简单问题复杂化，到底哪里出了问题的另一个问法其实就是“我到底添加了哪些功能”，在没有问题发生到有问题出现的时间段内的任何更改都可能导致各种奇异的问题。
        作为一个bug的定位和解决，确实很尴尬，但是对于一个技术痴迷者而言，重要的是知其所以然，是为所以然。

10.经验

没有什么经验，唯一的经验就是在加入一个功能的时候，一定要彻底了解该功能所用到的所有的技术细节，否则就很有可能引入新的问题！对待技术问题决不能模棱两可，要么不用，要用就要彻底摸清！

11.关于标题

本文之所以取这么一个名字，是因为希望别人比较容易搜到这篇文章，因为我在起初解决问题google的时候，花了大量的时间没有结果，不管国内国外的高手，都没有切入重点。因此我希望我这篇惊魂72小时可以对大家有所帮助，毕竟我起初也是希望能直接在网上找到答案，怀着这么一种侥幸心理，不想自己努力，只是没有找到结果以后，不得已才自己摸索的。这样的人我相信是大多数，因此我希望大家都能继续尝试这种方式，毕竟是懒人创造了世界，懒人并不懒惰，懒人不重新造轮子，但是在迫不得已不得不重新造轮子的时候，他的目的是不希望别人-别的懒人重新造轮子！

12.72小时内的生活

我感觉自己就是双核，我可以在72小时内保持紧张去排查这个问题，然而另一方面，我又有自己其它方面的收获：
1.结掉了第9本《罗马人的故事》，是为最后的一搏，为戴克里先感到悲哀。
2.查阅了君士坦丁的相关资料，理解了他为何结束了罗马帝国，创建了中世纪。
3.靠地利优势可以胜过天时和人和。
dog250
关注
MacOS无法挂载NFS Operation not permitted错误解决办法
08-31
在使用MacOS操作系统时，有时会遇到尝试挂载NFS（网络文件系统）共享时遇到“Operation not permitted”错误。这个错误通常是由于安全策略或权限设置不正确导致的。本文将详细讲解如何解决这个问题。 首先，确保你...
“ operation not permitted” 错误解决办法
热门推荐
业余前端的职业经历
08-17 3万+
举例说明 我是要删除文件夹代码 如果这个文件夹中得 某些文件正在被其他的项目引用着 而且那个项目还是运行中 那么就会报错 不许这样操作 删除之前 先把运行的代码关闭了 再次运行就可以了 ...
Linux下操作文件时提示：Operation not permitted
最新发布
nimizi_2009的博客
09-23 2006
2、如上面的命令输出所示，文件被赋予了只允许追加属性(a)，这意味着此文件只能被追加内容，而对文件附加删除、清空、移动等操作都将被系统拒绝。在此你还需要确认除了a属性外，文件是否还被赋予了其他特殊属性。在有些Linux系统下可能存在 /var/log/messages文件过大需要清理的情况，而系统管理员在通过。命令设置的，用于控制文件系统的特殊行为。与常规的文件权限不同，这些属性提供了更精细的控制，例如防止文件被删除或修改。的输出通常包含一系列标志和对应的文件名，每个标志代表一个特定的文件属性。
Linux内核：写proc文件的返回值问题
kanguolaikanguolaik的专栏
08-12 1万+
一、使用说明 1. 用户态写（echo或write()）内核/proc文件时，返回值，就是内核的函数提供的返回值。 2. echo数据时的返回情况：         a. echo写int数据，可以用以下2种方式：                 echo "6" > /proc/sys/net/ipv4/test/testdata                 echo 7 > /p
运行./android_server时提示socket: Operation not permitted
weixin_43873389的博客
08-01 3580
问题：运行./android_server时提示socket: Operation not permitted 解决办法：在apk的androidmanfest.xml 中添加网络权限 <uses-permission android:name="android.permission.INTERNET"/>
docker内 jmap|jstack操作时，错误提示 ptrace(PTRACE_ATTACH, ..) failed for 219: Operation not permitted
weixin_45444133的博客
01-12 3275
因为需要分析java内存增长原因，今天准备去dump一个 java 线程下来，下面是docker 内部执行dump操作时遇到的问题与解决步骤。 开始dump # 执行 jstack jstack -l 219 > test.dump 219: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target proces
PHP解决Operation not permitted in
01-10
在PHP开发过程中，有时会遇到"Operation not permitted"这样的错误，这通常是由于权限问题导致的。这个错误通常出现在尝试执行一些系统级别的操作，比如改变文件或目录的所有权、修改文件权限，或者执行需要较高权限...
Linux删除文件提示Operation not permitted的处理办法
01-20
经常有同事问，删除文件/目录时报Operation not permitted错误，这个要如何处理？！ 这个一般是权限的问题，比如: 1. 普通用户且有足够的权限的话，一般文件夹可能是别的服务/进程掉用该文件夹 lsof +D /Dir/Your/...
am335x gpio 控制的另一种方法
weixin_34125592的博客
08-29 273
#include &lt;linux/gpio.h&gt;  #include &lt;linux/module.h&gt;  #include &lt;linux/kernel.h&gt;  #include &lt;linux/moduleparam.h&gt;  #include &lt;linux/delay.h&gt;  #include &lt;linux/types.h&gt;  #...
Operation not permitted
missiletcy的博客
07-08 5085
经常有同事问，删除文件/目录时报Operation not permitted错误，这个要如何处理？！ 这个一般是权限的问题，比如: 1. 普通用户且有足够的权限的话，一般文件夹可能是别的服务/进程掉用该文件夹 lsof +D /Dir/Your/Want/To/Delete/ 先执行上面的命令，查询到调用该文件夹的进程IDs，然后再kill掉，这个时候应该就可以删了！ 2. 普通用户且缺乏权限的话，如果要删除该文件夹则要借助su或者sudo命令来删除 3. 如果是root用户，依然报上面.
nf_conntrack: table full, dropping packet. 终结篇
weixin_30585437的博客
06-28 715
“连接跟踪表已满，开始丢包”！相信不少用iptables的同学都会见过这个错误信息吧，这个问题曾经也困扰过我好长一段时间。此问题的解决办法有四种（nf_conntrack 在CentOS 5 / kernel <= 2.6.19中名为 ip_conntrack ）： 一、关闭防火墙。 简单粗暴，直接有效 chkconfig iptables off chkconfig ip...
Linux下jmap工具出现sun.jvm.hotspot.debugger.DebuggerException解决方法
DemoTransfer
09-21 2万+
参照连接 https://stackoverflow.com/questions/2913948/jmap-cant-connect-to-make-a-dump 1 问题描述 Attaching to process ID 12499, please wait... Error attaching to process: sun.jvm.hotspot.debugger.DebuggerEx...
Java 工具（jmap,jstack）在linux上的源码分析(五) -F 参数的bug
test_touch的专栏
02-09 375
当使用jmap,jstack是用-F参数的时候，是通过调用系统调用ptrace来取的寄存器的信息，关于linux下的ptrace实现可以参考我的博客（http://blog.csdn.net/raintungli/article/details/6563867） 在jdk6u23版本之前你会发现，当你使用jstack -F的时候 经常在logger 里面 看到错误信息，直接抛出异常，根本无法看到...
linux多线程创建失败，errno=1:Operation not permitted
dragon_cdut的博客
10-24 5969
报错：Thread creation failed: errno=1,Operation not permitted 原因分析：在linux环境下编译程序时，没有在root权限下进行 解决办法：编译多线程程序时，在root用户下输入命令：$make即可
JVM故障处理工具，使用总结
bugstack虫洞栈
01-14 3212
作者：小傅哥 博客：https://bugstack.cn 沉淀、分享、成长，让自己和他人都能有所收获！???? 一、前言 用都用不到怎么学？ 没有场景、没有诉求，怎么学习这些似乎用不上知识点。 其实最好的方式就是归纳、整理、实践、输出，一套组合拳下来，你就掌握了这个系列的知识了。 但在当前阶段可能真的用不上，JVM是一个稳定服务，哪能天天出问题，哪需要你老排查。又不是像你写的代码那样！ 可是知识的学习就是把你垫基到更高层次后，才有机会接触更有意思的工作和技术创新。如果只是单纯的学几个指令，其实并没有多
收藏jstack命令，查看线程中栈的报错信息，报错解答：http://blog.51cto.com/zhangshaoxiong/1310166
王子的博客
05-21 286
jstack命令报错解答：http://blog.51cto.com/zhangshaoxiong/1310166
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值