Fino a poco tempo fa c'era un modo semplice ed efficace per avviare / arrestare / riavviare i servizi:

service nginx start|stop|restart

Questo ha funzionato perfettamente per così tanti anni, ... fino a quando alcuni smart-pants hanno deciso di migliorarli e ora sto affrontando sistemi Debian / Ubuntu in cui lo servicescript non fa nulla (come dovrei usare le cose come systemctl start nginx.service(molto più a lungo, nessuna funzione di completamento automatico, ...)

La mia domanda si riferisce in particolare a Debian e Ubuntu ma sarebbe utile anche coprire le distro CentOS / RedHat.

Quindi, c'è qualcosa che può salvarmi da questi cambiamenti condannati?

Nel caso in cui non fosse chiaro, sto cercando un modo coerente per gestirli, uno che funzionerebbe su Debian 7.x, 8.x, l'ultima versione di Ubuntu LTS e non LTS.

PS. Al di fuori dell'ambito di questa domanda specifica, ma ulteriori riconoscimenti concessi se la soluzione coprirebbe anche la parte di abilitazione e disabilitazione per i servizi.

Ci sono stati diversi sistemi di controllo di avvio e servizi su piattaforme Unix nel corso della sua storia intricata.

Il service\chkconfigsistema basato che hai trovato semplice ed efficace è generalmente indicato come stile SysVinit ed è stato un grande passo avanti verso una sorta di standardizzazione. Troverai questo stile di avvio su RHEL / CentOS (EL) fino alla versione 6, Fedora fino a 14 e su distribuzioni basate su Debian / Ubuntu fino al 2015. Non è stato l'unico sistema di avvio in circolazione, lo stile (più semplice) di BSD Il sistema init ha ancora molti fan.

SysVinit non era una soluzione perfetta (cos'è?) E Systemd è stato ideato per superare molti dei problemi; questo è il systemctlsistema basato sui comandi che stai sperimentando. Sebbene non sia universalmente apprezzato (le persone odiano il cambiamento, il gonfiore, ecc.), Non c'è dubbio che sta rapidamente diventando lo standard defacto nella maggior parte delle distribuzioni.

Pertanto, guardare subito avanti la risposta alla tua domanda originale è semplicemente:
il modo standard per controllare i servizi nella maggior parte delle distribuzioni Linux è ora systemctl!
Per quanto tempo ciò sarà vero è l'ipotesi di chiunque; probabilmente solo fino a quando succederà qualcosa che è meglio e viene ampiamente adottato.

Sono sicuro che ci saranno involucri disponibili per consentire, il tuo preferito preferito, i service/chkconfigcomandi per continuare a fare cose per lo più sane, ma con questa particolare curva di apprendimento è probabilmente meglio non combatterla. Forse non vedo l'ora, per un po 'ci saranno anche systemctlinvolucri per i sistemi più vecchi, per rendere meno facile la loro gestione insieme a quelli più attuali;)

Non ha senso sostituire il vecchio servicecomando con un wrapper che chiama invece servicectl[sic]?

Sì, ma [...] un wrapper potrebbe gestirlo, rendendo la transizione a systemd più agevole per gli utenti.

... che è, come altri hanno detto nei commenti, ciò che è stato fatto da molto tempo .

Il /usr/sbin/servicecomando su Debian 8 fa parte del pacchetto sysvinit-utils. È lì dal 2009. È un'aggiunta di RedHat specifica per Debian al pacchetto sorgente originale sysvinit e, come si può vedere dalla lettura dello script, riconosce sia l'esecuzione del sistema che la presenza di lavori di avvio, dando comandi systemctle initctl( tramite i suoi alias) rispettivamente. Lo ha fatto dal 2013.

service name actionè abbastanza ampiamente disponibile anche su sistemi operativi non Linux. Funzionerà anche sulla maggior parte dei BSD, poiché anche loro hanno i loro servicecomandi. C'è anche un servicecomando shim nel pacchetto nosh che si traduce in . Ma …system-control action name

• ... vai oltre questo sottoinsieme comune e c'è molta meno compatibilità ovunque.
• ... OpenBSD non ha alcun servicecomando.
• ... i servicecomandi BSD hanno noti problemi di lunga data di cui gli amministratori di sistema raccontano storie di guerra da decenni.

Abilitare e disabilitare i servizi è una situazione simile. Sebbene il chkconfigprogramma SuSE (disponibile in pacchetto per Debian e Ubuntu) sia molto diverso da quello di Fedora (essendo scritti in linguaggi di programmazione completamente diversi, anche - uno compilato, uno interpretato), esiste una sintassi minima comune , con azione in corso o . Ma …chkconfig name actiononoff

• ... ancora una volta, oltre questo sottoinsieme comune c'è meno compatibilità.
• ... Non c'è chkconfigsui BSD, poiché gli strumenti convenzionali per questo sono uno sysrco il più recente OpenBSD rcctl enablee rcctl disable. Ci sono chkconfige rcctlspessori nel pacchetto nosh che si traducono in e .system-control enable namesystem-control disable name
• ... solo la Fedora chkconfigconosce systemd e funge da shim per systemctl enablee systemctl disable. Il SuSE chkconfignon ha alcuna conoscenza di systemd.

Ulteriori letture

• "Scarica sysvinit-utils: Elenco dei file" . pacchetto sysvinit-utils . Pacchetti Debian 8.
• script/service. init-system-aiutanti. Archivio dei sorgenti Debian.
• Jonathan de Boyne Pollard (2015). telinit. Guida di nosh . 1.20. Software di JdeBP.
• Jonathan de Boyne Pollard (2015). Non più problemi con il servicecomando . pagine di nosh. Software di JdeBP.
• pacchetto chkconfig . Pacchetti Debian 8.
• "Il comando chkconfig funziona con systemd?" . systemd . Wiki del progetto Fedora.
• "Il comando di servizio funziona con systemd?" . systemd . Wiki del progetto Fedora.
• Douglas Barton (2012-12-11). service. § 8. Pagine del manuale di FreeBSD.
• Antoine Jacoutot (2014-08-19). Introdurre rcctl (8), una semplice utility per mantenere rc.conf.local (8). . CVS di OpenBSD.
• Jonathan de Boyne Pollard (2015). Il pacchetto nosh . Software di JdeBP.

Non esiste un modo standard per avviare e arrestare i servizi su Linux.

c'è qualcosa che può salvarmi da questi cambiamenti condannati?

Prova lo strumento di gestione / orchestrazione della configurazione: Ansible , Chef , Saltstack , Puppet o altro.

Puoi avviare e abilitare un servizio con Ansible:

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

Dai un'occhiata alla classe LinuxService nel servicemodulo Ansible :

Questa è la classe di manipolazione del servizio Linux: attualmente supporta una combinazione di binari e script di inizializzazione per il controllo dei servizi avviati all'avvio, nonché per il controllo dello stato corrente.

Il tuo problema è che Debian / Ubuntu sono passati al nuovo systemdin sostituzione del vecchio sysvinit. Chiedi quale è meglio e inizierai una guerra di fiamma, ma puoi sempre tornare al vecchio sysvinit, controlla questo se vuoi tornare indietro.