AWS Lambda中基于ECR镜像调用LibreOffice时pyuno连接失败

以下是针对该问题的排查方向和可落地的解决方案：

1. 修正LibreOffice启动参数与运行目录权限 #

Lambda运行环境的/home目录为只读状态，而LibreOffice默认会在用户主目录生成配置文件，这会导致启动失败或服务初始化异常。启动时需显式指定可写的临时目录：

soffice --headless --accept="socket,host=127.0.0.1,port=2002;urp;" --norestore --nofirststartwizard --nologo --env:HOME=/tmp

同时确保镜像中Lambda默认运行用户（sbx_user1051）对/tmp有读写权限，镜像构建阶段可添加：

RUN chmod 777 /tmp

2. 添加启动等待逻辑，避免过早连接 #

Lambda冷启动或LibreOffice启动耗时较长时，直接发起连接会失败。在函数代码中加入等待逻辑，确认服务就绪后再建立连接：

# Python示例：循环检查2002端口是否开放
import socket
import time

def wait_libreoffice_ready(port=2002, timeout=30):
    start = time.time()
    while time.time() - start < timeout:
        try:
            sock = socket.create_connection(('127.0.0.1', port), timeout=1)
            sock.close()
            return True
        except (socket.timeout, ConnectionRefusedError):
            time.sleep(0.5)
    return False

# 在调用LibreOffice服务前执行等待
wait_libreoffice_ready()

3. 改用Unix域套接字替代TCP套接字 #

Lambda环境中Unix域套接字的稳定性优于TCP套接字，修改启动参数使用/tmp下的Unix socket路径（仅可写目录支持）：

soffice --headless --accept="unixsocket,path=/tmp/lo_socket;urp;" --norestore --nofirststartwizard --nologo --env:HOME=/tmp

代码中连接时需对应指定Unix socket路径（适配所用LibreOffice SDK的连接逻辑）。

4. 确保镜像包含完整的LibreOffice依赖 #

本地环境可能自带额外系统依赖，但Lambda镜像中常缺失。基于Amazon Linux 2或Ubuntu构建镜像时，需同步安装依赖包：

# Amazon Linux 2 构建示例
RUN amazon-linux-extras install libreoffice -y
RUN yum install -y fontconfig libXext libXrender libXinerama libXi libXrandr

# Ubuntu 构建示例
RUN apt-get update && apt-get install -y libreoffice libreoffice-core fontconfig libxext6 libxrender1 libxinerama1 libxi6 libxrandr2

缺少字体或图形依赖会导致LibreOffice无法正常启动服务进程。

5. 调整Lambda资源配置 #

LibreOffice启动需要足够内存支持，建议将Lambda函数内存配置至少设为512MB（推荐1GB），内存不足会直接导致进程意外终止。同时延长函数超时时间，确保覆盖LibreOffice启动和文件处理的全流程耗时。

内容的提问来源于stack exchange，提问作者Thakur Sahil Sambyal