Bug 1334397

Summary: Samba [RHEL6] : Upon smbd crash the log displays core dump path as /var/log/samba/cores/smbd but in actual the core is dumped in /var/log/cores
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Vivek Das <vdas>
Component: sambaAssignee: Anoop C S <anoopcs>
Status: CLOSED ERRATA QA Contact: Vivek Das <vdas>
Severity: high Docs Contact:
Priority: high    
Version: rhgs-3.1CC: amukherj, anoopcs, asrivast, nlevinki, rhinduja, rjoseph
Target Milestone: ---Keywords: ZStream
Target Release: RHGS 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: samba-4.6.0-0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-09-21 04:46:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1417147    

Description Vivek Das 2016-05-09 13:52:03 UTC
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

Comment 4 Anoop C S 2016-11-15 10:32:09 UTC
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 '|'.

Comment 6 Anoop C S 2017-02-21 11:58:13 UTC
Here is the upstream patch:

https://git.samba.org/?p=samba.git;a=commit;h=656f2a9dcd6822e1e8606a56bf4cd8984ce80f5d

Comment 8 Vivek Das 2017-04-24 11:03:48 UTC
Unable to verify as blocked because of 
https://bugzilla.redhat.com/show_bug.cgi?id=1444028

Comment 9 Vivek Das 2017-06-09 08:23:06 UTC
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

Comment 11 errata-xmlrpc 2017-09-21 04:46:03 UTC
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