[Samba] Repeat core dumps due to libgcrypt?

[Ochressandro Rettinger]

Hi, sorry. I have spent about 4 hours googling, and had no luck.
I'm getting repeat core dumps out of smbd, and nothing I've gotten from
the log file has successfully pointed me at any indication that anyone
else has posted about this problem before.

------

libgcrypt selftest: binary (0): Selftest failed
(/lib64/.libgcrypt.so.11.hmac)
fatal error in libgcrypt, file visibility.c, line 1250, function
gcry_create_nonce: called in non-operational state
[2016/04/04 14:39:20.089157, 0] ../lib/util/fault.c:72(fault_report)
===============================================================
[2016/04/04 14:39:20.089302, 0] ../lib/util/fault.c:73(fault_report)
INTERNAL ERROR: Signal 6 in pid 3692 (4.0.0rc4)
Please read the Trouble-Shooting section of the Samba HOWTO
[2016/04/04 14:39:20.089465, 0] ../lib/util/fault.c:75(fault_report)
===============================================================
[2016/04/04 14:39:20.089580, 0] ../source3/lib/util.c:810(smb_panic_s3)
PANIC (pid 3692): internal error
[2016/04/04 14:39:20.090361, 0]
../source3/lib/util.c:921(log_stack_trace)
BACKTRACE: 29 stack frames:
#0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7f3cc61f4f8a]
#1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x25) [0x7f3cc61f5055]
#2 /usr/lib64/libsamba-util.so.0(smb_panic+0x1a1) [0x3950017801]
#3 /usr/lib64/libsamba-util.so.0() [0x39500178c2]
#4 /lib64/libpthread.so.0() [0x3999a0f7e0]
#5 /lib64/libc.so.6(gsignal+0x35) [0x3999632625]
#6 /lib64/libc.so.6(abort+0x175) [0x3999633e05]
#7 /lib64/libgcrypt.so.11(+0x399e60e398) [0x7f3cc1332398]
#8 /lib64/libgcrypt.so.11(gcry_create_nonce+0x46) [0x7f3cc132b0f6]
#9 /usr/lib64/libgnutls.so.26(+0x39a1e3e887) [0x7f3cc1a89887]
#10 /usr/lib64/libgnutls.so.26(+0x39a1e3cb1c) [0x7f3cc1a87b1c]
#11 /usr/lib64/libgnutls.so.26(gnutls_global_init+0x126)
[0x7f3cc1a78456]
#12 /usr/lib64/libcups.so.2(httpInitialize+0x41) [0x39a1222a21]
#13 /usr/lib64/libcups.so.2(_httpCreate+0x95) [0x39a1222ae5]
#14 /usr/lib64/libcups.so.2(httpConnectEncrypt+0x1a) [0x39a1222c1a]
#15 /usr/lib64/samba/libsmbd_base.so(+0xa82d8) [0x7f3cc69202d8]
#16 /usr/lib64/samba/libsmbd_base.so(cups_cache_reload+0x205)
[0x7f3cc6922f55]
#17 /usr/lib64/samba/libsmbd_base.so(pcap_cache_reload+0x146)
[0x7f3cc691fd46]
#18 /usr/lib64/samba/libsmbd_base.so(+0x93169) [0x7f3cc690b169]
#19 /usr/lib64/libsmbconf.so.0(+0x3b107) [0x7f3cc620b107]
#20 /usr/lib64/libsmbconf.so.0(run_events_poll+0x115) [0x7f3cc620b7d5]
#21 /usr/lib64/libsmbconf.so.0(+0x3bef0) [0x7f3cc620bef0]
#22 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x39a320349d]
#23 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b)
[0x39a320351b]
#24 /usr/lib64/samba/libsmbd_base.so(start_background_queue+0x271)
[0x7f3cc690b4b1]
#25 /usr/lib64/samba/libsmbd_base.so(printing_subsystem_init+0xa3)
[0x7f3cc690b7a3]
#26 smbd(main+0x1175) [0x409b05]
#27 /lib64/libc.so.6(__libc_start_main+0xfd) [0x399961ed5d]
#28 smbd() [0x405459]
[2016/04/04 14:39:20.092147, 0] ../source3/lib/dumpcore.c:317(dump_core)
dumping core in /var/log/samba/cores/smbd
[2016/04/04 14:39:20.199910, 0]
../source3/printing/print_cups.c:516(cups_async_callback)
failed to recv pcap blob

------


Sorry, I'd have tried to trim that, but I don't know which parts
are important for y'all to see.

The other weird thing is, these core dumps are patterned. After I
start smbd, I get one immediately, and then I get one ~60 seconds later,
and then I get another one approximately every ~781 seconds.

-Sandro

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Andrew Bartlett]

On Mon, 2016-04-04 at 14:48 -0600, Ochressandro Rettinger wrote:
> Hi, sorry. I have spent about 4 hours googling, and had no
> luck.
> I'm getting repeat core dumps out of smbd, and nothing I've gotten
> from
> the log file has successfully pointed me at any indication that
> anyone
> else has posted about this problem before.
>
> ------
>
> libgcrypt selftest: binary (0): Selftest failed
> (/lib64/.libgcrypt.so.11.hmac)
> fatal error in libgcrypt, file visibility.c, line 1250, function
> gcry_create_nonce: called in non-operational state

This is very interesting. I think you are linking to an older version
of gnutls, perhaps upgrade your OS, as the newer versions use libnettle
and so perhaps that avoids the issue.

I don't normally suggest changing the OS to fix a Samba issue, but this
is a bid different:

What is happening here is that when we spawn a child to check the print
queues, that is failing to connect to your cups server over HTTPS
because of some issue inside gcrypt, use by gnutls, used by cups.

Otherwise, perhaps if CUPS is on the same host, avoid using SSL to talk
to it?

Thanks,

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba

[Ochressandro Rettinger]

On Tue, 5 Apr 2016, Andrew Bartlett wrote:

> On Mon, 2016-04-04 at 14:48 -0600, Ochressandro Rettinger wrote:
>> Hi, sorry. I have spent about 4 hours googling, and had no
>> luck.
>> I'm getting repeat core dumps out of smbd, and nothing I've gotten
>> from
>> the log file has successfully pointed me at any indication that
>> anyone
>> else has posted about this problem before.
>>
>> ------
>>
>> libgcrypt selftest: binary (0): Selftest failed
>> (/lib64/.libgcrypt.so.11.hmac)
>> fatal error in libgcrypt, file visibility.c, line 1250, function
>> gcry_create_nonce: called in non-operational state
>
> This is very interesting. I think you are linking to an older version
> of gnutls, perhaps upgrade your OS, as the newer versions use libnettle
> and so perhaps that avoids the issue.
>
> I don't normally suggest changing the OS to fix a Samba issue, but this
> is a bid different:
>
> What is happening here is that when we spawn a child to check the print
> queues, that is failing to connect to your cups server over HTTPS
> because of some issue inside gcrypt, use by gnutls, used by cups.
>
> Otherwise, perhaps if CUPS is on the same host, avoid using SSL to talk
> to it?

I've got the most updated version of RHEL running on that system.
So I'm not quite sure what I'd upgrade there. Unless it's RHEL itself
that's packaging an older version of gnutls.

I continued googling for answers after I wrote, and found a
suggestion that it might be related to FIPS mode, and indeed, when I turn
off FIPS mode on the OS, it stops doing this. But that's not really a
viable long term solution.

To be honest, I'm not sure why Samba is trying to connect to a
cups server at all, because I thought I had turned printing via Samba
*off*... Since I clearly haven't done that, how can I do that?

Thanks!

-Sandro

[Ochressandro Rettinger]

Ok, I found instructions on turning off the printers. Which seems
to have stopped my repeated core dump problem which is nice.

So is this a bug in cups or libgcrypt or samba or what?

[Andrew Bartlett]

If this is real RHEL, then use your subscription and file a bug against
libgcrypt in FIPS mode, and they can re-assign to samba if they think
we are providing an unreasonable environment for the library.

Andrew Bartlett

--
Andrew Bartlett

https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
https://catalyst.net.nz/services/samba

[Andrew Bartlett]

I would note that Samba is not compatible with FIPS mode, as a concept.
We use NTLM authentication, non-FIPS crypto and many other things that
just don't pass that set of requirements.

Of course, because we simply don't know about any FIPS mode switch, we
gladly offer non-complient services, and so you get into issues like
this that are just untested normally.

I hope this clarifies things as to why you are one of the first to
notice this.

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba