cvs commit: src/usr.sbin/jexec jexec.8 jexec.c

[Robert Watson]

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 Cambridge