Because the async_status module will read from the same file that
the async_wrapper module is writing, it's possible that the file
may not be fully synced during a read, causing spurious failures.
Use a temp file to do an atomic operation on the file. We can't
use atomic_move() here as that doesn't work properly under async.
Also, let's not read concurrently from the same file the subprocess
is writing to. Instead, capture stdout/stderr via PIPE and write to
the file to avoid nasty races.
Prior to Python 2.5, SystemExit was a subclass of Exception.
In Py2.4, this is causing extra error output on valid sys.exit(0).
(Toshio) Call sys.exit from inside of the SystemExit exception handler so py2.4 and py2.5+ behaviour matches
* Fixing compile time errors irt a) exception handling for Python 3 in util, also: b) problem octal usage (fixed) and c) print json_dump -> print(json_dump(xyz) ... et al
* This code was not Python 2.4 compliant. Octal codes and exception handling is now working with Py 2.4, 2.6, & 3.5.
* Fixing formating (or rather reverting an non 2.4 compatible change). Works in compile & runtime checking.
* a) revert to use print sys.stderr not fail_json; b) fixed var name in exception
* Python 3 compatible print (print >>sys.stderr will generate a TypeError - now uses sys.stderr.write instead).
There are established connections for a service. The service is bound to a ipv4-mapped ipv6 address. Wait_for wrongly waits for clients listed in exclude_hosts.
Running async_status in an "until: result.finished" loop will mask a module failure (eg, traceback) with a
template failure, because the fail dict doesn't include "finished" (eg, you'll see "ERROR! The conditional check 'bogus_out.finished' failed. The error was: ERROR! error while evaluating conditional: bogus_out.finished ({% if bogus_out.finished %} True {% else %} False {% endif %}"). Because the failure dict still includes "failed: true",
this change has no effect on stoppage/failure reporting, it just prevents the common usage pattern from masking the underlying error message.
* reading from a socket that gave some data we weren't looking for and
then closed.
* read from a socket that stays open and never sends data.
* reading from a socket that sends data but not the data we're looking
for.
Fixes#2051
Context: I recently discovered that when setting a fact, key=value pairs and complex arguments differ in how the fact is stored. For example, when attempting to use complex arguments using key=values, the result can be stored as a unicode string as opposed to an object/list/etc.
I'm hoping the above example update will better demonstrate to and instruct people to use complex arguments instead of key=value pairs in certain situations.
