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

20

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

Quero que isso inicie na inicialização, por isso entrei systemctl enable emacs

No entanto, cada vez que meu serviço é reiniciado, systemctl status emacsmostra:

● 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, inserir systemctl start emacse verificar 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 obter esse processo para iniciar com êxito na inicialização?

systemd

— Startec
fonte

9

Não tenho idéia do porquê, mas para fazer isso funcionar, eu:

excluído Environment=DISPLAY=:%i

adicionou uma User=variável

Verifique se o arquivo correto está dentro /etc/systemd/system/emacs.service(anteriormente, havia sido um link físico)

e re-correu systemctl enable emacs

Isso fez funcionar.

EDIT O verdadeiro problema aqui é que eu tive um erro de digitação na linha 3: Documentatin

Eu encontrei isso verificando journalctl. Sugiro que qualquer pessoa que tenha problemas com um script systemd faça o mesmo, pois não houve erro enviado ao stderr.

— Startec
fonte

Isso também funciona em uma reinicialização? Acho que se o modo daemon não exigir uma conexão X11, não será necessário After=...mencioná-lo.

— Alexis Wilke #:

11

Sim, funciona após a reinicialização. Este não é um Emacs gráfico, portanto, não é necessário X11. Essa foi apenas uma linha que copiei de um exemplo e não prestei atenção.

— Iniciado

3

ooh isso é interessante.

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

Isso pode explicar por que seu serviço é exibido disableddepois que você o habilita. Tente substituir default.targetno seu arquivo de serviço por multi-user.target, por exemplo.

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

— sourcejedi
fonte

O comando journalctl informa o que foi interrompido (por que a ativação falhou, por exemplo.) Quanto ao link, não é necessário se você criar seu próprio serviço pessoal. Ele não importa se você criar um pacote que você quer que os outros para instalar / remover, etc.

— Alexis Wilke

@AlexisWilke Isso seria ainda pior! Por que seria escrito para relatar alguns erros ao stderr e outros ao diário?

— sourcejedi

Ele escreve tudo no diário. Pelo que vi, você vê apenas um erro muito básico e específico do sistema se ele não pôde iniciar o daemon.

— Alexis Wilke

2

O usuário não relatou sequer um erro básico, eles acreditavam que a operação havia sido bem-sucedida e, portanto, continuaram a reinicialização. no valor nominal, há um defeito no systemd. Os usuários também têm modos de falha, mas não me pareceu que ignorar completamente uma mensagem de erro era muito provável nesta pergunta.

— sourcejedi

11

@sourcejedi Não tenho idéia de como você sabia disso, mas sim, agora tenho uma lista no /etc/systemd/system/default.target.wants Inside que é meus arquivos de serviço. E sim, eu não tinha ideia de que havia algum erro.

— Startec

1

Você tem uma variável de ambiente DISPLAY, ou seja, 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 After=...opção .

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

[Unit]
After=graphical.target

Outra possibilidade, se o servidor X não iniciar imediatamente (ou seja, você tiver uma tela de login com lightdm ou algo semelhante), poderá ser necessário WantedBy=...:

[Unit]
WantedBy=graphical.target

Se você se cansar de fazê-lo funcionar com o systemd, convém observar a maneira usual de os gerentes do X-Windows fazerem o trabalho.

Existe o ~/.xprofilearquivo, que funciona como o ~/.bashrcarquivo.

Há também os ~/.config/autostart/*.desktoparquivos. Ele iniciará automaticamente quaisquer aplicativos definidos lá.

Essas soluções não são abrangentes ao sistema, no entanto, caso você tenha vários usuários, cada um deles deverá ter sua própria entrada. Além disso, ele não inicia o aplicativo como root, mas você.

Como observação lateral, a mensagem "carregado + inativo (inoperante)" significa que o sistema teve dificuldades para iniciar o processo e, como resultado, decidiu abandoná- lo. Você pode testar manualmente se name.servicefunciona depois de reiniciar usando:

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

Isso 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>

— Alexis Wilke
fonte

2

Hum, apaguei toda a linha e nada mudou. Além disso, (como eu disse na minha pergunta), ele começa bem executando o systemctl start emacs).

— Startec

veja minha pergunta atualizada. Eu tive um erro de digitação Documentatin. Sua dica sobre journalctlme ajudou aqui.

— Startec

0

É um bug em vários arquivos de serviço do Debian:

# systemctl enable watchdog
Synchronizing state of watchdog.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable watchdog
# find /etc/systemd/ | grep watch
# tail -n2 /lib/systemd/system/watchdog.service

[Install]

https://www.raspberrypi.org/forums/viewtopic.php?f=82&t=218609&p=1406567#p1406567 https://forum.armbian.com/topic/9115-still-dont-know-where-to-report -bugs-watchdogservice-recusa-iniciar-devido-a-quebrado-service-file /

A correção do nível de distribuição é

echo "WantedBy=default.target" >> /lib/systemd/system/watchdog.service
systemctl daemon-reexec
systemctl enable watchdog
systemctl stop watchdog.service
systemctl start watchdog.service

Existem muitas alternativas manuais para isso.

— Benoit-Pierre DEMAINE
fonte