The interrupted message might be slightly misleading as there are
several timeouts before declaring the process interrupted and the wait
might not be issued immediatelly so let's use the (time - start_time)
value instead of timeout value.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

When we execute process with a timeout, we allow to specify signal to be
used after the timeout is reached defaulting to SIGTERM. This signal is
not always enough to really finish the process, on the other hand using
SIGKILL all the time might do even more damage.

Instead this version attempts to use the user-specified signal and only
if that fails it sends SIGKILL to it. The same behavior is now shared on
negative-timeout behavior.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This code is only accessible when timeout is specified so we do want to
finish as soon as possible. Let's replace the "wait" with "poll" which
might lead to declaring process Zombie even when it's not, but it's
already passed 2 timeouts so I think it's better to finish and report
something than to insist on waiting.

This improves a real bug where Avocado hanged after process execution
with timeout. This version is not the full fix, it only declares such
process as zombie and avoids the complete hang.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Our process library only allows to specify timeout for process execution
when used as the whole package using "run" method, but it might be
useful to allow the same kind of treatement for "wait". Let's move the
code there.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

The "import multiprocessing.queues" results in imported
"multiprocessing".
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The finish_deadline should be the time of the end, not timeout. This
fixes actual issue where interrupted test reports hang, because
it never checks whether the process actually lives:

    avocado run sleeptenmin.py --mux-inject /run:timeout:1
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NJunxiang Li <junli@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Instead of relying only on the SSH status code, which can succeed
while still not leaving a usable master connection running, let's add
an explicit check.

Reference: https://github.com/avocado-framework/avocado/issues/2900Signed-off-by: NCleber Rosa <crosa@redhat.com>

The connection sharing functionality of SSH, on which the
avocado.utils.ssh.Session is based upon, requires setting control path
to be given to both the SSH holding the master connection, and to the
SSH instance that should eventually reuse the master connection.

That setting was completely absenting from the library, and the only
reason it worked, was because my local SSH configurations
(~/.ssh/config) had a default setting.

To avoid clashes (even if they could, in theory, be beneficial), let's
flag the control path for the connections initialized by Avocado as
such.

Reference: https://github.com/avocado-framework/avocado/issues/2900Signed-off-by: NCleber Rosa <crosa@redhat.com>

Some tests for the vmimage module do not specify the arch to use to
determine the image that will (would) be fetched.  It then relies on
the default of using the host arch.  But, if the test is run on a host
arch different than x86_64, the test will fail.

Let's make the test more deterministic by providing the arch parameter
value.

Reference: https://trello.com/c/92VQRMoC/1483-vmimage-tests-fail-under-x8664Signed-off-by: NCleber Rosa <crosa@redhat.com>

Commit c60f0ae8 fixed a CVE warning that GitHub sent notifications
about.  While so, it was attempted to fulfill the downstream (Fedora
and EPEL) dependencies in the same patch, keeping users of Python 2
with possibly vulnerable versions.

The matching of versions that ship in the Fedora and EPEL distros are
really best done in the SPEC file.  Finally, this was motivated by the
fact that the simple Python version check was not enough because
PyYAML>=4.2b2 is not available on Fedora 28, even though it contains
Python 3.

Reference: https://trello.com/c/3UMFOyzQ/1484-pyyaml-requirement-not-fulfilled-on-f28Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

This adds a Makefile that adds support for the Fedora COPR service to
build packages for Avocado, right out of a Git repo.  To do so, create
your project, and in "Builds" tab, select "New Build".

On "1. Select source type" section, select "SCM".  On section
"2. Provide the source", under "Clone url" add the URL of your repo.
For instance, this has been tested with:

  https://github.com/clebergnu/avocado

Under "Committish", enter a reference to a given commit.  For instance, this
has been tested with the name of this branch: "copr_makefile".

Under "3. How to build SRPM from the source", select "make srpm".
Finally, select the appropriate Chroots.  It's better not to have
"Enable internet access during this build" option checked.

Finally, it's advisable to not attempt to run this Makefile locally,
as it's designed to be run on the environment that CORP provides, that
is, a mock based chroot with super user privileges.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Based on some reports of failures to behave properly on
unittest.TestCase's assertRaises methods, let's improve the test
coverage on these situations.

References: https://github.com/avocado-framework/avocado/issues/2791Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NPlamen Dimitrov <pdimitrov@pevogam.com>
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This reverts commit ae0d5528.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NPlamen Dimitrov <pdimitrov@pevogam.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

This change adds a new section to yaml to mux documentation about how to
inject values to the final multiplex tree using --mux-inject argument.
Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

When the Robot Framework finds an issue worthwhile to be shown on
the UI, it will do so, but that confuses Avocado users by mixing
the content from both layers.

Let's disable the Robot framework console logger, and only shown
the messages we intend to.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

If one is running avocado as a privileged user, the "usable_ro_dir()"
function may create a system wide directory for hosting tests.  That's
confusing because, the following workflow is possible:

 1) Regular user creates test, say "foo.py" in his own test dir
 2) Privileged user run "avocado run does_not_exist.py", which by
    means of "usable_ro_dir()", may create a system wide location
    for tests.
 3) Regular user runs "avocado run foo.py", and then test is not found
    because "avocado.core.data_dir.get_test_dir()" gives precedence to
    the system test dir created earlier.

This is also a problem when running the selftests from within the
tree, when working as a privileged user.  And finally, as a general
rule, we should avoid creating directories in system-wide locations so
silently, so I do believe this pattern could be expanded to the
results and data directories too.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

1. read directly from /proc/meminfo.
2. improve the regex to get more accurate result.
Signed-off-by: Nlolyu <lolyu@redhat.com>

As a documented feature of the asset fetcher, a user may want to make
sure, by the use of a hash, that the fetched asset is sound.  Also, by
giving a name of the asset, allow it to be fetched from a different
number of locations.

But, there's a difference in intention when a name+hash is used, and
when a specific location and hash (a URL+hash) is used.  In the later
case, we don't want to cache the file by name, because different URLs
can have completely different contents.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The name the user gives to the asset fetcher should be the primary
controlling aspect of the cache location.  The possible locations
where the asset might be found are just an aiding component to the
asset retrieval.

This is, besides a fix, also an opmization, given that
_get_relative_dir() is now called only once, instead of once for each
possible location.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The definition of the locations parameter feels broken.  Let's improve it.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

This changes addresses the CVE-2017-18342[1] that defines: "In PyYAML
before 4.1, the yaml.load() API could execute arbitrary code. In other
words, yaml.safe_load is not used."

The change affects only installation using Python 3 because when
building EL7 RPMs, we want to use version 3.10, which is packaged on
EPEL.

[1] - https://nvd.nist.gov/vuln/detail/CVE-2017-18342Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

According to the author of the publication, the authoritative source,
we were using an incorrect URL to the publication that backs the CIT
implementation.  Let's fix that.
Signed-off-by: NCleber Rosa <crosa@redhat.com>