rc.local Não funciona Debian 8

Question

Estou tentando iniciar um script Shell na inicialização / inicialização Eu tentei editar o arquivo /etc/rc.local, mas não funcionou

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/root/ark/startup.sh   #Added 
exit 0

Ele deve iniciar um script, o script sozinho funciona como um encanto (ele inicia uma sessão de tela ...)

Qualquer ajuda ou outros métodos que eu poderia usar para conseguir isso?

    

Answer 1

Esqueça sobre rc.local .

Como eu disse sobre o CentOS 7 :

Você está usando o Debian 8. Você tem o systemd. /etc/rc.local é um mecanismo de compatibilidade com versões anteriores no systemd, porque é um mecanismo de compatibilidade com versões anteriores para um mecanismo que era em si um mecanismo de compatibilidade no sistema van Smoorenburg 5 rc clone.

Como mostra a confusão na questão do AskUbuntu com hyperlink abaixo, usar /etc/rc.local pode dar errado. Em outros lugares, as pessoas ficaram surpresas pelo fato de o systemd não rodar rc.local da mesma maneira, no mesmo lugar do bootstrap, como eles estão acostumados. Outros ficaram surpresos com o fato de que o que eles configuraram em rc.local esperando as formas antigas de fazer as coisas é completamente desfeito pelos gostos das novas regras udev , NetworkManager, systemd-logind , systemd-resolved ou vários " Kit "s.

Esqueça o rc.local . Não é o caminho a percorrer. Você tem o Debian 8. Portanto, faça uma unidade de serviço apropriada e não comece de um ponto que esteja a dois níveis de compatibilidade com versões anteriores. (No Ubuntu, ele é três vezes removido, o clone do System 5 rc que o seguiu foi então substituído por duas vezes , há mais de uma década pelo upstart e depois pelo systemd.)

Não inicie o processo de execução com o systemd, fazendo um script startup.sh e, em seguida, invocando-o a partir de uma unidade de serviço systemd. Essa ideia leva muito rapidamente ao território do systemd House of Horror . Crie uma unidade de serviço que descreva o máximo possível da configuração e execução do processo diretamente. Use um script de shell wrapper apenas quando você acertar as limitações disso. E certifique-se de que o seu shell script wrap no mínimo usa exec para sobrepor o programa final do programa.

Você não diz qual é esse serviço. Você menciona o uso de screen , mas isso é freqüentemente abusado como um Supervisor de Daemon do Poor Man e pode não ser o meio de executar seu serviço em um gerenciador de serviços real . Eu vejo a palavra "arca" lá, que em conjunto com o potencial abuso de screen traz à mente duas coisas:

• A primeira regra para migrar para o systemd .
• Que essa regra foi demonstrada, mais uma vez, outra pessoa que já escreveu uma unidade de serviço, me espancou por 4 dias, em link em 2015.

Leitura adicional

• link
• link
• Jonathan de Boyne Pollard (2015). A casa do sistema de terror . Respostas frequentemente dadas.

Answer 2

Se você estiver usando o systemd completo, os scripts padrão do sysvinit serão ignorados. Se você quiser usar scripts sysvinit você precisa instalar o systemd-shim