No se puede demonizar el script de Python usando systemd: no hay ningún módulo llamado 'oandapyV20'

No se puede demonizar el script de Python usando systemd: no hay ningún módulo llamado 'oandapyV20'

Estoy intentando demonizar un script de Python usando systemd, pero aparece constantemente el error "No hay módulo llamado 'oandapyV20'" después de activar el demonio.

El script está en la ubicación: /home/user/workingdir/script.py

El entorno virtual está en: /home/user/venv/bin/

Mi mejor suposición sobre cómo crear el servicio a partir de los documentos que encontré es la siguiente:

[Unit]
Description=DataLoader
[Service]
User=root
Group=root
WorkingDirectory=/home/user/workingdir
ExecStart=/home/user/venv/bin/python3 script.py
[Install]
WantedBy=multi-user.target

¿Qué funciona...?

script python3.py

o activar el entorno virtual

fuente /home/user/venv/bin/activate; script python3.py

Aunque eso funciona fuera del servicio, nada de lo que he probado funciona cuando llamo desde systemd.

¿Dónde me equivoco? ¿Qué no me estoy dando cuenta?

Solución eventual (con poca comprensión)

[Unit]
Description=DataLoader
[Service]
User={user_name}
Group={user_name}
WorkingDirectory=/home/{user_name}/workingdir
ExecStart=/usr/bin/python3 script.py
Restart=always
[Install]
WantedBy=multi-user.target

Respuesta1

Parece que ha estado operando bajo el supuesto de que cada vez que llamaba a source /home/user/venv/activate, el python3comando (y el pip3comando) llamaría posteriormente al ejecutable relevante desde /home/user/venv/bin.

Sin embargo, la aclaración que agregó en los comentarios indica que la suposición era incorrecta. No había estado llamando a Python desde su entorno virtual cuando ejecutaba script.py; había estado llamando a Python /usr/bin(y parece que también es correspondiente pip, ya que Python en su entorno virtual no parece tener el oandapyV20módulo instalado, mientras que el Python del sistema sí lo tiene).

Examinar la salida de

echo $PATH
echo $PYTHONPATH

La $PATHvariable de entorno es una lista de rutas separadas por dos puntos en su sistema que se buscarán cuando ingrese un comando. O /home/user/venv/binno está presente en esa lista o ocurre después de una aparición de /usr/bin, que contiene una coincidencia para python3( $PATHdejará de escanearse después de la primera coincidencia). $PATHGeneralmente se establece por $HOME/.bashrc(o /etc/bashrcsi no se establece allí) y si su suposición hubiera sido correcta, /home/user/venv/activatehabría estado prefiriendo $PATHanteponerlo /home/user/venv/bin.

$PYTHONPATHdebería decirle a Python dónde buscar módulos para cargar. (También se puede modificar o leer desde su script con sys.path.)

Eso explica por qué funcionó cambiar el comando de su unidad systemd: finalmente está llamando al mismo Python que lo hizo su comando de trabajo.

información relacionada