From owner-freebsd-net@freebsd.org Thu Mar 19 13:22:48 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 9B665260686; Thu, 19 Mar 2020 13:22:48 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48jndf54KVz4gBC; Thu, 19 Mar 2020 13:22:46 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 01CAA8D4A168; Thu, 19 Mar 2020 13:22:44 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 7B1E4E7089D; Thu, 19 Mar 2020 13:22:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id wtJPBlSRQI1d; Thu, 19 Mar 2020 13:22:42 +0000 (UTC) Received: from [169.254.231.217] (unknown [IPv6:fde9:577b:c1a9:4902:edb8:d7e:6ea:811a]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9088CE7089C; Thu, 19 Mar 2020 13:22:42 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Victor Sudakov" Cc: "Miroslav Lachman" <000.fbsd@quip.cz>, freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: IPv6 in jails Date: Thu, 19 Mar 2020 13:22:40 +0000 X-Mailer: MailMate (2.0BETAr6146) Message-ID: <01EF7656-4F8A-4075-A0B4-27E8AB17B516@lists.zabbadoz.net> In-Reply-To: <20200319021432.GA80800@admin.sibptus.ru> References: <20200318151556.GA64871@admin.sibptus.ru> <2dd539ed-0ee3-079b-27b2-28126056c69a@quip.cz> <20200318155046.GD65497@admin.sibptus.ru> <4CA69535-0F6C-40FC-83CF-5000FD728C2D@lists.zabbadoz.net> <20200319021432.GA80800@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 48jndf54KVz4gBC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-5.01 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.72)[ip: (-9.11), ipnet: 195.201.0.0/16(-2.91), asn: 24940(-1.55), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 13:22:48 -0000 On 19 Mar 2020, at 2:14, Victor Sudakov wrote: >> If it does, can you add a >> >> exec.start += "sleep 2 "; >> >> to your config > > OK, I've added it to the configs of 3 experimental jails. > >> and see if your problem goes away? > > It goes away partially (only for sshd in 2 of the 3 available jails), > and > not for syslogd in any of the 3 available jails. Restarting the > daemons > from within the jail fixes the problem. An example from a problem > jail: > .. > >> If it does, the reason is >> that you configure an IPv6 address to an interface and DUD has not >> yet >> completed by the time sshd or other daemons start. Giving it the 2 >> seconds >> avoids this problem and the address is usable at that time. > > There is obviously a race somewhere, but the 2 second sleep does not > eliminate it entirely. Well not so much of a race but than a “gap”. The point is you are configuring an address on the base system and the jail knows nothing about it so it’ll simply start the daemons. Normally the startup scripts would do the right thing. I don’t think “polluting” jail(8) with logic to check that the addresses become available or not is a good idea. However I agree that it should automatically do the right thing somehow .. > Thank you for the hint in the right direction, what would you suggest > further? If you make it 3 seconds, does it deterministically work then? /bz