--==========C0CB1C4A269A2DB8FD87========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li To: Quanah Gibson-Mount Hi Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========C0CB1C4A269A2DB8FD87========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD (fwd)" Date: Tue, 24 Apr 2018 14:28:57 -0700 From: Quanah Gibson-Mount <quanah(a)symas.com&gt; Reply-To: Quanah Gibson-Mount <quanah(a)symas.com&gt; To: Howard Chu <hyc(a)symas.com&gt; Subject: Re: kqueue in OpenLDAP for FreeBSD (fwd) Message-ID: <49431EE1A7D095C608D778A4(a)[192.168.1.10]&gt; X-Mailer: Mulberry/4.0.9a1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========EF6328C82A1CE901E152==========" --==========EF6328C82A1CE901E152========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline kqueue issues with slapd --Quanah ------------ Forwarded Message ------------ Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li <delphij(a)delphij.net&gt; To: Quanah Gibson-Mount <quanah(a)symas.com&gt;, Xin LI <delphij(a)gmail.com&gt; Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch&gt;, Xin LI=20 <delphij(a)freebsd.org&gt; Subject: Re: kqueue in OpenLDAP for FreeBSD Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: to as --disable-dependency-tracking \ of ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========EF6328C82A1CE901E152========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD" Return-Path: delphij(a)delphij.net Received: from 127.37.197.104.bc.googleusercontent.com (LHLO zmcc-5-mta-1.zmailcloud.com) (104.197.37.127) by zmcc-5-mailbox-1.zmailcloud.com with LMTP; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 57E10C0814 for <qgibson-mount(a)symas.com&gt;; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Authentication-Results: zmcc-5-mta-1.zmailcloud.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=delphij.net Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wrlpf0yr3bg2 for <qgibson-mount(a)symas.com&gt;; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (254.215.154.104.bc.googleusercontent.com [104.154.215.254]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 36497C06D2 for <quanah(a)symas.com&gt;; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (localhost.localdomain [127.0.0.1]) by mailstronghold-1.zmailcloud.com (8.13.8/8.13.8) with ESMTP id v9N4CeHI010656 for <quanah(a)symas.com&gt;; Mon, 23 Oct 2017 01:43:18 -0500 X-Haraka-RcptSummary: valid=1 invalid=0 unverified=0 relay=0 norelay=0 Received-SPF: Pass (mailstronghold-1.zmailcloud.com: domain of delphij.net designates 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=mailfrom; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=&lt;delphij(a)delphij.net&gt; Received-SPF: None (mailstronghold-1.zmailcloud.com: domain of anubis.delphij.net does not designate 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=helo; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=&lt;delphij(a)delphij.net&gt; Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mailstronghold-1.zmailcloud.com (Haraka/2.2.8) with ESMTPS id 44429DF9-9A11-41FD-AF40-A85A1E9CCAE7.1 envelope-from <delphij(a)delphij.net&gt; (version=TLSv1/SSLv3 cipher=AES256-SHA verify=OK); Mon, 23 Oct 2017 01:43:14 -0500 Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:37a:c09f:c4b5:916b:f99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 7315321847; Sun, 22 Oct 2017 23:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1508740990; x=1508755390; bh=lHOLEU7RrRbdsqZiIrERFdjtGcmjK0d4J65y4NciNAE=; h=Cc:Subject:To:References:From:Date:In-Reply-To; b=pSf21voW+1hi95e1Gk7n0Etfo4WpoqUlF4m7Ukgp6+Sw1OreGQEjQPiBMq0Wo6htG P/+uPZswNtPxpr/6yGE9Fsrxku8Bygk6Qv/o3pR9rRe0bKhvrh+jqAcM0KvcjgG9cV geciuENhFuihiQm9Jh/4383kqyrcrgnufON8XY4Q= Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch&gt;, Xin LI <delphij(a)freebsd.org&gt; Subject: Re: kqueue in OpenLDAP for FreeBSD To: Quanah Gibson-Mount <quanah(a)symas.com&gt;, Xin LI <delphij(a)gmail.com&gt; From: Xin Li <delphij(a)delphij.net&gt; Date: Sun, 22 Oct 2017 23:43:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]&gt; Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ" X-Haraka-Syntax: mail_case=upper mail_leading_spaces=N mail_trailing_spaces=N mail_missing_brackets=N rcpt_case=upper rcpt_leading_spaces=N rcpt_missing_brackets=N rcpt_trailing_spaces=N X-Haraka-GeoIP: US X-Haraka-GeoIP-Received: 64.62.153.212:US X-Haraka-rDNS: anubis.delphij.net X-Haraka-FCrDNS: anubis.delphij.net X-Haraka-HostID: delphij.net X-Haraka-SenderAuth: 64.62.153.212 delphij.net X-Haraka-Domain-Info: domain="delphij.net" last_update=176 primary_ns="ns-us.delphij.net" serial=2017043060 refresh=7200 retry=3600 expiration=604800 minimum=14400 flags="" X-Haraka-Watermark: references:WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!@mailstronghold-3.zmailcloud.com References: <1EEAC653239F6692643DB632(a)192.168.1.30&gt; <058DB23288D5009E6DBB5BCD(a)192.168.1.30&gt; <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com&gt; <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com&gt; <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30&gt; <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com&gt; <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com&gt; <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]&gt; <D8979E6E67B623588F99E3B7(a)[192.168.1.30]&gt; <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net&gt; <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com&gt; <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]&gt; <77291973D4E980CDD2C6B12D(a)[192.168.1.30]&gt; <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net&gt; Message-Id: <WM!ff18dbc4fd0ca98069f4da171165aabfe0351a19a07c5c098b191f5850c1c079bf8b820779722c14189597ab2ab2028a!(a)mailstronghold-1.zmailcloud.com&gt; X-FSL-MailScanner-Information: Please contact postmaster(a)zmailcloud.com for more information X-FSL-MailScanner-ID: v9N4CeHI010656 X-FSL-MailScanner: Found to be clean X-Dirty-Status: X-FSL-MailScanner-From: delphij(a)delphij.net This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: multipart/mixed; boundary="SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl"; protected-headers="v1" From: Xin Li <delphij(a)delphij.net&gt; To: Quanah Gibson-Mount <quanah(a)symas.com&gt;, Xin LI <delphij(a)gmail.com&gt; Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch&gt;, Xin LI <delphij(a)freebsd.org&gt; Message-ID: <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net&gt; Subject: Re: kqueue in OpenLDAP for FreeBSD References: <1EEAC653239F6692643DB632(a)192.168.1.30&gt; <WM!652ba1f610b07a3646a24508aa83d70e7fbfbbbf4a02ab2f4f5c75bea4ea7433084f5a08cbd2551d01ebcc1be8bfada2!(a)mailstronghold-3.zmailcloud.com&gt; <806290B685E4C0A58E186335(a)192.168.1.30&gt; <a77bd491-68e1-d071-90d1-f081685137cd(a)delphij.net&gt; <WM!9301149f169acc8af0f3fbefd6be96ab8874fd401aaf6373e9390d058b5fc3a788bd3202b6db71ad2dcfda2aec5e5b59!(a)mailstronghold-3.zmailcloud.com&gt; <058DB23288D5009E6DBB5BCD(a)192.168.1.30&gt; <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com&gt; <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com&gt; <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30&gt; <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com&gt; <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com&gt; <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]&gt; <D8979E6E67B623588F99E3B7(a)[192.168.1.30]&gt; <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net&gt; <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com&gt; <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]&gt; <77291973D4E980CDD2C6B12D(a)[192.168.1.30]&gt; In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]&gt; --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl Content-Type: multipart/mixed; boundary="------------617F49AD045D5D9CF20DDEA9" Content-Language: en-US This is a multi-part message in MIME format. --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's= descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, et= c. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: to as tracking \ of --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="slapd-workaround.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd-workaround.patch" ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvbWFpbi5jIGIvc2VydmVycy9zbGFwZC9tYWlu LmMKaW5kZXggMGEwNTNjM2VlLi4xOGQ4NDBjNWEgMTAwNjQ0Ci0tLSBhL3NlcnZlcnMvc2xh cGQvbWFpbi5jCisrKyBiL3NlcnZlcnMvc2xhcGQvbWFpbi5jCkBAIC02OTIsNiArNjkyLDkg QEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJYmVyX3NldF9vcHRpb24oTlVMTCwgTEJFUl9PUFRf REVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGFwX3NldF9vcHRpb24oTlVMTCwgTERB UF9PUFRfREVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGlmX2RlYnVnID0gc2xhcF9k ZWJ1ZzsKKwlpZiAoIGNoZWNrICE9IENIRUNLX05PTkUgKSB7CisJCW5vX2RldGFjaCA9IDE7 CisJfQogCiAJaWYgKCB2ZXJzaW9uICkgewogCQlmcHJpbnRmKCBzdGRlcnIsICIlc1xuIiwg VmVyc2lvbnN0ciApOwpAQCAtNzM5LDYgKzc0MiwyOSBAQCB1bmhhbmRsZWRfb3B0aW9uOjsK IAlnbG9iYWxfaG9zdCA9IGxkYXBfcHZ0X2dldF9mcWRuKCBOVUxMICk7CiAJYmVyX3N0cjJi diggZ2xvYmFsX2hvc3QsIDAsIDAsICZnbG9iYWxfaG9zdF9idiApOwogCisjaWZuZGVmIEhB VkVfV0lOU09DSworCWlmICggIW5vX2RldGFjaCApIHsKKwkJaWYgKCBsdXRpbF9wYWlyKCB3 YWl0ZmRzICkgPCAwICkgeworCQkJRGVidWcoIExEQVBfREVCVUdfQU5ZLAorCQkJCSJtYWlu OiBsdXRpbF9wYWlyIGZhaWxlZDogJWRcbiIsCisJCQkJMCwgMCwgMCApOworCQkJcmMgPSAx OworCQkJZ290byBkZXN0cm95OworCQl9CisJCXBpZCA9IGx1dGlsX2RldGFjaCggbm9fZGV0 YWNoLCAwICk7CisJCWlmICggcGlkICkgeworCQkJY2hhciBidWZbNF07CisJCQlyYyA9IEVY SVRfU1VDQ0VTUzsKKwkJCWNsb3NlKCB3YWl0ZmRzWzFdICk7CisJCQlpZiAoIHJlYWQoIHdh aXRmZHNbMF0sIGJ1ZiwgMSApICE9IDEgKQorCQkJCXJjID0gRVhJVF9GQUlMVVJFOworCQkJ X2V4aXQoIHJjICk7CisJCX0gZWxzZSB7CisJCQljbG9zZSggd2FpdGZkc1swXSApOworCQl9 CisJfQorI2VuZGlmIC8qIEhBVkVfV0lOU09DSyAqLworCiAJaWYoIGNoZWNrID09IENIRUNL X05PTkUgJiYgc2xhcGRfZGFlbW9uX2luaXQoIHVybHMgKSAhPSAwICkgewogCQlyYyA9IDE7 CiAJCVNFUlZJQ0VfRVhJVCggRVJST1JfU0VSVklDRV9TUEVDSUZJQ19FUlJPUiwgMTYgKTsK QEAgLTkxMSwyOSArOTM3LDYgQEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJKHZvaWQpIFNJR05B TCggU0lHQlJFQUssIHNsYXBfc2lnX3NodXRkb3duICk7CiAjZW5kaWYKIAotI2lmbmRlZiBI QVZFX1dJTlNPQ0sKLQlpZiAoICFub19kZXRhY2ggKSB7Ci0JCWlmICggbHV0aWxfcGFpcigg d2FpdGZkcyApIDwgMCApIHsKLQkJCURlYnVnKCBMREFQX0RFQlVHX0FOWSwKLQkJCQkibWFp bjogbHV0aWxfcGFpciBmYWlsZWQ6ICVkXG4iLAotCQkJCTAsIDAsIDAgKTsKLQkJCXJjID0g MTsKLQkJCWdvdG8gZGVzdHJveTsKLQkJfQotCQlwaWQgPSBsdXRpbF9kZXRhY2goIG5vX2Rl dGFjaCwgMCApOwotCQlpZiAoIHBpZCApIHsKLQkJCWNoYXIgYnVmWzRdOwotCQkJcmMgPSBF WElUX1NVQ0NFU1M7Ci0JCQljbG9zZSggd2FpdGZkc1sxXSApOwotCQkJaWYgKCByZWFkKCB3 YWl0ZmRzWzBdLCBidWYsIDEgKSAhPSAxICkKLQkJCQlyYyA9IEVYSVRfRkFJTFVSRTsKLQkJ CV9leGl0KCByYyApOwotCQl9IGVsc2UgewotCQkJY2xvc2UoIHdhaXRmZHNbMF0gKTsKLQkJ fQotCX0KLSNlbmRpZiAvKiBIQVZFX1dJTlNPQ0sgKi8KLQogI2lmZGVmIENTUklNQUxMT0MK IAltYWxfbGVha3RyYWNlKDEpOwogI2VuZGlmCg== --------------617F49AD045D5D9CF20DDEA9-- --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl-- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ-- --==========EF6328C82A1CE901E152==========-- --==========C0CB1C4A269A2DB8FD87==========--