Description of problem: When smbd crashes the log shows that the core is dumped in /var/log/samba/cores/smbd but actually the core is getting dumped in /var/log/cores. [2016/05/09 13:20:36.759067, 0] ../source3/lib/dumpcore.c:318(dump_core) dumping core in /var/log/samba/cores/smbd Version-Release number of selected component (if applicable): samba-client-4.4.3-1.el6rhs.x86_64 glusterfs-cli-3.7.9-3.el6rhs.x86_64 How reproducible: Always Steps to Reproduce: 1. Bring up a gluster samba set up 2. Mount the share on windows client 3. Do smbstatus and take the pid 4. kill -6 pid 5. Check the client log 6. Check for the core dump Actual results: Client log says dumping core in /var/log/samba/cores/smbd but the core is present in /var/log/cores Expected results: The log should exactly say where the core is being dumped Additional info: [2016/05/09 13:20:36.758182, 0] ../source3/lib/util.c:902(log_stack_trace) BACKTRACE: 18 stack frames: #0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7fb75fce08ba] #1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x23) [0x7fb75fce0983] #2 /usr/lib64/libsamba-util.so.0(smb_panic+0x3a) [0x7fb7621d414a] #3 /usr/lib64/libsamba-util.so.0(+0x25362) [0x7fb7621d4362] #4 /lib64/libpthread.so.0(+0x3a57a0f7e0) [0x7fb7624337e0] #5 /lib64/libc.so.6(__poll+0x53) [0x7fb75e466283] #6 /usr/lib64/libsmbconf.so.0(+0x36c48) [0x7fb75fcf6c48] #7 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7fb75e71ecdd] #8 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7fb75e71ed5b] #9 /usr/lib64/samba/libsmbd-base-samba4.so(smbd_process+0x779) [0x7fb761d90e49] #10 smbd(+0xa838) [0x7fb76286e838] #11 /usr/lib64/libsmbconf.so.0(run_events_poll+0x2b7) [0x7fb75fcf6837] #12 /usr/lib64/libsmbconf.so.0(+0x36c86) [0x7fb75fcf6c86] #13 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7fb75e71ecdd] #14 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7fb75e71ed5b] #15 smbd(main+0x182f) [0x7fb7628705bf] #16 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fb75e3a5d1d] #17 smbd(+0x6499) [0x7fb76286a499] [2016/05/09 13:20:36.759067, 0] ../source3/lib/dumpcore.c:318(dump_core) dumping core in /var/log/samba/cores/smbd
In general this behaviour is expected. Here's why? As we have observed before in a related BZ 1322672 for RHEL7, vdsmd which comes from vdsm package overwrites the system-wide /proc/sys/kernel/core_pattern to /var/log/core/core.%p.%t.dump and sets a particular context on /var/log/core in an RHGS installation. For more details refer the other bug report. Due to changes in boot sequence run levels for abrt-ccpp and vdsmd init scripts, in RHEL6 the core_pattern set by vdsmd is again replaced by abrt-ccpp with |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e. As a result abrt-ccpp saves the previous core_pattern under /var/run/abrt/saved_core_pattern. Even though abrt handles the coredump procedure it also have an option to dump the core in old location based on whether MaxCompatCore is set to 'yes' or not in /etc/abrt/plugins/CCpp.conf. By default this parameter is set to yes and thus coredump is available at abrt's location and under /var/log/core/. And the misleading log message in Samba logs is something we need to fix based on whether the core_pattern file content starts with a '/' or '|'. Currently Samba only checks for '/' and not '|'.
Here is the upstream patch: https://git.samba.org/?p=samba.git;a=commit;h=656f2a9dcd6822e1e8606a56bf4cd8984ce80f5d
Unable to verify as blocked because of https://bugzilla.redhat.com/show_bug.cgi?id=1444028
Followed the below steps Steps to Reproduce: 1. Bring up a gluster samba set up 2. Mount the share on windows client 3. Do smbstatus and take the pid 4. kill -6 pid 5. Check the client log 6. Check for the core dump There is no misguiding message in log with the latest build, the message that is reflecting now is appropriate (as mentioned below) 2017/06/09 12:58:38.490826, 0] ../source3/lib/dumpcore.c:318(dump_core) coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2778