Bjoern A. Zeeb 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
What is "DUD" BTW? > > > 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? Not quite: https://termbin.com/arvb syslogd sometimes remains deprived of the IPv6 address. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature