samba - Aug 2022 - Problem with SO_REUSEPORT in samba v4.16 No problem in v4.14

Hi Samba folks,

I am having a problem cross compiling samba 4.15.5 with glibc version 2.11 . I
acknowledge that this is a very old version of glibc however my target platform
uses this version. There was no problem cross compiling samba 4.14.12.

The issue seems to be with newly introduced source file
"source3/printing/samba-bgqd.c"

../../source3/printing/samba-bgqd.c: In function ?main?:
../../source3/printing/samba-bgqd.c:340:28: error: ?SIGPIPE? undeclared (first
use in this function); did you mean ?SNDPIPE??
  340 |         BlockSignals(true, SIGPIPE);
      |                            ^~~~~~~
      |                            SNDPIPE
../../source3/printing/samba-bgqd.c:340:28: note: each undeclared identifier is
reported only once for each function it appears in
In file included from ../../source3/locking/share_mode_lock.h:20,
                 from ../../source3/printing/samba-bgqd.c:21:
../../source3/printing/samba-bgqd.c:384:28: error: ?SIGTERM? undeclared (first
use in this function)
  384 |                 ev, frame, SIGTERM, 0, bgqd_sig_term_handler,
&done);
      |                            ^~~~~~~
../../lib/tevent/tevent.h:412:41: note: in definition of macro
?tevent_add_signal?
  412 |         _tevent_add_signal(ev, mem_ctx, signum, sa_flags, handler,
private_data, \
      |                                         ^~~~~~

The problem can be fixed by adding the following include directive to
samba-bgqd.c

    #include <signal.h>

The issue arises from /usr/include/sys/param.h in glibc 2.11 not containing an
"#include <signal.h> " statement like modern glibc versions do.

Do you think that if I raised a samba bug that there'd be any hope of
getting this include statement added to samba-bgqd.c ? Can anyone suggest
something else that might be more elegant to resolve this issue with compiling
samba using glibc 2.11?

Thanks very much!

Berto.

On Mon, 2022-03-14 at 10:29 +1100, Berto Furth via samba
wrote:
> 
> Do you think that if I raised a samba bug that there'd be any hope of
> getting this include statement added to samba-bgqd.c ? Can anyone
> suggest something else that might be more elegant to resolve this
> issue with compiling samba using glibc 2.11?
As a general rule, we don't include any system headers in our main C
files, we have headers in lib/replace that we include, so either
include the 'right' header from there or put the extra include, guarded
appropriately in a header there.

Then raise a MR I guess: https://wiki.samba.org/index.php/Contribute

Andrew,

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions

Hi Samba folks,

I have having a problem running samba v4.16.4 on my very old Linux system
running kernel v2.6.35. I had no problems with version samba v4.14.6. I am
getting the following error messages in my logs

../../source3/lib/util_sock.c:294(open_socket_in)  open_socket_in:
setsockopt(SO_REUSEPORT) failed: Protocol not available
../../source3/smbd/server.c:1097(smbd_open_one_socket)  smbd_open_one_socket:
open_socket_in failed: Protocol not available
../../source3/smbd/server.c:1264(open_sockets_smbd)  open_sockets_smbd: No
sockets available to bind to.
INTERNAL ERROR: open_sockets_smbd() failed in pid 12523 (4.16.3)


The issue appears to be that in earlier versions of smbd, if the SO_REUSEPORT
socket option could not be set then a debug message was printed but the code
would continue on. My system runs Linux v2.6.35 which does not support
SO_REUSEPORT (introduced in Linux v3.3)

I believe the behavior was changed in the following commit 

lib: Properly return errno from open_socket_in()" (Commit :
72540222c2290dc041fb01018de7febe44a4ac0d )
https://git.samba.org/?p=samba.git;a=commitdiff;h=72540222c2290dc041fb01018de7febe44a4ac0d

After this commit if setting SO_REUSEPORT fails then the socket would not be
setup.

If I were to raise a bug asking for the old behavior back do you think it would
be fixed?

Thanks so much,

Berto.