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/

Attachment: signature.asc
Description: PGP signature

Reply via email to