O que há de errado com o arquivo de unidade do meu systemd?

Question

Aqui está o meu arquivo de unidade:

[Unit]
Description=Backend Service
After=mariadb.service
Requires=mariadb.service

[Service]
Type=simple
ExecStart=/var/www/html/pythonscripts/Backend.py

[Install]
Alias=BEd
WantedBy=basic.target

Aqui está o que eu escrevi anteriormente que costumava funcionar (instruções para configurar o serviço):

BEd.service must be moved to /etc/systemd/system

systemctl daemon-reload
systemctl enable BEd
systemctl start BEd

Aqui está o que a pasta / etc / systemd / system contém atualmente:

basic.target.wants  dbus-org.freedesktop.NetworkManager.service  default.target.wants     sockets.target.wants
BEd                 dbus-org.freedesktop.nm-dispatcher.service   getty.target.wants       sysinit.target.wants
BEd.service         default.target                               multi-user.target.wants  system-update.target.wants

Aqui está a mensagem de erro após a reinicialização:

[root@BEKappa ~]# systemctl status -l BHd
BEd.service - Backend Service
   Loaded: loaded (/etc/systemd/system/BEd.service; enabled)
   Active: failed (Result: exit-code) since Sat 2016-01-16 18:39:27 EST; 34s ago
  Process: 3852 ExecStart=/var/www/html/pythonscripts/BEd.py (code=exited, status=1/FAILURE)
 Main PID: 3852 (code=exited, status=1/FAILURE)
   CGroup: /system.slice/BEd.service

Jan 16 18:39:27 BEKappa BEd.py[3852]: Traceback (most recent call last):
Jan 16 18:39:27 BEKappa BEd.py[3852]: File "/var/www/html/pythonscripts/BEd.py", line 147, in <module>
Jan 16 18:39:27 BEKappa BEd.py[3852]: cur.execute(network_adapters_sql)
Jan 16 18:39:27 BEKappa BEd.py[3852]: File "/usr/lib64/python2.7/site-packages/MySQLdb/cursors.py", line 174, in execute
Jan 16 18:39:27 BEKappa BEd.py[3852]: self.errorhandler(self, exc, value)
Jan 16 18:39:27 BEKappa BEd.py[3852]: File "/usr/lib64/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
Jan 16 18:39:27 BEKappa BEd.py[3852]: raise errorclass, errorvalue
Jan 16 18:39:27 BEKappa BEd.py[3852]: _mysql_exceptions.ProgrammingError: (1064, 'You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near \'\'IP\', \'ethernet\', \'connecting\', \'(getting\', \'enp7s0\', \'yes\', \'1000\', \'"dhcp"\', )\' at line 1')
Jan 16 18:39:27 BEKappa systemd[1]: BEd.service: main process exited, code=exited, status=1/FAILURE
Jan 16 18:39:27 BEKappa systemd[1]: Unit BEd.service entered failed state.

Tenho 100% de certeza de que não é o código de serviço, já que ele começa bem após a reinicialização manual (por exemplo, systemctl start BEd).

Com base no erro, tenho 90% de certeza de que o mariaDB não está carregado quando o BEd é iniciado, ele falha na primeira instrução SQL do programa. No entanto, esse arquivo de unidade funcionou antes e atualmente está trabalhando em outro servidor. Então estou confuso.

    

Answer 1

É provável que sua pergunta não tenha atraído uma resposta devido à pergunta genérica de "O que há de errado com meu arquivo?". Tente fazer uma pergunta específica na próxima vez.

Nesse caso, você acha que o problema pode ser que o script antes do MySQL estar pronto. Você pode confirmar se esse é o caso. Desligue manualmente o MySQL e execute o script. Deve produzir o mesmo resultado.

Você também pode adicionar verificação de erro ao script para confirmar que ele pode se conectar ao MySQL antes de continuar.

Se o problema é que o MySQL não começou, então essa é uma pergunta interessante e específica a ser feita, porque sua configuração parece indicar que você pediu que o MySQL fosse iniciado primeiro.

Deve haver uma maneira de resolver / that / issue com systemd , mas você também pode testar se esse é realmente o problema ao atualizar seu script para dormir por um minuto (ou cinco) antes de tentar fazer qualquer coisa. Isso deve dar ao MySQL muito tempo para terminar de entrar online antes de continuar.

Como uma nota secundária, notei que você está armazenando seu script Python sob uma raiz da web. Se o script nem sempre é destinado a ser executado na web, a segurança pode ser melhorada movendo-o para fora da raiz da web.