![No se puede demonizar el script de Python usando systemd: no hay ningún módulo llamado 'oandapyV20'](https://rvso.com/image/170267/No%20se%20puede%20demonizar%20el%20script%20de%20Python%20usando%20systemd%3A%20no%20hay%20ning%C3%BAn%20m%C3%B3dulo%20llamado%20'oandapyV20'.png)
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 python3
comando (y el pip3
comando) 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 oandapyV20
módulo instalado, mientras que el Python del sistema sí lo tiene).
Examinar la salida de
echo $PATH
echo $PYTHONPATH
La $PATH
variable 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/bin
no está presente en esa lista o ocurre después de una aparición de /usr/bin
, que contiene una coincidencia para python3
( $PATH
dejará de escanearse después de la primera coincidencia). $PATH
Generalmente se establece por $HOME/.bashrc
(o /etc/bashrc
si no se establece allí) y si su suposición hubiera sido correcta, /home/user/venv/activate
habría estado prefiriendo $PATH
anteponerlo /home/user/venv/bin
.
$PYTHONPATH
deberí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.