Bug 11355 - Samba daemons and utils extremely slow to startup on OpenBSD
Samba daemons and utils extremely slow to startup on OpenBSD
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Build
unspecified
All OpenBSD
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-06-23 00:59 UTC by Ian McWilliam
Modified: 2015-10-19 08:19 UTC (History)
4 users (show)

See Also:
slow: review+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian McWilliam 2015-06-23 00:59:19 UTC
Some where in the Samba 4.0.x line after 4.0.3 samba 4 on OpenBSD became unusable
as all of the samba daemons and command line tools took extremely long times to start up.

This change was seen.

 --- samba-4.0.3/wscript       Tue Dec  4 21:07:44 2012
 +++ samba-4.0.26/wscript      Mon Dec  8 18:46:38 2014


 -    if sys.platform != "openbsd4":
 +    if not sys.platform.startswith("openbsd"):
          conf.env.asneeded_ldflags = conf.ADD_LDFLAGS('-Wl,--as-needed', testflags=True)


We would like it if you could remove the following line on all samba 4.1.x and 4.2.x versions.

if not sys.platform.startswith("openbsd"):

so the linker can use the --as-needed


Output of LD_DEBUG=1 time samba-tool:

==> before <==
doing dtors obj 0x76bdc238000 @0x76c004b0a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0x76bb7b3b000 @0x76bfbc6e740: [/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0x76bb7b3b800 @0x76b8c3331b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0x76c1ede3400 @0x76bbadbc950: [/usr/lib/libc.so.79.0]
doing dtors obj 0x76c1ede3000 @0x76c333c5a40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0x76bdc238800 @0x76c0159b340: [/usr/lib/libm.so.9.0]
      251.92 real       251.96 user         0.19 sys
doing dtors
 doing dtors obj 0xf0ae0f94c00 @0xf0b5ec96950: [/usr/lib/libc.so.79.0]

==> after <==
doing dtors obj 0xa6021425000 @0xa60bf833a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0xa6021425800 @0xa603fca0740: [/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0xa6034d7e800 @0xa60c0c911b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0xa60a5bcf400 @0xa604a3e0950: [/usr/lib/libc.so.79.0]
doing dtors obj 0xa60a5bcf000 @0xa60eb3eba40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0xa6021425400 @0xa610ba86340: [/usr/lib/libm.so.9.0]
        1.49 real         1.24 user         0.22 sys
doing dtors
doing dtors obj 0x4e7a8e11c00 @0x4e767f81950: [/usr/lib/libc.so.79.0]


Thanks
Comment 1 Björn Jacke 2015-07-02 09:34:14 UTC
The OpenBSD strict linking exception was introduced by Matthieu in 61d9aa5a3e899d4dfea7bff054837b0b3907fa75

So Matthieu, can you have a look at this bug report here, which wants the strict linking rules back? :-)
Comment 2 Jérémie Courrèges-Anglas 2015-09-01 18:48:09 UTC
I can confirm that Samba4 is unusable without as-needed.  as-needed was unsafe until recently (we upgraded the binutils version we used), but it is now usable.  We removed the test about OpenBSD in our ports tree:

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/net/samba/patches/patch-wscript?rev=1.1&content-type=text/plain
 
Gotta perform test about no-undefined though.
Comment 3 Björn Jacke 2015-09-02 11:27:45 UTC
(In reply to Jérémie Courrèges-Anglas from comment #2)
> I can confirm that Samba4 is unusable without as-needed

OpenBSD also still has the NGROUPS_MAX limit of 16, right? IMHO this makes Samba quite unusable on that platform anyway.

But a start time of 251.92s is ridiculous in any case but this one looks like a performance bug that the OpenBSD developers should try to fix. A performance penalty of that dimension just becasue there are superfluous libs linked in is crazy - especially given that OpenBSD didn't care about making the as-needed linker option usable till some days ago.

In any case, would be good you provide a patch that checks for the sanity of the as-needed on OpenBSD that uses this when appropriate
Comment 4 Jérémie Courrèges-Anglas 2015-09-02 12:00:04 UTC
(In reply to Björn Jacke from comment #3)
> OpenBSD also still has the NGROUPS_MAX limit of 16, right? IMHO this makes Samba quite unusable on that platform anyway.

Samba is quite usable on OpenBSD right now, even if it can't support setups you may be used to. AFAIK, nobody hit/reported the NGROUPS_MAX limit with Samba so far.  Also, if NGROUPS_MAX proves to be too low, we can bump it.  

> But a start time of 251.92s is ridiculous in any case but this one looks like a performance bug that the OpenBSD developers should try to fix. A performance penalty of that dimension just becasue there are superfluous libs linked in is crazy - especially given that OpenBSD didn't care about making the as-needed linker option usable till some days ago.

It agree that it is ridiculous but very few other OpenBSD ports have such an enormous number of libraries and inter-libs references involved. :)

> In any case, would be good you provide a patch that checks for the sanity of the as-needed on OpenBSD that uses this when appropriate

Sorry but this won't happen.  Testing for binutils corner cases doesn't sound like a pleasant task. Please trust that as-needed works on OpenBSD.  If it doesn't we'll fix it.
Comment 5 Volker Lendecke 2015-09-02 12:41:32 UTC
(In reply to Jérémie Courrèges-Anglas from comment #4)

Maybe the reason why nobody noticed NGROUPS_MAX is that OpenBSD can't run winbind in AD due to the lack of nsswitch.

I considered to write a NIS server into winbind to make it work on OpenBSD, join the local "NIS domain". Question: Would NIS be considered a supported OpenBSD feature, so is it worth putting effort into it?
Comment 6 Björn Jacke 2015-09-02 13:13:22 UTC
(In reply to Jérémie Courrèges-Anglas from comment #4)
>Samba is quite usable on OpenBSD right now, even if it can't support setups you >may be used to. AFAIK, nobody hit/reported the NGROUPS_MAX limit with Samba so >far.  Also, if NGROUPS_MAX proves to be too low, we can bump it.  

that would be awesome. Let me know when I need to update
https://www.j3e.de/ngroups.html then :-). The new NGROUPS_MAX limit that FreeBSD 8.0 introduced would be a good start.


>Sorry but this won't happen.  Testing for binutils corner cases doesn't sound >like a pleasant task. Please trust that as-needed works on OpenBSD.  If it >doesn't we'll fix it.

okay, maybe we might just do that...
Comment 7 Jérémie Courrèges-Anglas 2015-09-02 17:29:49 UTC
(In reply to Björn Jacke from comment #6)
> The new NGROUPS_MAX limit that FreeBSD 8.0 introduced would be a good start.

Thanks for the link. I think the issue was already discussed internally to the project.  Pushing those boundaries are an interesting goal but IMO we have bigger problems to tackle first.


Regarding the special treatment of linker flags on OpenBSD: --as-needed can safely go away.  I would like to make tests for the other flags concerned by OpenBSD-specific tests.  I only tested 4.1.20 on amd64 so far.
Comment 8 Jérémie Courrèges-Anglas 2015-09-02 17:41:01 UTC
(In reply to Volker Lendecke from comment #5)
> Maybe the reason why nobody noticed NGROUPS_MAX is that OpenBSD can't
> run winbind in AD due to the lack of nsswitch.

We don't support nsswitch, indeed.  We package winbind for external software that might want to use it (eg dovecot, squid).  I don't think this is specific to AD mode.

> I considered to write a NIS server into winbind to make it work on
> OpenBSD, join the local "NIS domain". Question: Would NIS be considered
> a supported OpenBSD feature, so is it worth putting effort into it?

I have no idea, really.  You might be aware that we "support" LDAP auth using ypldap which is similar to your proposal, but I don't know people that are using it right now.  I don't know about the future of such NIS bridges in OpenBSD. The idea is probably the only thing that could work right now, though. Thanks for bringing this up.
Comment 9 Ian McWilliam 2015-09-08 02:04:43 UTC
(In reply to Jérémie Courrèges-Anglas from comment #7)

That should read - The check for openbsd to not include as-needed should go away. We require the linker flag to help resolve the slow startup times.
Comment 10 Ian McWilliam 2015-09-08 02:16:20 UTC
(In reply to Björn Jacke from comment #3)

> In any case, would be good you provide a patch that checks for the sanity of the as-needed on OpenBSD that uses this when appropriate

Currently the working Samba on OpenBSD (even the forthcoming 5.8 release) is Samba 3.6.15 + back ported security fixes where is was not an issue. I therefore don't see the need for the sanity check, just the removal of the test for OpenBSD. Moving forward, OpenBSD supports as-needed and even if individuals try compile samba 4 on older releases, then Samba 4 is unlikely to work due to lots of other factors that have been resolved in the OpenBSD ports tree version of Samba 4.
Comment 11 Björn Jacke 2015-09-11 10:33:59 UTC
this is fixed in master with b0f41c07ffe8600433c20a038b1612c04ed29e89

Ralf: can you review+ for the cherry-pick to the release branches?
Comment 12 Jérémie Courrèges-Anglas 2015-09-11 11:32:06 UTC
Great, thanks.
Comment 13 Karolin Seeger 2015-09-15 09:05:14 UTC
(In reply to Björn Jacke from comment #11)
Pushed to autobuild-v4-[3|2]-test.

Next time, please attach the patches for each branch to the bug report and explicitly add review flags for each version. Thanks!
Comment 14 Karolin Seeger 2015-09-25 13:41:12 UTC
(In reply to Karolin Seeger from comment #13)
Is this an issue in 4.1 as well?
I was asked privately to backport...
Comment 15 Ralph Böhme 2015-09-25 14:36:42 UTC
Well, yes I guess.
Comment 16 Jérémie Courrèges-Anglas 2015-09-25 14:54:48 UTC
(In reply to Ralph Böhme from comment #15)
> Well, yes I guess.

That is true.  The OpenBSD port is at 4.1.20 right now, thus it is affected (I have a local patch in our CVS repo).  However I see no reason for anyone to run upstream samba-4.1.X on OpenBSD, so I did not ask for a backport to 4.1 which is maintenance mode.

It would allow me to remove one local patch among 26 other patches, so it is not very high priority for me. :)
Comment 17 Karolin Seeger 2015-10-19 08:19:06 UTC
(In reply to Jérémie Courrèges-Anglas from comment #16)
Thanks for your feedback, it's much appreciated!

Closing out bug report.
4.1 is in the security fixes only mode now.

Thanks!