On Fri, 30 May 2008, Michael Reifenberger wrote: > On Thu, May 29, 2008 at 06:05:37PM +0100, Robert Watson wrote: >> On Thu, 29 May 2008, Michael Reifenberger wrote: >> >>> Log: >>> Fix some bugs/complaints: >>> - make addr2jid static >>> - add -h Flag for hostname/ip-number search >>> - s,strncmp,strcmp, in addr2jid >>> - return jid only if found once >>> >>> Requested by: some >> >> FWIW, I think recent changes have made jexec behave in a fundamentally >> unreliable way -- please don't MFC any of these changes until than >> unreliable behavior is corrected. > > What unreliable way do you mean? I just tried to address the complaints > about non uniqueness if searching with a hostname or ip-number. Furthermore > now hostname or ip-number is only user with the '-h' switch. So the usage is > purely optional and the original jid search is the default. Here's the specific concern I have: an administrator starts a jail with a name/IP number, and various processes run, creating TCP connections. The administrator shuts down the jail to change global configuration for the jail, but some TCP connections remain in TIME_WAIT (etc) as they spin down. The administrator then restarts the jail. For some number of minutes after starting the new jail, jexec will fail with the new jail, as the specification by IP or hostname will be ambiguous. This non-determinism will be a source of inconsistent and confusing behavior. For example, it's easy to imagine jexec being used as the foundation for scripts managing services in jails, such as starting/stopping Apache with control panels, etc. If those scripts all work fine except in the first two minutes of restarting a jail, sometimes, it will be an extremely hard problem to track down. We should not encourage users to depend on something that is inherently unreliable as a result of being based on a fundamentally inconsistent concept. If we want to offer options along these lines, they need to be 100% reliable, as administrators, quite reasonably, will assume that they work (regardless of a BUGS section), and quite reasonably feel upset if they then find that, for no really good reason, they "sometimes fail" based on something pretty much beyond their control. Robert N M Watson Computer Laboratory University of CambridgeReceived on Fri May 30 2008 - 06:24:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:31 UTC