Não quero fazer a coisa certa criando um novo script systemd, só quero que meu antigo script init funcione novamente agora que atualizei meu sistema para um sistema operacional que está usando o systemd.
Pesquisei brevemente como converter scripts init e como escrever scripts systemd, mas tenho certeza de que aprender corretamente e fazer direito levaria várias horas.
A situação atual é:
systemctl start solr
Failed to start solr.service: Unit solr.service failed to load: No such file or directory.
E:
sudo service solr start
Failed to start solr.service: Unit solr.service failed to load: No such file or directory.
No momento, só quero voltar ao trabalho. Qual é o caminho de menor resistência para fazer isso funcionar novamente?
Atualizações
Eu não queria descobrir tudo isso - realmente não queria - mas preciso e descobri minha primeira pista:
sudo systemctl enable solr
Synchronizing state for solr.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d solr defaults
insserv: warning: script 'K01solr' missing LSB tags and overrides
insserv: warning: script 'solr' missing LSB tags and overrides
Executing /usr/sbin/update-rc.d solr enable
update-rc.d: error: solr Default-Start contains no runlevels, aborting.
A página de incompatibilidades do systemd diz que:
As informações de dependência do cabeçalho LSB são importantes. As implementações de SysV em muitas distribuições não usavam as informações de dependência codificadas nos cabeçalhos de script de inicialização LSB ou as usavam apenas de maneiras muito limitadas. Por isso, muitas vezes estão incorretos ou incompletos. systemd, no entanto, interpreta totalmente esses cabeçalhos e os segue de perto no tempo de execução
Acho que isso significa que meu script não funcionará até que seja corrigido.
O roteiro em questão:
#!/bin/sh
# Prerequisites:
# 1. Solr needs to be installed at /usr/local/solr/example
# 2. daemon needs to be installed
# 3. Script needs to be executed by root
# 4. $INSTALL_ROOT must be set
# This script will launch Solr in a mode that will automatically respawn if it
# crashes. Output will be sent to /var/log/solr/solr.log. A pid file will be
# created in the standard location.
start () {
echo -n "Starting solr..."
# Reset ulimit or else get issues with too many open files (https://issues.apache.org/jira/browse/SOLR-4)
ulimit -n 10000
# start daemon
daemon --chdir='/usr/local/solr/example' --command "java -jar -server start.jar -DINSTALL_ROOT=$INSTALL_ROOT" --respawn --output=/var/log/solr/solr.log --name=solr --verbose
RETVAL=$?
if [ $RETVAL = 0 ]
then
echo "done."
else
echo "failed. See error code for more information."
fi
return $RETVAL
}
stop () {
# stop daemon
echo -n "Stopping solr..."
daemon --stop --name=solr --verbose
RETVAL=$?
if [ $RETVAL = 0 ]
then
echo "done."
else
echo "failed. See error code for more information."
fi
return $RETVAL
}
restart () {
daemon --restart --name=solr --verbose
}
status () {
# report on the status of the daemon
daemon --running --verbose --name=solr
return $?
}
case "$1" in
start)
start
;;
status)
status
;;
stop)
stop
;;
restart)
stop
sleep 15
start
;;
*)
echo $"Usage: solr {start|status|stop|restart}"
exit 3
;;
esac
exit $RETVAL
Sério, um arquivo de unidade systemd é trivial de escrever para um serviço como este ... ou para a maioria dos serviços.
Isso deve levá-lo a cerca de 95% do caminho até lá. Coloque isso, por exemplo,
/etc/systemd/system/solr.service
Observe as coisas que não estão aqui, como o arquivo de log e tal; O systemd irá capturar e registrar automaticamente a saída do serviço sob o nome do serviço.
Para mim, foi mais fácil apenas adicionar o bloco de informações init no cabeçalho, conforme sugerido aqui :
Em seguida, execute
sudo systemctl enable solr
.Outra solução para usar o script init legado solr com systemd:
É mais conveniente executar o Solr usando o script de início fornecido .
O arquivo de unidade do systemd se parece com isso:
Observe que você também pode usar suas variáveis de ambiente adicionando
EnvironmentFile
à[Service]
seção. O scriptbin/solr
respeita variáveis de ambiente, basta dar uma olhada nele.Testado no Debian: Adicione '_SYSTEMCTL_SKIP_REDIRECT=OHYES' no início do script.
Os fanboys do systemd podem não gostar, mas ei, eu não gosto do systemd, então aí :).
Eu tive o mesmo erro ao tentar usar um script de inicialização LSB no CentOS 7. A causa raiz acabou sendo que o script era um link simbólico. Depois de substituído por uma cópia do original, tudo funcionou bem.
A resposta mais simples para a pergunta do OP é:
chkconfig {{service-name}} on
- isso habilitará o serviço SysV existente sem mais nada para fazer. Eu acho que não é inteiramente a questão original se ele está rodando em uma espécie de modo legado, mas está me permitindo rodar serviços antigos do CentOS 6 na versão 7 sem nenhum trabalho extra.Depois de executar esse comando, você pode controlar o serviço por meio de
systemctl
comandos padrão, pois ele cria a unidade wrapper-thingmyjigwhatsit.