控制客户端,返回超时问题
现象
执行需要与加域客户端交互的测试用例,当脚本代码完成发送后,操作客户端时,zerorpc
通信超时:
shell
x86_64-35: 07/31 11:18:27 | DEBUG | connected to tcp://10.8.12.9:4243 (status=<SocketContext(connect='tcp://10.8.12.9:4243')>)
x86_64-35: 07/31 11:18:27 | DEBUG | --> new channel b'e80b75021e28402186f871ea993c4eb4'
x86_64-35: 07/31 11:18:30 | DEBUG | -x- closed channel b'e80b75021e28402186f871ea993c4eb4'
x86_64-35: 07/31 11:18:30 | DEBUG | [sleep]: sleep 5 s [x86_64 * 1.0 = 5.0]
x86_64-35: 07/31 11:18:35 | INFO | [sleep]: sleep 2 s [x86_64 * 1.0 = 2.0]
Warning: Permanently added '10.8.12.9' (ECDSA) to the list of known hosts.
sending incremental file list
autotest_udcp/_readme/README.md
autotest_udcp/case/pages/logs/logs_pc/test_logs_1340913.py
autotest_udcp/client/widget/base_widget.py
autotest_udcp/client/widget/udcp_wizzard_widget.py
sent 20,068 bytes received 243 bytes 40,622.00 bytes/sec
total size is 781,136,071 speedup is 38,458.77
x86_64-35: 07/31 11:18:38 | DEBUG | connected to tcp://10.8.12.9:4243 (status=<SocketContext(connect='tcp://10.8.12.9:4243')>)
x86_64-35: 07/31 11:18:38 | DEBUG | --> new channel b'e80b75031e28402186f871ea993c4eb4'
x86_64-35: 07/31 11:18:58 | DEBUG | -x- closed channel b'e80b75031e28402186f871ea993c4eb4'
x86_64-35: 07/31 11:18:58 | INFO | [pytest_runtest_makereport]: 运行结果: FAILED
【 2024-07-31 11:18:58.619927 TestUdcp.test_client_cts_1450161 || FAILED ✘ 】
apps/autotest_udcp/case/pages/client_cts/test_client_cts_1450161.py:14 (TestUdcp.test_client_cts_1450161)
self = <zerorpc.channel.BufferedChannel object at 0x7feb61978160>, timeout = 20
def recv(self, timeout=None):
# self._channel can be set to None by an 'on_close_if' callback if it
# sees a suitable message from the remote end...
#
if self._verbose and self._channel:
if self._input_queue_reserved < self._input_queue_size // 2:
self._request_data()
else:
self._verbose = True
try:
> event = self._input_queue.get(timeout=timeout)
/home/lxs-pen/.local/lib/python3.7/site-packages/zerorpc/channel.py:255:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> ???
src/gevent/queue.py:335:
……
分析
1、进入加域客户端,手动启动远程服务,提示Could not open X display
:
shell
(youqu) 12345@uos-PC:~/youqu/src/remotectl$ python3 _remote_other_ctl.py
No protocol specified
Unable to init server: Could not connect: Connection refused
No protocol specified
Unable to init server: 无法连接:Connection refused
No protocol specified
(_remote_other_ctl.py:21887): dbind-WARNING **: 10:00:10.002: Could not open X display
2、查看当前登录终端,发现有多个 x 服务在运行:
shell
$ $ who
uos tty1 2024-07-30 16:50 (:0)
12345 tty2 2024-07-30 17:04 (:1)
12345 pts/0 2024-07-31 09:59 (10.8.11.74)
3、注销 x 服务为 0 的用户,再次尝试依旧复现,查询后发现加域账户依旧虽然为第一个 x 服务,但是标识依旧是 :1
shell
$ $ who
12345 tty2 2024-07-30 17:04 (:1)
12345 pts/0 2024-07-31 09:59 (10.8.11.74)
解决
重启终端系统,只登录加域账户,问题消失
控制客户端,无法找到资源问题
现象
执行用例时,服务端网页自动化执行正常,进行客户端断言时,找不到资源(图片资源)
分析
1、找不到资源,查看客户端 youqu
项目的自动化应用项目是否存在对应资源,发现整个 youqu
项目没有同步到客户端
2、执行前有进行过手动删除 youqu
的动作,重新执行时,调试发现没有进行重新发送
python
# youqu/src/remotectl/_base.py
def _transfer_appname(ip, password, user, transfer_appname):
os.system(
f"sshpass -p '{password}' rsync -av -e ssh --exclude='__pycache__' "
f"{conf.APPS_PATH}/{transfer_appname} {user}@{ip}:~/{client_project_path}/apps/"
)
3、继续断点调试,发现逻辑为如果存在远端远程服务进程,则不进行文件同步
python
# youqu/src/remotectl/_base.py
def check_rpc_started(filename):
……
_base_env_check()
if transfer_appname:
_transfer_appname(ip, password, user, transfer_appname)
tool_status = os.popen(
f'''{_ssh(ip, password, user)} "ps -aux | grep {filename} | grep -v grep"'''
).read()
if not tool_status:
_transfer_to_client(ip, password, user)
_start_client_service(ip, password, user, filename)
if restart_service:
_restart_client_service(ip, password, user, filename)
res = func(*args, **kwargs)
……
4、查看客户端服务进程,文件虽然不存在,但是进程依旧存在
shell
12345@uos-PC:~$ ps aux|grep remote
12345 4648 0.5 2.2 725052 183048 ? SLsl 10:03 0:14 /home/12345@udcp/youqu/.venv/bin/python _remote_other_ctl.py
12345 5123 0.0 1.9 700436 155644 ? SLsl 10:03 0:02 /home/12345@udcp/youqu/.venv/bin/python _remote_dogtail_ctl.py
12345 18070 0.0 0.0 13820 888 pts/1 S+ 10:52 0:00 grep remote
解决
杀掉原进程,重新执行,报错消失