Por que meu serviço systemd ativado não inicia na inicialização?

14

Eu tenho o seguinte arquivo de unidade systemd em /etc/systemd/system/emacs.service :

[Unit]
Description=Emacs: the extensible, self-documenting text editor
Documentatin=man:emacs(1) info:Emacs


[Service]
Type=forking
ExecStart=/usr/bin/emacs --daemon
ExecStop=/usr/bin/emacsclient --eval "(progn (setq kill-emacs-hook nil) (kill-emacs))"
Restart=always
Environment=DISPLAY=:%i
TimeoutStartSec=0

[Install]
WantedBy=default.target

Eu quero que isso comece na inicialização, então eu digitei systemctl enable emacs

No entanto, cada vez que meu serviço é reinicializado, systemctl status emacs mostra:

● emacs.service - Emacs: the extensible, self-documenting text editor
   Loaded: loaded (/etc/systemd/system/emacs.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Mas, em seguida, inserindo systemctl start emacs e verificando o status retorna:

● emacs.service - Emacs: the extensible, self-documenting text editor
   Loaded: loaded (/etc/systemd/system/emacs.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2016-11-11 23:03:59 UTC; 4s ago
  Process: 3151 ExecStart=/usr/bin/emacs --daemon (code=exited, status=0/SUCCESS)
 Main PID: 3154 (emacs)
    Tasks: 2
   Memory: 7.6M
      CPU: 53ms
   CGroup: /system.slice/emacs.service
           └─3154 /usr/bin/emacs --daemon

Como posso fazer com que este processo inicie com sucesso na inicialização?

    
por Startec 12.11.2016 / 00:05

3 respostas

7

Eu não tenho ideia do porquê, mas para fazer isso funcionar, eu:

excluído Environment=DISPLAY=:%i

adicionou uma variável User=

Certifica-se de que o arquivo correto está em /etc/systemd/system/emacs.service (anteriormente, era um link físico)

e reexecutou systemctl enable emacs

Isso fez com que funcionasse.

EDITAR O problema real aqui é que eu tinha um erro de digitação na linha 3: Documentatin

Encontrei isso verificando journalctl . Eu sugiro que qualquer um que tenha problemas com um script systemd faça o mesmo que não foi enviado nenhum erro ao stderr.

    
por 02.12.2016 / 07:35
3

ooh isso é interessante.

Escolhendo uma unidade de serviço aleatória e olhando para ela, isso depende de um alvo específico em vez de default.target . O último é simbólico ... um link configurado para um alvo específico, semanticamente, não faz sentido. (Veja systemctl set-default )

Isso pode explicar por que seu serviço é exibido como disabled depois de você ativá-lo. Tente substituir default.target em seu arquivo de serviço por multi-user.target , por exemplo.

(Não reportar um erro quando falhar ao ativar parece um defeito no systemd. Eu quase me pergunto se você agora tem um diretório /etc/systemd/system/default.target.wants ).

    
por 12.11.2016 / 01:37
1

Você tem uma variável de ambiente DISPLAY, o que significa que você deseja que o X11 seja iniciado. Então você precisa ter uma maneira de bloquear seu serviço até então.

Isso é feito usando a opção After=... .

Eu não fiz isso sozinho, então não posso dizer que funcionaria, mas é provável que algo tenha a ver com graphical.target .

[Unit]
After=graphical.target

Outra possibilidade, se o servidor X não iniciar imediatamente (ou seja, você tem uma tela de login com lightdm ou algo parecido), então você pode ter que usar WantedBy=... em vez disso:

[Unit]
WantedBy=graphical.target

Se você se cansar de fazê-lo funcionar com o systemd, talvez seja interessante observar a maneira usual como os gerentes do X-Windows o fazem funcionar.

Existe o arquivo ~/.xprofile , que funciona como o arquivo ~/.bashrc .

Há também os arquivos ~/.config/autostart/*.desktop . Ele irá iniciar automaticamente qualquer aplicativo que esteja definido lá.

Estas soluções não são de todo o sistema, no entanto, no caso de você ter vários usuários, cada um deles teria que ter sua própria entrada. Além disso, ele não inicia o aplicativo como root, mas você, em vez disso.

Como uma nota secundária, a mensagem "carregado + inativo (inativo)" significa que o systemd teve dificuldades para iniciar o processo e, como resultado, decidiu abandoná-lo . Você pode testar manualmente se o name.service funciona depois que você reinicia usando:

systemctl stop <service-name>
systemctl start <service-name>

Isto irá atualizar o status e iniciar o serviço corretamente, assumindo que as informações estejam corretas. Você pode verificar o status novamente para ver detalhes adicionais:

 systemctl status <service-name>
    
por 12.11.2016 / 00:09

Tags