1
0
mirror of https://github.com/ARM-software/devlib.git synced 2025-03-13 21:37:50 +00:00
devlib/devlib/host.py

146 lines
5.1 KiB
Python
Raw Normal View History

# Copyright 2015-2017 ARM Limited
2015-10-09 09:30:04 +01:00
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
from glob import iglob
2015-10-09 09:30:04 +01:00
import os
import signal
2015-10-09 09:30:04 +01:00
import shutil
import subprocess
import logging
from distutils.dir_util import copy_tree
2015-10-09 09:30:04 +01:00
from getpass import getpass
from pipes import quote
2015-10-09 09:30:04 +01:00
exceptions: Classify transient exceptions Exceptions such as TargetError can sometimes be raised because of a network issue, which is useful to distinguish from errors caused by a missing feature for automated testing environments. The following exceptions are introduced: * DevlibStableError: raised when a non-transient error is encountered * TargetStableError * DevlibTransientError: raised when a transient error is encountered, including timeouts. * TargetTransientError When there is an ambiguity on the type of exception to use, it can be assumed that the configuration is correct, and therefore it is a transient error, unless the function is specifically designed to probe a property of the system. In that case, ambiguity is allowed to be lifted by assuming a non-transient error, since we expect it to raise an exception when that property is not met. Such ambiguous case can appear when checking Android has booted, since we cannot know if this is a timeout/connection issue, or an actual issue with the Android build or configuration. Another case are the execute() methods, which can be expected to fail on purpose. A new parameter will_succeed=False is added, to automatically turn non transient errors into transient ones if the caller is 100% sure that the command cannot fail unless there is an environment issue that is outside of the scope controlled by the user. devlib now never raises TargetError directly, but one of TargetStableError or TargetTransientError. External code can therefore rely on all (indirect) instances TargetError to be in either category. Most existing uses of TargetError are replaced by TargetStableError.
2018-06-20 15:04:12 +01:00
from devlib.exception import TargetTransientError, TargetStableError
2015-10-09 09:30:04 +01:00
from devlib.utils.misc import check_output
from devlib.connection import ConnectionBase, PopenBackgroundCommand
2015-10-09 09:30:04 +01:00
2015-10-09 09:30:04 +01:00
PACKAGE_BIN_DIRECTORY = os.path.join(os.path.dirname(__file__), 'bin')
2018-07-11 17:30:45 +01:00
# pylint: disable=redefined-outer-name
def kill_children(pid, signal=signal.SIGKILL):
with open('/proc/{0}/task/{0}/children'.format(pid), 'r') as fd:
for cpid in map(int, fd.read().strip().split()):
kill_children(cpid, signal)
os.kill(cpid, signal)
2015-10-09 09:30:04 +01:00
class LocalConnection(ConnectionBase):
2015-10-09 09:30:04 +01:00
name = 'local'
host = 'localhost'
2015-10-09 09:30:04 +01:00
@property
def connected_as_root(self):
if self._connected_as_root is None:
result = self.execute('id', as_root=False)
self._connected_as_root = 'uid=0(' in result
return self._connected_as_root
@connected_as_root.setter
def connected_as_root(self, state):
self._connected_as_root = state
2018-07-11 17:30:45 +01:00
# pylint: disable=unused-argument
def __init__(self, platform=None, keep_password=True, unrooted=False,
password=None, timeout=None):
super().__init__()
self._connected_as_root = None
2015-10-09 09:30:04 +01:00
self.logger = logging.getLogger('local_connection')
self.keep_password = keep_password
self.unrooted = unrooted
self.password = password
2015-10-09 09:30:04 +01:00
def push(self, source, dest, timeout=None, as_root=False): # pylint: disable=unused-argument
self.logger.debug('cp {} {}'.format(source, dest))
shutil.copy(source, dest)
def pull(self, source, dest, timeout=None, as_root=False): # pylint: disable=unused-argument
self.logger.debug('cp {} {}'.format(source, dest))
if ('*' in source or '?' in source) and os.path.isdir(dest):
# Pull all files matching a wildcard expression
for each_source in iglob(source):
shutil.copy(each_source, dest)
else:
if os.path.isdir(source):
# Use distutils to allow copying into an existing directory structure.
copy_tree(source, dest)
else:
shutil.copy(source, dest)
2015-10-09 09:30:04 +01:00
2018-07-11 17:30:45 +01:00
# pylint: disable=unused-argument
def execute(self, command, timeout=None, check_exit_code=True,
exceptions: Classify transient exceptions Exceptions such as TargetError can sometimes be raised because of a network issue, which is useful to distinguish from errors caused by a missing feature for automated testing environments. The following exceptions are introduced: * DevlibStableError: raised when a non-transient error is encountered * TargetStableError * DevlibTransientError: raised when a transient error is encountered, including timeouts. * TargetTransientError When there is an ambiguity on the type of exception to use, it can be assumed that the configuration is correct, and therefore it is a transient error, unless the function is specifically designed to probe a property of the system. In that case, ambiguity is allowed to be lifted by assuming a non-transient error, since we expect it to raise an exception when that property is not met. Such ambiguous case can appear when checking Android has booted, since we cannot know if this is a timeout/connection issue, or an actual issue with the Android build or configuration. Another case are the execute() methods, which can be expected to fail on purpose. A new parameter will_succeed=False is added, to automatically turn non transient errors into transient ones if the caller is 100% sure that the command cannot fail unless there is an environment issue that is outside of the scope controlled by the user. devlib now never raises TargetError directly, but one of TargetStableError or TargetTransientError. External code can therefore rely on all (indirect) instances TargetError to be in either category. Most existing uses of TargetError are replaced by TargetStableError.
2018-06-20 15:04:12 +01:00
as_root=False, strip_colors=True, will_succeed=False):
2015-10-09 09:30:04 +01:00
self.logger.debug(command)
if as_root and not self.connected_as_root:
2015-10-09 09:30:04 +01:00
if self.unrooted:
exceptions: Classify transient exceptions Exceptions such as TargetError can sometimes be raised because of a network issue, which is useful to distinguish from errors caused by a missing feature for automated testing environments. The following exceptions are introduced: * DevlibStableError: raised when a non-transient error is encountered * TargetStableError * DevlibTransientError: raised when a transient error is encountered, including timeouts. * TargetTransientError When there is an ambiguity on the type of exception to use, it can be assumed that the configuration is correct, and therefore it is a transient error, unless the function is specifically designed to probe a property of the system. In that case, ambiguity is allowed to be lifted by assuming a non-transient error, since we expect it to raise an exception when that property is not met. Such ambiguous case can appear when checking Android has booted, since we cannot know if this is a timeout/connection issue, or an actual issue with the Android build or configuration. Another case are the execute() methods, which can be expected to fail on purpose. A new parameter will_succeed=False is added, to automatically turn non transient errors into transient ones if the caller is 100% sure that the command cannot fail unless there is an environment issue that is outside of the scope controlled by the user. devlib now never raises TargetError directly, but one of TargetStableError or TargetTransientError. External code can therefore rely on all (indirect) instances TargetError to be in either category. Most existing uses of TargetError are replaced by TargetStableError.
2018-06-20 15:04:12 +01:00
raise TargetStableError('unrooted')
2015-10-09 09:30:04 +01:00
password = self._get_password()
command = 'echo {} | sudo -S -- sh -c '.format(quote(password)) + quote(command)
2015-10-09 09:30:04 +01:00
ignore = None if check_exit_code else 'all'
try:
return check_output(command, shell=True, timeout=timeout, ignore=ignore)[0]
except subprocess.CalledProcessError as e:
message = 'Got exit code {}\nfrom: {}\nOUTPUT: {}'.format(
e.returncode, command, e.output)
exceptions: Classify transient exceptions Exceptions such as TargetError can sometimes be raised because of a network issue, which is useful to distinguish from errors caused by a missing feature for automated testing environments. The following exceptions are introduced: * DevlibStableError: raised when a non-transient error is encountered * TargetStableError * DevlibTransientError: raised when a transient error is encountered, including timeouts. * TargetTransientError When there is an ambiguity on the type of exception to use, it can be assumed that the configuration is correct, and therefore it is a transient error, unless the function is specifically designed to probe a property of the system. In that case, ambiguity is allowed to be lifted by assuming a non-transient error, since we expect it to raise an exception when that property is not met. Such ambiguous case can appear when checking Android has booted, since we cannot know if this is a timeout/connection issue, or an actual issue with the Android build or configuration. Another case are the execute() methods, which can be expected to fail on purpose. A new parameter will_succeed=False is added, to automatically turn non transient errors into transient ones if the caller is 100% sure that the command cannot fail unless there is an environment issue that is outside of the scope controlled by the user. devlib now never raises TargetError directly, but one of TargetStableError or TargetTransientError. External code can therefore rely on all (indirect) instances TargetError to be in either category. Most existing uses of TargetError are replaced by TargetStableError.
2018-06-20 15:04:12 +01:00
if will_succeed:
raise TargetTransientError(message)
else:
raise TargetStableError(message)
2015-10-09 09:30:04 +01:00
def background(self, command, stdout=subprocess.PIPE, stderr=subprocess.PIPE, as_root=False):
if as_root and not self.connected_as_root:
2015-10-09 09:30:04 +01:00
if self.unrooted:
exceptions: Classify transient exceptions Exceptions such as TargetError can sometimes be raised because of a network issue, which is useful to distinguish from errors caused by a missing feature for automated testing environments. The following exceptions are introduced: * DevlibStableError: raised when a non-transient error is encountered * TargetStableError * DevlibTransientError: raised when a transient error is encountered, including timeouts. * TargetTransientError When there is an ambiguity on the type of exception to use, it can be assumed that the configuration is correct, and therefore it is a transient error, unless the function is specifically designed to probe a property of the system. In that case, ambiguity is allowed to be lifted by assuming a non-transient error, since we expect it to raise an exception when that property is not met. Such ambiguous case can appear when checking Android has booted, since we cannot know if this is a timeout/connection issue, or an actual issue with the Android build or configuration. Another case are the execute() methods, which can be expected to fail on purpose. A new parameter will_succeed=False is added, to automatically turn non transient errors into transient ones if the caller is 100% sure that the command cannot fail unless there is an environment issue that is outside of the scope controlled by the user. devlib now never raises TargetError directly, but one of TargetStableError or TargetTransientError. External code can therefore rely on all (indirect) instances TargetError to be in either category. Most existing uses of TargetError are replaced by TargetStableError.
2018-06-20 15:04:12 +01:00
raise TargetStableError('unrooted')
2015-10-09 09:30:04 +01:00
password = self._get_password()
command = 'echo {} | sudo -S '.format(quote(password)) + command
2015-10-09 09:30:04 +01:00
# Make sure to get a new PGID so PopenBackgroundCommand() can kill
# all sub processes that could be started without troubles.
def preexec_fn():
os.setpgrp()
popen = subprocess.Popen(
command,
stdout=stdout,
stderr=stderr,
shell=True,
preexec_fn=preexec_fn,
)
bg_cmd = PopenBackgroundCommand(popen)
self._current_bg_cmds.add(bg_cmd)
return bg_cmd
def _close(self):
2015-10-09 09:30:04 +01:00
pass
def cancel_running_command(self):
pass
def wait_for_device(self, timeout=30):
return
def reboot_bootloader(self, timeout=30):
raise NotImplementedError()
2015-10-09 09:30:04 +01:00
def _get_password(self):
if self.password:
return self.password
password = getpass('sudo password:')
if self.keep_password:
self.password = password
return password