一.引言: 最近发现datanode老是无缘无故的进程挂掉,从程序的日志没有stop迹象,只能从/var/log/messages入手,发现如下信息: 从namenode的页面也可以看到进程消息的时间点: 由此可以看出进程是跟abrt有一定的关系的. 二.解决问题: 这是因为无法创建ccpp文件导致的,因为需要修改/etc/abrt/abrt-action-save-package-data.conf中ProcessUnpackaged参数,修改如下: 可以使用如下命令: sed -i 's/P

vi 有三种模式,输入模式,编辑模式,“:”命令模式vi 进入以后默认是编辑模式vi 编辑模式默认的快捷键 上下左右分别是 J K H Lvi 在编辑模式使用 i 可以进入输入模式vi 输入模式只能输入英文,默认不能使用上下左右箭头vi 输入模式用Esc可以返回到编辑模式vi 编辑模式 Shift + ; 可以进入命令模式vi 命令模式w保存,q退出 在「命令行模式(command mode)」下,按一下「:」冒号键进入「Last line mode」,例如: : w filename (输入

gdb-7.2-64.el6_5.2.x86_64/usr/bin/gcore/usr/bin/gdb/usr/bin/gdb-add-index/usr/bin/gdbtui/usr/bin/gstack/usr/bin/pstack [root@coreserv tmp]# rpm -qa|grep abrabrt-libs-2.0.8-6.el6.centos.x86_64abrt-addon-ccpp-2.0.8-6.el6.centos.x86_64abrt-2.0.8-6.el6.c

CentOS版本 cat /etc/centos-release  CentOS Linux release 7.2.1511 (Core) 设置ulimit -c ulimited 依旧无法生成coredump文件,其中也检查了cat /proc/sys/kernel/core_pattern 及/etc/abrt/abrt-action-save-package-data.conf 设置. 网上报出类似错误[https://access.redhat.com/solutions/218144

http://www.cnblogs.com/hugetong/p/6898608.html 一个程序挂掉了, 怎么办?  启动coredump 写一个脚本: [root@T185 ~]# cat /etc/a.sh ulimit -c cd /data/coredump/ /root/a.out cd - [root@T185 ~]# ulimit -c 的参数单位是512byte, 乘以204800就是100MB. 默认在那个目录启动, 就在那个目录存在coredump, 所以就cd一下.

[net] ######################## cat /proc/sys/net/ipv4/tcp_syncookies # 默认值:1 # 作用:是否打开SYN Cookie功能,该功能可以防止部分SYN攻击 net.ipv4.tcp_syncookies = 1   ######################## cat /proc/sys/net/ipv4/ip_local_port_range # 默认值:32768   61000 # 作用:可用端口的范围 net.i

[net] ######################## cat /proc/sys/net/ipv4/tcp_syncookies # 默认值: # 作用:是否打开SYN Cookie功能,该功能可以防止部分SYN攻击 net.ipv4.tcp_syncookies = ######################## cat /proc/sys/net/ipv4/ip_local_port_range # 默认值: # 作用:可用端口的范围 net.ipv4.ip_local_port_

一.系统相关 1.系统关键文件设置 1.1.设置文件初始权限 设置默认的umask值,增强安全性. [root@localhost ~]# umask 0022 /etc/profile最下面添加一行: [root@localhost ~]# vim /etc/profile umask 027 上面的设置,即新创建的文件属主拥有读写执行权限,同组用户拥有读和执行权限,其他用户无权限. 1.2.锁定关键文件 用chattr命令防止系统中的一些关键文件被修改 +i表示文件不允许新增.删除.修改.改

问题一:故障记录时间2019年4月4日,查看系统日志报错如下: tail -f /var/log/messages Apr 4 16:29:16 localhost kernel: tracker-extract[18065]: segfault at 205f0 ip 00000000000205f0 sp 00007ffdef1af718 error 14 in tracker-extract[400000+15000] Apr 4 16:29:16 localhost abrt-hook-

1:当一个程序崩溃时,在进程当前工作目录的core文件中复制了该进程的存储图像.core文件仅仅是一个内存映象(同时加上调试信息),主要是用来调试的. 当程序接收到以下UNIX信号会产生core文件:SIGABRT.SIGBUS.SIGEMT.SIGFPE.SIGILL.SIGIOT.SIGQUIT.SIGSEGV.SIGSYS.SIGTRAP.SIGXCPU.SIGXFSZ: 下面比较详细地说明这些信号. • SIGABRT 调用abort函数时产生此信号.进程异常终止. • SIGBUS 指

前言 在现网环境下,程序奔溃后不一定会留下core文件,原因有很多,比如存储空间不足就是其中一个常见的原因.此时我们只能依据linux记录的错误日志来定位问题. 涉及linux命令 本文涉及以下几条命令 1. dmesg命令,用于获取程序出错时的堆栈地址 1)dmesg |grep -E 'segfault|general'可以通过该命令过滤出发生崩溃的程序,以及对应的堆栈信息.之前看网上的其他文章仅过滤segfault,但我在实践中发现"general protection"的提示信

什么是 core dump? core dump是一个当进程意外终止时包含进程内存内容的文件.当程序崩溃的时候,core dump由kernel触发.core dump可以作为程序崩溃时的事后快照(post-mortem snapshot),尤其是在难以可靠的重现故障的情况下. 大多数Linux系统默认开始core dump.但是通常这么做是有代价的.一方面我们想要去收集信息从而提高稳定性并且帮助我们排除故障:另一方面,我们希望限制debug的数据并且避免泄漏一些敏感数据.第一个选择适合于研究不

当系统发生coredump时,通常需要通过分析core文件来定位问题所在,但实际工作中,有时却发现core 文件找不到,或者core文件被删除了. 一.core文件没有生成 KINGBASE core 文件通常是在 $KINGBASE_DATA目录下.可以使用 coredumpctl list 查找core 文件是否生成 (对于abrtd 服务生成的coredump不会列出): [kingbase@dbhost03 ~]$ coredumpctl list No coredumps found.