samba4 slow startup, shared libs?
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 21 | 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 StartEnd Type Open Ref GrpRef Name 1433498584.149249 04bec650 04bec691 exe 10 0 smbd 1433498584.149272 04c19b74e000 04c19bb6 rlib 0107 0 /usr/lib/libpthread.so.19.0 1433498584.149293 04c18f3df000 04c18f812000 rlib 075 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 The simpler programs in samba4 are also slower than expected to startup (smbclient --version takes 3-4 seconds) but I haven't identified others which are quite as bad as smbd yet.
Re: samba4 slow startup, shared libs?
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 21 | 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 StartEnd Type Open Ref GrpRef Name 1433498584.149249 04bec650 04bec691 exe 10 0 smbd 1433498584.149272 04c19b74e000 04c19bb6 rlib 0107 0 /usr/lib/libpthread.so.19.0 1433498584.149293 04c18f3df000 04c18f812000 rlib 075 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.
Re: [PATCH] FTP as an install method is no more
On 06/05/15 01:15, Raf Czlonka wrote: Hi all, I think I got the most obvious ones but there might still be other ones scattered among the web pages. I'm not entirely sure how does that leave the exact wording of 'ftp.html' in terms of Download via HTTP/FTP, etc. vs. Install via ... so I left it unchanged for now. yeah, there are a few other things to look at on that one, AND ftp.html is a generated file, so I haven't committed this yet (a little more than I can do before running off to work in the morning!). faq1.html and faq4.html, though, I've committed. There's also the text version of the FAQ ('faq/obsd-faq.txt') which I haven't updated as it seems to be generated from the HTML version so that needs to be done separately - it doesn't seem like this has been done for 5.7 release at all as there's an answer to What's new in OpenBSD 5.6? section with 5.6 changes (not just the actual question like below in the faq1.html). regenerated and committed, thanks! Nick. Regards, Raf Index: ftp.html === RCS file: /cvs/www/ftp.html,v retrieving revision 1.669 diff -u -p -r1.669 ftp.html --- ftp.html 11 May 2015 11:19:50 - 1.669 +++ ftp.html 5 Jun 2015 05:04:11 - @@ -64,7 +64,7 @@ upgrade your system very quickly. h3font color=#e0a name=mirrorsDownload via HTTP/FTP/a/font/h3 -OpenBSD can be also easily installed via HTTP or FTP. +OpenBSD can also be easily installed via HTTP. Typically you need a single small piece of boot media (e.g., a boot floppy) and then the rest of the files can be installed from a number of locations, including directly off the Internet. Index: faq/faq1.html === RCS file: /cvs/www/faq/faq1.html,v retrieving revision 1.147 diff -u -p -r1.147 faq1.html --- faq/faq1.html 25 May 2015 15:32:00 - 1.147 +++ faq/faq1.html 5 Jun 2015 05:04:11 - @@ -36,7 +36,7 @@ please, use a max of 72 chars per line - lia href=#WhoMaintains1.6 - Who maintains OpenBSD?/a lia href=#Next1.7 - When is the next release of OpenBSD?/a lia href=#Included1.8 - What is included with OpenBSD?/a -lia href=#WhatsNew1.9 - What is new in OpenBSD 5.6?/a +lia href=#WhatsNew1.9 - What is new in OpenBSD 5.7?/a lia href=#Desktop1.10 - Can I use OpenBSD as a desktop system?/a lia href=#HowAbout1.11 - Why is/isn't iProductX/i included?/a /ul Index: faq/faq4.html === RCS file: /cvs/www/faq/faq4.html,v retrieving revision 1.355 diff -u -p -r1.355 faq4.html --- faq/faq4.html 25 May 2015 15:32:00 - 1.355 +++ faq/faq4.html 5 Jun 2015 05:04:11 - @@ -235,7 +235,7 @@ You will want to know the following item liIf ISA, you also need to know hardware settings, and confirm they are as OpenBSD requires. /ul -liInstall method to be used (CD-ROM, FTP, etc.). +liInstall method to be used (CD-ROM, HTTP, etc.). liShould an important bug be found, how will the system be patched? ul liIf done locally, you will need to have @@ -1079,7 +1079,7 @@ Note that on slow hardware, the Get/Ver Installing xshare57.tgz 100% |**| 4413 KB00:05 Installing xfont57.tgz 100% |**| 38994 KB00:10 Installing xserv57.tgz 100% |**| 18469 KB00:06 - Location of sets? (cd disk ftp http or 'done') [done] biEnter/i/b + Location of sets? (cd disk http or 'done') [done] biEnter/i/b /pre/td/tr/table p @@ -3005,7 +3005,7 @@ Note: if you will be doing your install need to add your ttsite*.tgz/tt file(s) to the file ttindex.txt/tt in the source directory in order for them to be listed as an option at install time. -This is not needed for FTP or other installs. +This is not needed for other install methods. p a name=Multiple/a
Pflow export every X seconds
Hello, I'd love to see the feature Joerg Goltermann developed a while ago committed in the standard pflow : http://marc.info/?l=openbsd-miscm=124661838923498w=2 Do you know why it was never committed ? What would it need to be ? May I help in any way ? -- Cordialement, Pierre Bardou Ingénieur réseau 12, rue Michel Labrousse CS 93668 - 31036 Toulouse cedex 1 Avant d'imprimer cet e-mail, pensons à l'environnement
Re: RTF_LOCAL and permanent ARP
On Thu, Jun 04, 2015 at 12:19:10PM +0200, Martin Pieuchot wrote: I'd like to put the link-layer address back into the gateway field of RTF_LOCAL addresses. The problem is that RTF_LOCAL routes are also marked as RTF_LLINFO and a lot of code assume (correctly) that such routes contain valid ARP or ND information. I believe we decided to use an ``empty'' lladdr because previously all the routes created via rt_ifa_add(9) were using the same code and we needed the exact same gateway to remove MPATH routes. But now that only RTF_LOCAL routes use this code and taking into consideration that such route *cannot* be MPATH, we can simply use ifp-if_sadl instead of a blank sockaddr_dl. This should also fix the (imcomplete) output in arp(8) and ndp(8). Ok? If I see this correctly rt_ifa_del is now doing deletes without a gateway specified for the RTF_LLINFO flag is set. Are you sure that there will be never multipath routes in that case? Also do we need to set RTAX_LABEL on remove? I think that is not needed. This is unrelated and should be handled independently. Apart from that OK claudio@ Index: net/route.c === RCS file: /cvs/src/sys/net/route.c,v retrieving revision 1.212 diff -u -p -r1.212 route.c --- net/route.c 26 May 2015 12:19:51 - 1.212 +++ net/route.c 4 Jun 2015 10:03:51 - @@ -1121,27 +1121,23 @@ rt_maskedcopy(struct sockaddr *src, stru int rt_ifa_add(struct ifaddr *ifa, int flags, struct sockaddr *dst) { + struct ifnet*ifp = ifa-ifa_ifp; struct rtentry *rt, *nrt = NULL; struct sockaddr_rtlabel sa_rl; - struct sockaddr_dl sa_dl = { sizeof(sa_dl), AF_LINK }; struct rt_addrinfo info; - u_short rtableid = ifa-ifa_ifp-if_rdomain; - u_int8_t prio = ifa-ifa_ifp-if_priority + RTP_STATIC; + u_short rtableid = ifp-if_rdomain; + u_int8_t prio = ifp-if_priority + RTP_STATIC; int error; - sa_dl.sdl_type = ifa-ifa_ifp-if_type; - sa_dl.sdl_index = ifa-ifa_ifp-if_index; - memset(info, 0, sizeof(info)); info.rti_ifa = ifa; info.rti_flags = flags | RTF_MPATH; info.rti_info[RTAX_DST] = dst; if (flags RTF_LLINFO) - info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)sa_dl; + info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)ifp-if_sadl; else info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr; - info.rti_info[RTAX_LABEL] = - rtlabel_id2sa(ifa-ifa_ifp-if_rtlabelid, sa_rl); + info.rti_info[RTAX_LABEL] = rtlabel_id2sa(ifp-if_rtlabelid, sa_rl); #ifdef MPLS if ((flags RTF_MPLS) == RTF_MPLS) { @@ -1189,14 +1185,14 @@ rt_ifa_add(struct ifaddr *ifa, int flags int rt_ifa_del(struct ifaddr *ifa, int flags, struct sockaddr *dst) { + struct ifnet*ifp = ifa-ifa_ifp; struct rtentry *rt, *nrt = NULL; struct mbuf *m = NULL; struct sockaddr *deldst; struct rt_addrinfo info; struct sockaddr_rtlabel sa_rl; - struct sockaddr_dl sa_dl = { sizeof(sa_dl), AF_LINK }; - u_short rtableid = ifa-ifa_ifp-if_rdomain; - u_int8_t prio = ifa-ifa_ifp-if_priority + RTP_STATIC; + u_short rtableid = ifp-if_rdomain; + u_int8_t prio = ifp-if_priority + RTP_STATIC; int error; #ifdef MPLS @@ -1227,19 +1223,13 @@ rt_ifa_del(struct ifaddr *ifa, int flags } } - sa_dl.sdl_type = ifa-ifa_ifp-if_type; - sa_dl.sdl_index = ifa-ifa_ifp-if_index; - memset(info, 0, sizeof(info)); info.rti_ifa = ifa; info.rti_flags = flags; info.rti_info[RTAX_DST] = dst; - if (flags RTF_LLINFO) - info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)sa_dl; - else + if ((flags RTF_LLINFO) == 0) info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr; - info.rti_info[RTAX_LABEL] = - rtlabel_id2sa(ifa-ifa_ifp-if_rtlabelid, sa_rl); + info.rti_info[RTAX_LABEL] = rtlabel_id2sa(ifp-if_rtlabelid, sa_rl); if ((flags RTF_HOST) == 0) info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask; Index: netinet6/nd6.c === RCS file: /cvs/src/sys/netinet6/nd6.c,v retrieving revision 1.136 diff -u -p -r1.136 nd6.c --- netinet6/nd6.c15 May 2015 12:00:57 - 1.136 +++ netinet6/nd6.c4 Jun 2015 09:51:54 - @@ -651,7 +651,6 @@ nd6_lookup(struct in6_addr *addr6, int c } if (!rt) { if (create ifp) { - struct sockaddr_dl sa_dl = { sizeof(sa_dl), AF_LINK }; struct rt_addrinfo info;
Re: samba4 slow startup, shared libs?
On Fri, June 5, 2015 14: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 21 | 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 StartEnd Type Open Ref GrpRef Name 1433498584.149249 04bec650 04bec691 exe 10 0 smbd 1433498584.149272 04c19b74e000 04c19bb6 rlib 0107 0 /usr/lib/libpthread.so.19.0 1433498584.149293 04c18f3df000 04c18f812000 rlib 075 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. Vadim made an attempt to improve things. May be this can share some light. http://marc.info/?l=openbsd-portsm=140051145330799w=2 http://marc.info/?l=openbsd-portsm=140078438824316w=2 I've searched old mails and found that 4.0.3 was starting with normal speed. I have ldd output for 4.0.3 and 4.0.17 to compare.
LibreSSL 2.2 fails to connect to webdav.yandex.com
Hello, LibreSSL 2.2 (openbsd-current) fails to connect to https://webdav.yandex.com. OpenSSL 1.0.1m from OpenBSD packages does succeed. Yandex is the largest search engine in Russia. The webdav.yandex.com site is for accessing their file-hosting service. System info: $ uname -a OpenBSD roger.my.domain 5.7 GENERIC.MP#1039 amd64 $ dmesg | head -n 1 OpenBSD 5.7-current (GENERIC.MP) #1039: Wed Jun 3 12:09:31 MDT 2015 OpenSSL run: $ eopenssl version OpenSSL 1.0.1m 19 Mar 2015 $ echo -n | eopenssl s_client -debug -connect webdav.yandex.com:443 depth=1 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Level IV CA verify error:num=20:unable to get local issuer certificate verify return:0 CONNECTED(0003) write to 0xd6b51dc680 [0xd70e4f3000] (297 bytes = 297 (0x129)) - 16 03 01 01 24 01 00 01-20 03 03 8f 0d ed 87 39 $... ..9 0010 - 96 b6 31 ce a4 4a 01 e9-25 3a 03 96 75 54 60 d0 ..1..J..%:..uT`. 0020 - b9 9b 41 7a d1 af 6f 34-e7 bc 19 00 00 8a c0 30 ..Az..o4...0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.k 0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.2...* 0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f =.5.../ 0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.g 0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31 .@.3.2.E.D.1 0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%/ 0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05 ...A 00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a 00b0 - 00 15 00 12 00 09 00 ff-01 00 00 6d 00 0b 00 04 ...m 00c0 - 03 00 01 02 00 0a 00 34-00 32 00 0e 00 0d 00 19 ...4.2.. 00d0 - 00 0b 00 0c 00 18 00 09-00 0a 00 16 00 17 00 08 00e0 - 00 06 00 07 00 14 00 15-00 04 00 05 00 12 00 13 00f0 - 00 01 00 02 00 03 00 0f-00 10 00 11 00 23 00 00 .#.. 0100 - 00 0d 00 20 00 1e 06 01-06 02 06 03 05 01 05 02 ... 0110 - 05 03 04 01 04 02 04 03-03 01 03 02 03 03 02 01 0120 - 02 02 02 03 00 0f 00 01-01. read from 0xd6b51dc680 [0xd675564000] (7 bytes = 7 (0x7)) - 16 03 03 00 57 02 W. 0007 - SPACES/NULS read from 0xd6b51dc680 [0xd67556400a] (85 bytes = 85 (0x55)) - 00 53 03 03 55 72 4e 4e-f4 4b 58 3b 97 76 3a c0 .S..UrNN.KX;.v:. 0010 - 3a 70 e1 1e 7b d3 f7 51-39 c4 08 92 8b b0 d9 53 :p..{..Q9..S 0020 - 81 e4 b4 d8 20 0e 38 87-11 8b 29 e5 c3 05 e1 1f .8...). 0030 - 5b 5b 6f f6 a7 92 70 a5-ec 7c 28 80 ae 6b ba b0 [[o...p..|(..k.. 0040 - 6b 90 d5 b9 06 c0 14 00-00 0b 00 0b 00 02 01 00 k... 0050 - ff 01 00 01 0055 - SPACES/NULS read from 0xd6b51dc680 [0xd675564003] (5 bytes = 5 (0x5)) - 16 03 03 0a be. read from 0xd6b51dc680 [0xd675564008] (2750 bytes = 1393 (0x571)) - 0b 00 0a ba 00 0a b7 00-06 78 30 82 06 74 30 82 .x0..t0. 0010 - 05 5c a0 03 02 01 02 02-10 69 d8 9e b2 4a ed e3 .\...i...J.. 0020 - 01 8b dd 5e ae 9e d0 11-ea 30 0d 06 09 2a 86 48 ...^.0...*.H 0030 - 86 f7 0d 01 01 05 05 00-30 77 31 0b 30 09 06 03 0w1.0... 0040 - 55 04 06 13 02 50 4c 31-22 30 20 06 03 55 04 0a UPL10 ..U.. 0050 - 13 19 55 6e 69 7a 65 74-6f 20 54 65 63 68 6e 6f ..Unizeto Techno 0060 - 6c 6f 67 69 65 73 20 53-2e 41 2e 31 27 30 25 06 logies S.A.1'0%. 0070 - 03 55 04 0b 13 1e 43 65-72 74 75 6d 20 43 65 72 .UCertum Cer 0080 - 74 69 66 69 63 61 74 69-6f 6e 20 41 75 74 68 6f tification Autho 0090 - 72 69 74 79 31 1b 30 19-06 03 55 04 03 13 12 43 rity1.0...UC 00a0 - 65 72 74 75 6d 20 4c 65-76 65 6c 20 49 56 20 43 ertum Level IV C 00b0 - 41 30 1e 17 0d 31 34 31-31 31 37 31 32 31 34 31 A0...14111712141 00c0 - 39 5a 17 0d 31 35 31 32-33 31 31 32 31 34 31 39 9Z..151231121419 00d0 - 5a 30 81 9c 31 0b 30 09-06 03 55 04 06 13 02 52 Z0..1.0...UR 00e0 - 55 31 13 30 11 06 03 55-04 0a 0c 0a 59 61 6e 64 U1.0...UYand 00f0 - 65 78 20 4c 4c 43 31 0c-30 0a 06 03 55 04 0b 0c ex LLC1.0...U... 0100 - 03 49 54 4f 31 0f 30 0d-06 03 55 04 07 0c 06 4d .ITO1.0...UM 0110 - 6f 73 63 6f 77 31 1b 30-19 06 03 55 04 08 0c 12 oscow1.0...U 0120 - 52 75 73 73 69 61 6e 20-46 65 64 65 72 61 74 69 Russian Federati 0130 - 6f 6e 31 19 30 17 06 03-55 04 03 0c 10 77 65 62 on1.0...Uweb 0140 - 64 61 76 2e 79 61 6e 64-65 78 2e 72 75 31 21 30 dav.yandex.ru1!0 0150 - 1f 06 09 2a 86 48 86 f7-0d 01 09 01 16 12 70 6b ...*.Hpk 0160 - 69 40 79 61 6e 64 65 78-2d 74 65 61 6d 2e 72 75 i...@yandex-team.ru 0170 - 30 82 01 22 30 0d 06 09-2a 86 48 86 f7 0d 01 01 0..0...*.H. 0180 - 01 05 00 03 82 01 0f 00-30 82 01 0a 02 82 01 01