Até recentemente, havia uma maneira simples e eficaz de iniciar / parar / reiniciar serviços:

service nginx start|stop|restart

Isso funcionou perfeitamente por tantos anos, ... até que alguns smart-pants decidiram melhorá-los e agora estou enfrentando sistemas Debian / Ubuntu nos quais o servicescript não faz nada (como eu devo usar as coisas como systemctl start nginx.service(muito, muito mais, sem trabalho de preenchimento automático, ...)

Minha pergunta se refere especialmente ao Debian e Ubuntu, mas também seria útil para cobrir as distros do CentOS / RedHat.

Então, há algo que pode me salvar dessas mudanças condenadas?

Caso não esteja claro, estou procurando uma maneira consistente de lidar com elas, uma que funcione no Debian 7.x, 8.x, Ubuntu LTS mais recente e não LTS.

PS. Fora do escopo desta pergunta específica, são concedidos elogios extras se a solução também cobrir a parte de habilitar e desabilitar os serviços.

Existem vários sistemas de controle de inicialização e serviço variados nas plataformas Unix ao longo de sua história complicada.

O service\chkconfigsistema baseado que você achou simples e eficaz geralmente é chamado de estilo SysVinit e foi um passo importante no caminho para algum tipo de padronização. Você encontrará esse estilo de inicialização no RHEL / CentOS (EL) até a versão 6, no Fedora até 14 e nas distribuições baseadas no Debian / Ubuntu até 2015. Não era o único sistema de inicialização disponível, o estilo BSD (mais simples) O sistema init ainda tem muitos fãs.

O SysVinit não era uma solução perfeita (o que é?) E o Systemd foi desenvolvido para superar muitos dos problemas; este é o systemctlsistema baseado em comando que você está enfrentando agora. Embora não seja universalmente apreciado (as pessoas odeiam mudanças, inchaço, etc.), não há dúvida de que está rapidamente se tornando o padrão defacto na maioria das distribuições.

Portanto, olhando imediatamente para frente, a resposta para sua pergunta original é simplesmente:
A maneira padrão de controlar serviços na maioria das distribuições Linux é agora systemctl!
Quanto tempo isso será verdadeiro é o palpite de alguém; provavelmente apenas até que algo aconteça que seja melhor e se torne amplamente adotado.

Tenho certeza de que haverá invólucros disponíveis para permitir, o seu favorito atual, os service/chkconfigcomandos para continuar a fazer principalmente coisas sãs, mas com essa curva de aprendizado específica, provavelmente é melhor não lutar contra isso. Talvez ansioso, por um tempo também haverá systemctlinvólucros para sistemas mais antigos, para tornar o gerenciamento deles juntamente com os mais atuais menos trabalhoso;)

Não faz sentido substituir o servicecomando antigo por um invólucro que chama servicectl[sic]?

Sim, mas [...] um wrapper pode lidar com isso, tornando a transição para o systemd mais suave para os usuários.

… Ou seja, como outros disseram em comentários, o que foi feito há muito tempo .

O /usr/sbin/servicecomando no Debian 8 faz parte do pacote sysvinit-utils. Está presente desde 2009. É uma adição originária do RedHat específica ao Debian ao pacote fonte sysvinit original e, como pode ser visto na leitura do script, reconhece a execução do sistema e a presença de trabalhos iniciais, desenvolvendo comandos para systemctle initctl( através de seus apelidos), respectivamente. Isso é feito desde 2013.

service name actionestá amplamente disponível, mesmo em sistemas operacionais não Linux. Até funcionará na maioria dos BSDs, pois eles também têm seus próprios servicecomandos. Há também um servicecomando shim no pacote nosh que se traduz em . Mas …system-control action name

• ... supere esse subconjunto comum e há muito menos compatibilidade ao redor.
• ... O OpenBSD não tem servicecomando.
• … Os servicecomandos do BSD têm problemas bem conhecidos de longa data sobre os quais os administradores de sistemas contam histórias de guerra há décadas.

Ativar e desativar serviços é uma situação semelhante. Embora o SuSE chkconfigprograma (disponível empacotado para o Debian e Ubuntu) é muito diferente ao do Fedora um (que está sendo escrito em inteiramente diferentes linguagens de programação, mesmo - um compilado, um interpretado), há um mínimo comum de sintaxe, com ação ser ou . Mas …chkconfig name actiononoff

• ... novamente, além desse subconjunto comum, há menos compatibilidade.
• ... não há chkconfignos BSDs, pois as ferramentas convencionais para isso são sysrco OpenBSD rcctl enablee o rcctl disable. Existem chkconfige rcctlshims no pacote nosh que são traduzidos para e .system-control enable namesystem-control disable name
• … Somente o Fedora chkconfigconhece o systemd e atua como um calço para systemctl enablee systemctl disable. O SuSE chkconfignão tem conhecimento de systemd.

Leitura adicional

• "Download sysvinit-utils: Lista de arquivos" . pacote sysvinit-utils . Pacotes Debian 8.
• script/service. init-system-helpers. Arquivo fonte Debian.
• Jonathan de Boyne Pollard (2015). telinit. Guia nosh . 1.20 Softwares de JdeBP.
• Jonathan de Boyne Pollard (2015). Não há mais problemas com o servicecomando . páginas nosh. Softwares de JdeBP.
• pacote chkconfig . Pacotes Debian 8.
• "O comando chkconfig funciona com o systemd?" . systemd . Wiki do projeto Fedora.
• "O comando service funciona com systemd?" . systemd . Wiki do projeto Fedora.
• Douglas Barton (11/12/2012). service. §8 Páginas de manual do FreeBSD.
• Antoine Jacoutot (19/08/2014). Apresente o rcctl (8), um utilitário simples para manter o rc.conf.local (8). . OpenBSD CVS.
• Jonathan de Boyne Pollard (2015). O pacote nosh . Softwares de JdeBP.

Não há uma maneira padrão de iniciar e parar serviços no Linux.

existe algo que possa me salvar dessas mudanças condenadas?

Experimente a ferramenta de gerenciamento / orquestração de configurações: Ansible , Chef , Saltstack , Puppet ou o que for.

Você pode iniciar e ativar um serviço com o Ansible:

ansible all -i inv -m service -a 'name=service-name state=started enabled=true'

Dê uma olhada na classe LinuxService no servicemódulo do Ansible :

Esta é a classe de manipulação do Serviço Linux - atualmente ela suporta uma mistura de binários e scripts init para controlar os serviços iniciados na inicialização, bem como para controlar o estado atual.

Seu problema é que o Debian / Ubuntu mudou para o novo systemdcomo um substituto do antigo sysvinit. Pergunte qual é o melhor e você iniciará uma guerra de chamas, mas você sempre pode voltar para o antigo sysvinit; verifique isso se quiser voltar.