O serviço Systemd permanece inativo devido a code = exited, status = 1 / FAILURE

0

Eu criei um serviço em um Ubuntu 16.04 para executar um aplicativo c ++ após cada inicialização. O aplicativo c ++ é executado entre outras medidas de ping, e é por isso que eu preciso iniciá-lo após a rede estar ativa e ter cap_net_raw = ep. O arquivo da unidade de serviço que eu criei e armazenei em / etc / systemd / system / é o seguinte (app.service):

[Unit]
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
Restart=always
ExecStart=/home/app/script.sh

[Install]
WantedBy=default.target

O script.sh contém o seguinte:

#!/bin/bash
sudo setcap cap_net_raw=ep /home/app/C++_APP  
cd /home/app
gnome-terminal -e "./C++_APP"

Eu também dei os seguintes comandos:

   chmod +x /home/app/script.sh    
   chmod 664 /etc/systemd/system/app.service
   systemctl daemon-reload
   systemctl enable app.service

No entanto, quando eu reinicio o sistema operacional, o aplicativo c ++ não é executado e quando eu dou:

systemctl status app.service

Recebo a seguinte mensagem:

app.service    Loaded: loaded (/etc/systemd/system/app.service; enabled; vendor preset: enabled)    Active: inactive (dead) (Result: exit-code) since Mon 2017-04-03 16:14:21 EEST; 2min 24s ago   Process: 2937 ExecStart=/home/user/script.sh (code=exited, status=1/FAILURE)

Quando executo o script manualmente, tudo funciona bem. Alguém tem alguma idéia do que eu fiz de errado?

    
por dk13 03.04.2017 / 15:40

1 resposta

0

systemd não é a ferramenta certa para executar aplicativos de área de trabalho como gnome-terminal em primeiro plano. Seu systemd config estará executando o aplicativo como root , o que presumo que você pretenda. Ele não saberá se é incapaz de executar um aplicativo na sessão de primeiro plano de um usuário em particular.

Atualize seu script para não usar gnome-terminal e apenas torne o aplicativo executável e execute-o diretamente.

Para depurar, você pode fazer o log em STDOUT ou STDERR e usar journalctl -u app.service para revisar os logs. Revisar linhas próximas na saída journalctl completa também pode ser útil.

Veja também esta postagem relacionada sobre a execução de aplicativos por meio da CLI vs com o systemd:

por Mark Stosberg 03.04.2017 / 18:57