Início / unix / Perguntas / 409609
Accepted
sscirrus
Asked: 2017-12-08 15:38:45 +0800 CST

Como executar um comando dentro de um virtualenv usando systemd

  • 772

Eu acredito que isso deve ser simples, mas não consigo fazê-lo funcionar corretamente.

Estes são os comandos que posso executar na linha de comando:

cd /home/debian/ap

# Start a virtualenv
source venv-ap/bin/activate

# This needs to happen inside the virtualenv and takes ~20 seconds
crossbar start

# Outside the virtualenv, perhaps in a different command line window
python3 /home/debian/myscript.py

Esses comandos devem ser executados nessa ordem. Devido ao virtualenv, o não executável para crossbar e o script python separado posteriormente, não consegui descobrir a melhor maneira de fazer isso funcionar. Meu trabalho atual em andamento:

[Unit]
Description=Start CB
After=network.target

[Service]
Type=simple
User=debian
ExecStartPre=source /home/debian/ap/venv-ap/bin/activate
ExecStart=cd /home/debian/ap/ && crossbar start
Restart=always

[Install]
WantedBy=multi-user.target
systemd python

2 respostas

  1. Best Answer

    Isso não funciona porque sourceé um comando shell, então systemd's ExecStart=ou ExecStartPre=não os entenderá diretamente ... (BTW, o mesmo é verdadeiro para cde o &&.)

    Você pode conseguir isso executando um shell explicitamente e executando todos os seus comandos juntos:

    ExecStart=/bin/sh -c 'cd /home/debian/ap/ && source venv-ap/bin/activate && crossbar start'

    Mas uma abordagem melhor é, em vez de obter o script "ativar", usar o pythonexecutável bin/diretamente no seu virtualenv.

    Se você olhar o documento de uso do virtualenv , notará que diz:

    ENV/biné criado, onde os executáveis ​​vivem - visivelmente um novo python . Portanto, executar um script com #! /path/to/ENV/bin/pythonexecutaria esse script no python deste virtualenv.

    Em outras palavras, assumindo que crossbaro script Python que você deseja executar requer o venv-apvirtualenv, simplesmente comece crossbarcom:

    #!/home/debian/ap/venv-ap/bin/python

    E ele usará automaticamente o virtualenv sempre que for invocado.

    Também é possível invocar o interpretador Python do virtualenv diretamente, com:

    ExecStart=/home/debian/ap/venv-ap/bin/python /path/to/crossbar start

    (Além disso, em relação à execução em um diretório específico, a configuração WorkingDirectory=/home/debian/apé melhor do que usar um cdcomando. Você não precisa de um shell dessa forma e o systemd pode fazer um melhor tratamento de erros para você.)

    • 42

  2. Eu quero iterar na segunda parte da resposta de @filbranden

    Mas uma abordagem melhor é, em vez de fornecer o script "ativar", usar o executável python diretamente no bin/ do seu virtualenv.

    Se você olhar o documento de uso do virtualenv, notará que diz:

    ENV/bin é criado, onde os executáveis ​​vivem - visivelmente um novo python. Executando assim um script com #! /path/to/ENV/bin/python executaria esse script no python deste virtualenv.

    Não execute coisas no venv sem ativá-lo! Para ser justo, a documentação também é enganosa. Ativar o venv permite separar o diretório de trabalho do caminho do python (e dos pacotes venv-ed), o que é obrigatório com bastante frequência: você não deseja executar/colocar algo diretamente no venv bin, mas instalou alguns dependências do script para ele.

    Considere o seguinte cenário (que aposto que é um dos mais comuns):

    • você precisa executar um script de um repositório git com, mas tem suas dependências incompatíveis com seus pacotes python
    • você criou um virtualenv e o pip instalou as dependências lá
    • você clonou o repositório em algum lugar, mas o script não está no bin do venv.

    Se você quiser trabalhar no aplicativo a partir do repositório git, deseja que sua pasta esteja intacta, exceto suas modificações de código significativas. Você não gostaria de mudar shebang. Você pode colocar todo o venv em um subdiretório no repositório clonado e gitignorá-lo para manter tudo organizado, mas então:

    • você definiria o diretório de trabalho systemd para a pasta clonada
    • você executaria o script com o caminho completo do python da subpasta
    • script não encontrará os deps pip-ed, pois eles não estão na pasta de trabalho, nem no caminho O problema permanece se você inverter a hierarquia de pastas (clonar o repo para a subpasta do venv).

    Além disso, talvez você não queira executar o python diretamente, mas, por exemplo: gunicorn, e você colocou o webapp /srvenquanto o venv está em /var/lib.

    Não ativar um venv não é um bom hábito , eu me pergunto como aquele parágrafo idiota chegou aos documentos venv oficiais. Sim, ativá-lo não é necessário em alguns casos, exceto em muitos cenários do mundo real! - Eu defendo.

    ExecStartPrenão funcionará para fornecer venv de qualquer maneira, pois ele é executado em um shell diferente do ExecStartcomando 's, portanto, as variáveis ​​de ambiente não estarão corretas no último.

    Aconselho definir o venv PATH comEnvironment

    • 0

relate perguntas