From owner-freebsd-net@freebsd.org Tue Jun 16 18:09:42 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C3640346614 for ; Tue, 16 Jun 2020 18:09:42 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49mbnf2M4Wz4TRD for ; Tue, 16 Jun 2020 18:09:42 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mailman.nyi.freebsd.org (Postfix) id 20C5E3460F3; Tue, 16 Jun 2020 18:09:40 +0000 (UTC) Delivered-To: net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FF453460F2 for ; Tue, 16 Jun 2020 18:09:40 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "mail.evolve.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49mbnZ3yZ1z4TKf; Tue, 16 Jun 2020 18:09:37 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 5daa7dcc; Tue, 16 Jun 2020 18:09:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=date:from:to:cc :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=20180501; bh=LDGYzvTg uC0ygJiM+f45mBWEdx4=; b=mi3PNqc9RyAjpR1heXrmoujfL0QqlQiAX4wHF5uD +OIvS227LUDdVqwoeRvkEU7ve7JChs44mN4gRHXZjBEAARHpXEwWSUMMa4FLJLCP +oofbabBon8BOzQIdo16zQpAmugOF1RjXH0KeaDB2mAzLmM/9TUN8a28bZKbcJv2 IFz6tcTxNgEipxXctXglQ2832TwwkqR0UB5+jIcqkYXskYfj/Qx2NYby25hnZPVl pLm6Ce918PQ8kWfos4gYCXd4xwpCs+b2s1qVc5cLfzDVq6ST3iSCzX0xuILyuJ8G /8+sFiBeG2nyVFifciKbeFSri+pqzI2BZ5SnLzVgFs4uJw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=date:from:to:cc :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=20180501; b=N1 EM4+YJA2Zria66EIXnTGTQFB7+HbF9nUAGaWG0QkdXSRVTd4A44DzJoIVbZD0G98 c8FXz0nvWwhJ/7J1iyrDwUqXu1KVYcTOZwWbQc+H9FrbNn7UtKPreQZvxDlixT3X Dv9reac+LOo3GGXWe+sY+o8t/r7DPJXseErMrmJmQMV6j0hj4INuRy52dAUWk4ip 8Y4Mmh3iybJFKdy2+PTO1c9wqXFRHezU8Dp05BJiUEq7w79tUA6TAEQ3R6ry1dQI w2qB+elyzJbT8TOQ7pw26FFbZZzz1+/BWnmzYY4I/8hdVe6HrV7/jHm4L55bLQGn aqPNmobDtpoQbBNsxyOQ== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 704cb588 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO); Tue, 16 Jun 2020 18:09:35 +0000 (UTC) Date: Tue, 16 Jun 2020 20:09:18 +0200 From: Michael Gmelin To: Ryan Steinmetz Cc: "Rodney W. Grimes" , Jaap Akkerhuis , Andriy Gapon , net@freebsd.org Subject: Re: unbound and (isc) dhcpd startup order Message-ID: <20200616200918.33355616@bsd64.grem.de> In-Reply-To: <20200616163619.GA87881@exodus.zi0r.com> References: <202006151435.05FEZBKs045916@bela.nlnetlabs.nl> <202006161514.05GFEHao081218@gndrsh.dnsmgr.net> <20200616163619.GA87881@exodus.zi0r.com> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49mbnZ3yZ1z4TKf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=grem.de header.s=20180501 header.b=mi3PNqc9; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@grem.de designates 213.239.217.29 as permitted sender) smtp.mailfrom=freebsd@grem.de X-Spamd-Result: default: False [-3.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[grem.de:s=20180501]; NEURAL_HAM_MEDIUM(-0.88)[-0.883]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:213.239.217.29/32]; NEURAL_HAM_LONG(-0.99)[-0.987]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grem.de]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[grem.de:+]; NEURAL_HAM_SHORT(-0.65)[-0.648]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 18:09:42 -0000 On Tue, 16 Jun 2020 12:36:19 -0400 Ryan Steinmetz wrote: > On (06/16/20 08:14), Rodney W. Grimes wrote: > >Ok, well, I just thought of one and not sure if it is an issue or > >not, doesng unbound have the ability to specify interfaces? If so > >those may not exist until NETWORKING has run? > > > > Unbound isn't really going to do anything useful without the network. > I don't think it is unreasonable that it should depend on NETWORKING. > > I think we're in an edge case here and, perhaps, a better solution > might be to have someone(tm) add in support in rc.conf to specify > dependency overrides. > > So, perhaps you could set: > > dhcpd_after="unbound" > > Which would factor into the rcorder processing and make sure that > dhcpd starts after unbound. > > This would allow people to fine-tune things when they run into cases > like this. Exactly my thoughts for a while now. There are more examples like this (e.g., you run a service and host the database in the same jail/on the same machine, you want to have a dependency on the database being up, etc.). Never found the time to look into it though. Cheers, Michael -- Michael Gmelin