On 2015/06/05 13:27, Mark Kettenis wrote: > > Date: Fri, 5 Jun 2015 11:15:38 +0100 > > From: Stuart Henderson <st...@openbsd.org> > > > > net/samba4 is in the ports tree but not currently enabled in the build, > > we're still only using samba 3.x for various reasons, but unfortunately > > samba 3 is getting decreasingly useful as more Windows setups move to > > newer versions. > > > > One of the issues is that startup of samba4 on OpenBSD is very slow > > indeed, seemingly before control is transferred to the program. From > > the LD_DEBUG output with timestamps (using the very handy ts(1) from > > "moreutils"): > > > > # LD_DEBUG=1 smbd -D 2>&1 | ts %.s > > <..snip..> > > 1433498513.546306 examining: '/usr/local/lib/libhogweed.so.1.1' > > 1433498513.546323 loading: libnettle.so.1.2 required by > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546339 loading: libgmp.so.9.0 required by > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546354 linking dep /usr/local/lib/libnettle.so.1.2 as child of > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546370 linking dep /usr/local/lib/libgmp.so.9.0 as child of > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546386 examining: '/usr/local/lib/libgmp.so.9.0' > > 1433498584.125659 flags /usr/libexec/ld.so = 0x0 > > 1433498584.125783 obj /usr/libexec/ld.so has smbd as head > > 1433498584.149165 relocation took 0.023504 > > 1433498584.149215 Start End Type Open Ref > > GrpRef Name > > 1433498584.149249 000004bec6500000 000004bec6910000 exe 1 0 0 > > smbd > > 1433498584.149272 000004c19b74e000 000004c19bb60000 rlib 0 107 0 > > /usr/lib/libpthread.so.19.0 > > 1433498584.149293 000004c18f3df000 000004c18f812000 rlib 0 75 0 > > /usr/local/lib/libsamba-util.so.0.0 > > <..snip..> > > > > - a 74 second delay after "examining: '/usr/local/lib/libgmp.so.9.0'". > > Does anyone have suggestions for finding out what's going on here? > > Full text snipped from the above is at > > http://junkpile.org/samba4-lddebug.txt > > My first guess would have been that it is spending a lot of time on > initial relocations. But the line: > > 1433498584.149165 relocation took 0.023504 > > pretty much rules that out. My suggestion would be to add a few more > DL_DEB() statements inside of ld.so/loader.c:_dl_boot(), starting just > after the _dl_load_dep_libs() call in that function and try to narrow > it down. >
The part taking the biggest chunk of time is _dl_cache_grpsym_list() with its recursive calls (64 seconds). 1433936487.139917 _dl_cache_grpsym_list: 1433936551.414114 _dl_cache_grpsym_list:done ctors for libpthread are fairly slow too (35 seconds) but I think that's out of ld.so's hands. ... 1433936551.538493 _dl_debug_state done 1433936551.538508 doing ctors obj 0x138a43269400 @0x138a74fe0ca0: [/usr/lib/libpthread.so.19.0] 1433936587.157910 doing ctors obj 0x138ae5e30800 @0x138af0447f80: [/usr/local/lib/samba/libreplace.so.0.0] ...
