Is there a standard way to start and stop services on Linux?
Clash Royale CLAN TAG#URR8PPP
Until recently there was a simple and effective way to start/stop/restart services:
service nginx start|stop|restart
This worked perfectly for so many years,... until some smart-pants decided to improve them and now I am facing with Debian/Ubuntu systems where the service script does nothing (as I am supposed to use the stuff like systemctl start nginx.service (much much longer, no auto-complete working,...)
My question refers specially to Debian and Ubuntu but it would also be helpful to cover CentOS/RedHat distros too.
So, is there something that can save me from this doomed changes?
In case it was not clear, I am looking for a consistent way to deal with those, one that would work on Debian 7.x, 8.x, latest Ubuntu LTS and non-LTS.
PS. Outside the scope of this specific question, but extra kudos granted if the solution would also cover the enable and disable part for the services.
debian systemd init.d sysvinit
edited Oct 1 '15 at 10:57
terdon♦
131k32257436
asked Oct 1 '15 at 6:53
sorinsorin
4782713
|
show 4 more comments
Until recently there was a simple and effective way to start/stop/restart services:
service nginx start|stop|restart
This worked perfectly for so many years,... until some smart-pants decided to improve them and now I am facing with Debian/Ubuntu systems where the service script does nothing (as I am supposed to use the stuff like systemctl start nginx.service (much much longer, no auto-complete working,...)
My question refers specially to Debian and Ubuntu but it would also be helpful to cover CentOS/RedHat distros too.
So, is there something that can save me from this doomed changes?
In case it was not clear, I am looking for a consistent way to deal with those, one that would work on Debian 7.x, 8.x, latest Ubuntu LTS and non-LTS.
PS. Outside the scope of this specific question, but extra kudos granted if the solution would also cover the enable and disable part for the services.
debian systemd init.d sysvinit
edited Oct 1 '15 at 10:57
terdon♦
131k32257436
asked Oct 1 '15 at 6:53
sorinsorin
4782713
5
Tab completion works for systemctl for me... And, like it or not, systemd is the de facto standard now: may as well get used to it.
– jasonwryan
Oct 1 '15 at 6:55
1
Extra: if service command become useless, can I remove it? What package provides it?
– sorin
Oct 1 '15 at 6:55
3
Doesn't make sense to replace the oldservicecommand with a wrapper that calls servicectl instead?
– sorin
Oct 1 '15 at 6:59
4
@jasonwryan Yes, but you also can do just that, and a wrapper could handle it, making the transition to systemd smoother for the users.
– Dmitry Grigoryev
Oct 1 '15 at 7:29
2
Doesservicereally do nothing for you? It works as expected on my LMDE (which is basically Debian testing), I didn't think that was an LMDE-specific thing. It also works as expected in my Ubuntu VM.
– terdon♦
Oct 1 '15 at 10:56
|
show 4 more comments
Until recently there was a simple and effective way to start/stop/restart services:
service nginx start|stop|restart
This worked perfectly for so many years,... until some smart-pants decided to improve them and now I am facing with Debian/Ubuntu systems where the service script does nothing (as I am supposed to use the stuff like systemctl start nginx.service (much much longer, no auto-complete working,...)
My question refers specially to Debian and Ubuntu but it would also be helpful to cover CentOS/RedHat distros too.
So, is there something that can save me from this doomed changes?
In case it was not clear, I am looking for a consistent way to deal with those, one that would work on Debian 7.x, 8.x, latest Ubuntu LTS and non-LTS.
PS. Outside the scope of this specific question, but extra kudos granted if the solution would also cover the enable and disable part for the services.
debian systemd init.d sysvinit
edited Oct 1 '15 at 10:57
terdon♦
131k32257436
asked Oct 1 '15 at 6:53
sorinsorin
4782713
Until recently there was a simple and effective way to start/stop/restart services:
service nginx start|stop|restart
This worked perfectly for so many years,... until some smart-pants decided to improve them and now I am facing with Debian/Ubuntu systems where the service script does nothing (as I am supposed to use the stuff like systemctl start nginx.service (much much longer, no auto-complete working,...)
My question refers specially to Debian and Ubuntu but it would also be helpful to cover CentOS/RedHat distros too.
So, is there something that can save me from this doomed changes?
In case it was not clear, I am looking for a consistent way to deal with those, one that would work on Debian 7.x, 8.x, latest Ubuntu LTS and non-LTS.
PS. Outside the scope of this specific question, but extra kudos granted if the solution would also cover the enable and disable part for the services.
debian systemd init.d sysvinit
debian systemd init.d sysvinit
edited Oct 1 '15 at 10:57
terdon♦
131k32257436
asked Oct 1 '15 at 6:53
sorinsorin
4782713
edited Oct 1 '15 at 10:57
terdon♦
131k32257436
asked Oct 1 '15 at 6:53
sorinsorin
4782713
edited Oct 1 '15 at 10:57
terdon♦
131k32257436
edited Oct 1 '15 at 10:57
terdon♦
131k32257436
edited Oct 1 '15 at 10:57
terdon♦
131k32257436
131k32257436
asked Oct 1 '15 at 6:53
sorinsorin
4782713
asked Oct 1 '15 at 6:53
sorinsorin
4782713
asked Oct 1 '15 at 6:53
sorinsorin
4782713
4782713
5
Tab completion works for systemctl for me... And, like it or not, systemd is the de facto standard now: may as well get used to it.
– jasonwryan
Oct 1 '15 at 6:55
1
Extra: if service command become useless, can I remove it? What package provides it?
– sorin
Oct 1 '15 at 6:55
3
Doesn't make sense to replace the oldservicecommand with a wrapper that calls servicectl instead?
– sorin
Oct 1 '15 at 6:59
4
@jasonwryan Yes, but you also can do just that, and a wrapper could handle it, making the transition to systemd smoother for the users.
– Dmitry Grigoryev
Oct 1 '15 at 7:29
2
Doesservicereally do nothing for you? It works as expected on my LMDE (which is basically Debian testing), I didn't think that was an LMDE-specific thing. It also works as expected in my Ubuntu VM.
– terdon♦
Oct 1 '15 at 10:56
|
show 4 more comments
5
Tab completion works for systemctl for me... And, like it or not, systemd is the de facto standard now: may as well get used to it.
– jasonwryan
Oct 1 '15 at 6:55
1
Extra: if service command become useless, can I remove it? What package provides it?
– sorin
Oct 1 '15 at 6:55
3
Doesn't make sense to replace the oldservicecommand with a wrapper that calls servicectl instead?
– sorin
Oct 1 '15 at 6:59
4
@jasonwryan Yes, but you also can do just that, and a wrapper could handle it, making the transition to systemd smoother for the users.
– Dmitry Grigoryev
Oct 1 '15 at 7:29
2
Doesservicereally do nothing for you? It works as expected on my LMDE (which is basically Debian testing), I didn't think that was an LMDE-specific thing. It also works as expected in my Ubuntu VM.
– terdon♦
Oct 1 '15 at 10:56
5
5
Tab completion works for systemctl for me... And, like it or not, systemd is the de facto standard now: may as well get used to it.
– jasonwryan
Oct 1 '15 at 6:55
Tab completion works for systemctl for me... And, like it or not, systemd is the de facto standard now: may as well get used to it.
– jasonwryan
Oct 1 '15 at 6:55
1
1
Extra: if service command become useless, can I remove it? What package provides it?
– sorin
Oct 1 '15 at 6:55
Extra: if service command become useless, can I remove it? What package provides it?
– sorin
Oct 1 '15 at 6:55
3
3
Doesn't make sense to replace the old
service command with a wrapper that calls servicectl instead?– sorin
Oct 1 '15 at 6:59
Doesn't make sense to replace the old
service command with a wrapper that calls servicectl instead?– sorin
Oct 1 '15 at 6:59
4
4
@jasonwryan Yes, but you also can do just that, and a wrapper could handle it, making the transition to systemd smoother for the users.
– Dmitry Grigoryev
Oct 1 '15 at 7:29
@jasonwryan Yes, but you also can do just that, and a wrapper could handle it, making the transition to systemd smoother for the users.
– Dmitry Grigoryev
Oct 1 '15 at 7:29
2
2
Does
service really do nothing for you? It works as expected on my LMDE (which is basically Debian testing), I didn't think that was an LMDE-specific thing. It also works as expected in my Ubuntu VM.– terdon♦
Oct 1 '15 at 10:56
Does
service really do nothing for you? It works as expected on my LMDE (which is basically Debian testing), I didn't think that was an LMDE-specific thing. It also works as expected in my Ubuntu VM.– terdon♦
Oct 1 '15 at 10:56
|
show 4 more comments
4 Answers
4
active
oldest
votes
There have been a number of varied boot and service control systems across Unix platforms over its tangled history.
The servicechkconfig based system you found simple and effective is generally referred to as SysVinit style and was a major step along the way to some sort of standardization. You will find this style of boot on RHEL/CentOS(EL) through the 6 release, Fedora through 14, and on Debian/Ubuntu based distributions up until 2015. It was not the only boot system around though, the (simpler) BSD style init system still has many fans.
SysVinit was not a perfect solution (what is?) and Systemd was devised to overcome many of the issues; this is the systemctl command based system you are now experiencing. Although it is not universally liked (people hate change, bloat, etc) there is no doubt that it is fast becoming the defacto standard across the majority of distributions.
Therefore, looking immediately forward the answer to your original question is simply:
The standard way to control services across most Linux distributions is now systemctl!
How long this will hold true is anyone's guess; probably just until something comes along that is better and becomes widely adopted.
I'm sure there will be wrappers available to allow, your current favorite, the service/chkconfig commands to continue to do mostly sane things, but with this particular learning curve it is probably best not to fight it. Maybe looking forward, for a time there'll also be systemctl wrappers for older systems, to make managing them alongside more current ones less of a pain ;)
answered Oct 1 '15 at 10:29
DanSutDanSut
437312
And prior to this was xinetd, and prior to that was inetd
– jas-
Oct 1 '15 at 11:06
@jas- I think the inetd's are really services themselves, I believe they can exist within all boot systems. They are a special kind of service in that they provide an alternative for some other services to running as full services, by instead providing them on-demand. I understand where you are coming from in the context of this Q though, just another way of starting services.
– DanSut
Oct 1 '15 at 11:21
In all distributions; gentoo, centos, redhat, debian, ubuntu etc., xinetd and previously inetd consisted of small shell script to start, stop & reload configurations for various services, but yes you are correct they were indeed a service just like systemd is.
– jas-
Oct 3 '15 at 12:37
Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) upstart.ubuntu.com, and it's been possible to switch Debian away from sysvinit for quite a few years...
– James Tocknell
Oct 6 '15 at 0:19
add a comment |
Doesn't [it] make sense to replace the old
servicecommand with a wrapper that callsservicectl[sic] instead?Yes, but […] a wrapper could handle it, making the transition to systemd smoother for the users.
… which is, as others have said in comments, what has been done long since.
The /usr/sbin/service command on Debian 8 is part of the sysvinit-utils package. It has been there since 2009. It's a Debian-specific RedHat-originated addition to the original sysvinit source package, and as can be seen from reading the script it recognizes both systemd running and the presence of upstart jobs, farming out commands to systemctl and initctl (via its aliases) respectively. This it has done since 2013.
service name action is quite widely available even on non-Linux operating systems. It will even work on most of the BSDs, as they too have their own service commands. There is also a shim service command in the nosh package that translates to system-control action name. But …
- … get beyond this common subset, and there's far less compatibility all around.
- … OpenBSD has no
servicecommand. - … the BSD
servicecommands have well-known problems of long standing that system administrators have been telling war stories about for decades.
Enabling and disabling services is a similar situation. Although the SuSE chkconfig program (available packaged for Debian and Ubuntu) is very different to the the Fedora one (they being written in entirely different programming languages, even — one compiled, one interpreted), there is a common minimal chkconfig name action syntax, with action being on or off. But …
- … again, beyond this common subset there is less compatibility.
- … there's no
chkconfigon the BSDs, as the conventional tools for this are eithersysrcor the more recent OpenBSDrcctl enableandrcctl disable. There arechkconfigandrcctlshims in the nosh package that translate tosystem-control enable nameandsystem-control disable name. - … only the Fedora
chkconfigknows about systemd and acts as a shim forsystemctl enableandsystemctl disable. The SuSEchkconfighas no knowledge of systemd.
Further reading
"Download sysvinit-utils: List of files". sysvinit-utils package. Debian 8 packages.script/service. init-system-helpers. Debian source archive.- Jonathan de Boyne Pollard (2015).
telinit. nosh Guide. 1.20. JdeBP's Softwares. - Jonathan de Boyne Pollard (2015). No more problems with the
servicecommand. nosh pages. JdeBP's Softwares.
chkconfig package. Debian 8 packages.
"Does chkconfig command work with systemd?". systemd. Fedora project wiki.
"Does service command work with systemd?". systemd. Fedora project wiki.- Douglas Barton (2012-12-11).
service. §8. FreeBSD Manual Pages. - Antoine Jacoutot (2014-08-19). Introduce rcctl(8), a simple utility for maintaining rc.conf.local(8).. OpenBSD CVS.
- Jonathan de Boyne Pollard (2015). The nosh package. JdeBP's Softwares.
edited Jan 31 at 15:51
Stephen Kitt
173k24391467
answered Oct 4 '15 at 13:48
JdeBPJdeBP
35.2k470165
add a comment |
There is no standard way to start and stop services on Linux.
is there something that can save me from this doomed changes?
Try the configuration management/orchestration tool: Ansible, Chef, Saltstack, Puppet or whatever.
You can start and enable a service with Ansible:
ansible all -i inv -m service -a 'name=service-name state=started enabled=true'
Take a look at the LinuxService class in the Ansible's service module:
This is the Linux Service manipulation class - it is currently supporting
a mixture of binaries and init scripts for controlling services started at
boot, as well as for controlling the current state.
answered Oct 2 '15 at 2:26
Evgeny VereshchaginEvgeny Vereshchagin
3,31242236
Somehow it seems that Ubuntu guys were able to keep the service script working after switching to systemd. Looking inside it seems to be smart enough to use the right backend. Cannot say the same about Debian.
– sorin
Oct 2 '15 at 8:41
@sorin, well, service(8): use systemctl on machines that run systemd. But When running "service foo stop" and foo happens to be a service that has one or more .socket files, we also stop the .socket units. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 11:49
@sorin, also The reload action falls back to the sysv init script just in case the systemd service file does not (yet) support reload for a specific service.. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 12:10
add a comment |
Your problem is that Debian/Ubuntu have switched to the new systemd as a replacement of the old sysvinit. Ask which one is better and you will start a flame war, but you can allways switch back to the old sysvinit, check this if you want to go back.
answered Oct 1 '15 at 10:38
YoMismoYoMismo
3,0661925
add a comment |
protected by Anthon Apr 16 '16 at 4:39
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
There have been a number of varied boot and service control systems across Unix platforms over its tangled history.
The servicechkconfig based system you found simple and effective is generally referred to as SysVinit style and was a major step along the way to some sort of standardization. You will find this style of boot on RHEL/CentOS(EL) through the 6 release, Fedora through 14, and on Debian/Ubuntu based distributions up until 2015. It was not the only boot system around though, the (simpler) BSD style init system still has many fans.
SysVinit was not a perfect solution (what is?) and Systemd was devised to overcome many of the issues; this is the systemctl command based system you are now experiencing. Although it is not universally liked (people hate change, bloat, etc) there is no doubt that it is fast becoming the defacto standard across the majority of distributions.
Therefore, looking immediately forward the answer to your original question is simply:
The standard way to control services across most Linux distributions is now systemctl!
How long this will hold true is anyone's guess; probably just until something comes along that is better and becomes widely adopted.
I'm sure there will be wrappers available to allow, your current favorite, the service/chkconfig commands to continue to do mostly sane things, but with this particular learning curve it is probably best not to fight it. Maybe looking forward, for a time there'll also be systemctl wrappers for older systems, to make managing them alongside more current ones less of a pain ;)
answered Oct 1 '15 at 10:29
DanSutDanSut
437312
And prior to this was xinetd, and prior to that was inetd
– jas-
Oct 1 '15 at 11:06
@jas- I think the inetd's are really services themselves, I believe they can exist within all boot systems. They are a special kind of service in that they provide an alternative for some other services to running as full services, by instead providing them on-demand. I understand where you are coming from in the context of this Q though, just another way of starting services.
– DanSut
Oct 1 '15 at 11:21
In all distributions; gentoo, centos, redhat, debian, ubuntu etc., xinetd and previously inetd consisted of small shell script to start, stop & reload configurations for various services, but yes you are correct they were indeed a service just like systemd is.
– jas-
Oct 3 '15 at 12:37
Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) upstart.ubuntu.com, and it's been possible to switch Debian away from sysvinit for quite a few years...
– James Tocknell
Oct 6 '15 at 0:19
add a comment |
There have been a number of varied boot and service control systems across Unix platforms over its tangled history.
The servicechkconfig based system you found simple and effective is generally referred to as SysVinit style and was a major step along the way to some sort of standardization. You will find this style of boot on RHEL/CentOS(EL) through the 6 release, Fedora through 14, and on Debian/Ubuntu based distributions up until 2015. It was not the only boot system around though, the (simpler) BSD style init system still has many fans.
SysVinit was not a perfect solution (what is?) and Systemd was devised to overcome many of the issues; this is the systemctl command based system you are now experiencing. Although it is not universally liked (people hate change, bloat, etc) there is no doubt that it is fast becoming the defacto standard across the majority of distributions.
Therefore, looking immediately forward the answer to your original question is simply:
The standard way to control services across most Linux distributions is now systemctl!
How long this will hold true is anyone's guess; probably just until something comes along that is better and becomes widely adopted.
I'm sure there will be wrappers available to allow, your current favorite, the service/chkconfig commands to continue to do mostly sane things, but with this particular learning curve it is probably best not to fight it. Maybe looking forward, for a time there'll also be systemctl wrappers for older systems, to make managing them alongside more current ones less of a pain ;)
answered Oct 1 '15 at 10:29
DanSutDanSut
437312
And prior to this was xinetd, and prior to that was inetd
– jas-
Oct 1 '15 at 11:06
@jas- I think the inetd's are really services themselves, I believe they can exist within all boot systems. They are a special kind of service in that they provide an alternative for some other services to running as full services, by instead providing them on-demand. I understand where you are coming from in the context of this Q though, just another way of starting services.
– DanSut
Oct 1 '15 at 11:21
In all distributions; gentoo, centos, redhat, debian, ubuntu etc., xinetd and previously inetd consisted of small shell script to start, stop & reload configurations for various services, but yes you are correct they were indeed a service just like systemd is.
– jas-
Oct 3 '15 at 12:37
Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) upstart.ubuntu.com, and it's been possible to switch Debian away from sysvinit for quite a few years...
– James Tocknell
Oct 6 '15 at 0:19
add a comment |
There have been a number of varied boot and service control systems across Unix platforms over its tangled history.
The servicechkconfig based system you found simple and effective is generally referred to as SysVinit style and was a major step along the way to some sort of standardization. You will find this style of boot on RHEL/CentOS(EL) through the 6 release, Fedora through 14, and on Debian/Ubuntu based distributions up until 2015. It was not the only boot system around though, the (simpler) BSD style init system still has many fans.
SysVinit was not a perfect solution (what is?) and Systemd was devised to overcome many of the issues; this is the systemctl command based system you are now experiencing. Although it is not universally liked (people hate change, bloat, etc) there is no doubt that it is fast becoming the defacto standard across the majority of distributions.
Therefore, looking immediately forward the answer to your original question is simply:
The standard way to control services across most Linux distributions is now systemctl!
How long this will hold true is anyone's guess; probably just until something comes along that is better and becomes widely adopted.
I'm sure there will be wrappers available to allow, your current favorite, the service/chkconfig commands to continue to do mostly sane things, but with this particular learning curve it is probably best not to fight it. Maybe looking forward, for a time there'll also be systemctl wrappers for older systems, to make managing them alongside more current ones less of a pain ;)
answered Oct 1 '15 at 10:29
DanSutDanSut
437312
There have been a number of varied boot and service control systems across Unix platforms over its tangled history.
The servicechkconfig based system you found simple and effective is generally referred to as SysVinit style and was a major step along the way to some sort of standardization. You will find this style of boot on RHEL/CentOS(EL) through the 6 release, Fedora through 14, and on Debian/Ubuntu based distributions up until 2015. It was not the only boot system around though, the (simpler) BSD style init system still has many fans.
SysVinit was not a perfect solution (what is?) and Systemd was devised to overcome many of the issues; this is the systemctl command based system you are now experiencing. Although it is not universally liked (people hate change, bloat, etc) there is no doubt that it is fast becoming the defacto standard across the majority of distributions.
Therefore, looking immediately forward the answer to your original question is simply:
The standard way to control services across most Linux distributions is now systemctl!
How long this will hold true is anyone's guess; probably just until something comes along that is better and becomes widely adopted.
I'm sure there will be wrappers available to allow, your current favorite, the service/chkconfig commands to continue to do mostly sane things, but with this particular learning curve it is probably best not to fight it. Maybe looking forward, for a time there'll also be systemctl wrappers for older systems, to make managing them alongside more current ones less of a pain ;)
answered Oct 1 '15 at 10:29
DanSutDanSut
437312
edited Oct 2 '15 at 2:13
answered Oct 1 '15 at 10:29
DanSutDanSut
437312
answered Oct 1 '15 at 10:29
DanSutDanSut
437312
answered Oct 1 '15 at 10:29
DanSutDanSut
437312
437312
And prior to this was xinetd, and prior to that was inetd
– jas-
Oct 1 '15 at 11:06
@jas- I think the inetd's are really services themselves, I believe they can exist within all boot systems. They are a special kind of service in that they provide an alternative for some other services to running as full services, by instead providing them on-demand. I understand where you are coming from in the context of this Q though, just another way of starting services.
– DanSut
Oct 1 '15 at 11:21
In all distributions; gentoo, centos, redhat, debian, ubuntu etc., xinetd and previously inetd consisted of small shell script to start, stop & reload configurations for various services, but yes you are correct they were indeed a service just like systemd is.
– jas-
Oct 3 '15 at 12:37
Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) upstart.ubuntu.com, and it's been possible to switch Debian away from sysvinit for quite a few years...
– James Tocknell
Oct 6 '15 at 0:19
add a comment |
And prior to this was xinetd, and prior to that was inetd
– jas-
Oct 1 '15 at 11:06
@jas- I think the inetd's are really services themselves, I believe they can exist within all boot systems. They are a special kind of service in that they provide an alternative for some other services to running as full services, by instead providing them on-demand. I understand where you are coming from in the context of this Q though, just another way of starting services.
– DanSut
Oct 1 '15 at 11:21
In all distributions; gentoo, centos, redhat, debian, ubuntu etc., xinetd and previously inetd consisted of small shell script to start, stop & reload configurations for various services, but yes you are correct they were indeed a service just like systemd is.
– jas-
Oct 3 '15 at 12:37
Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) upstart.ubuntu.com, and it's been possible to switch Debian away from sysvinit for quite a few years...
– James Tocknell
Oct 6 '15 at 0:19
And prior to this was xinetd, and prior to that was inetd
– jas-
Oct 1 '15 at 11:06
And prior to this was xinetd, and prior to that was inetd
– jas-
Oct 1 '15 at 11:06
@jas- I think the inetd's are really services themselves, I believe they can exist within all boot systems. They are a special kind of service in that they provide an alternative for some other services to running as full services, by instead providing them on-demand. I understand where you are coming from in the context of this Q though, just another way of starting services.
– DanSut
Oct 1 '15 at 11:21
@jas- I think the inetd's are really services themselves, I believe they can exist within all boot systems. They are a special kind of service in that they provide an alternative for some other services to running as full services, by instead providing them on-demand. I understand where you are coming from in the context of this Q though, just another way of starting services.
– DanSut
Oct 1 '15 at 11:21
In all distributions; gentoo, centos, redhat, debian, ubuntu etc., xinetd and previously inetd consisted of small shell script to start, stop & reload configurations for various services, but yes you are correct they were indeed a service just like systemd is.
– jas-
Oct 3 '15 at 12:37
In all distributions; gentoo, centos, redhat, debian, ubuntu etc., xinetd and previously inetd consisted of small shell script to start, stop & reload configurations for various services, but yes you are correct they were indeed a service just like systemd is.
– jas-
Oct 3 '15 at 12:37
Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) upstart.ubuntu.com, and it's been possible to switch Debian away from sysvinit for quite a few years...
– James Tocknell
Oct 6 '15 at 0:19
Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) upstart.ubuntu.com, and it's been possible to switch Debian away from sysvinit for quite a few years...
– James Tocknell
Oct 6 '15 at 0:19
add a comment |
Doesn't [it] make sense to replace the old
servicecommand with a wrapper that callsservicectl[sic] instead?Yes, but […] a wrapper could handle it, making the transition to systemd smoother for the users.
… which is, as others have said in comments, what has been done long since.
The /usr/sbin/service command on Debian 8 is part of the sysvinit-utils package. It has been there since 2009. It's a Debian-specific RedHat-originated addition to the original sysvinit source package, and as can be seen from reading the script it recognizes both systemd running and the presence of upstart jobs, farming out commands to systemctl and initctl (via its aliases) respectively. This it has done since 2013.
service name action is quite widely available even on non-Linux operating systems. It will even work on most of the BSDs, as they too have their own service commands. There is also a shim service command in the nosh package that translates to system-control action name. But …
- … get beyond this common subset, and there's far less compatibility all around.
- … OpenBSD has no
servicecommand. - … the BSD
servicecommands have well-known problems of long standing that system administrators have been telling war stories about for decades.
Enabling and disabling services is a similar situation. Although the SuSE chkconfig program (available packaged for Debian and Ubuntu) is very different to the the Fedora one (they being written in entirely different programming languages, even — one compiled, one interpreted), there is a common minimal chkconfig name action syntax, with action being on or off. But …
- … again, beyond this common subset there is less compatibility.
- … there's no
chkconfigon the BSDs, as the conventional tools for this are eithersysrcor the more recent OpenBSDrcctl enableandrcctl disable. There arechkconfigandrcctlshims in the nosh package that translate tosystem-control enable nameandsystem-control disable name. - … only the Fedora
chkconfigknows about systemd and acts as a shim forsystemctl enableandsystemctl disable. The SuSEchkconfighas no knowledge of systemd.
Further reading
"Download sysvinit-utils: List of files". sysvinit-utils package. Debian 8 packages.script/service. init-system-helpers. Debian source archive.- Jonathan de Boyne Pollard (2015).
telinit. nosh Guide. 1.20. JdeBP's Softwares. - Jonathan de Boyne Pollard (2015). No more problems with the
servicecommand. nosh pages. JdeBP's Softwares.
chkconfig package. Debian 8 packages.
"Does chkconfig command work with systemd?". systemd. Fedora project wiki.
"Does service command work with systemd?". systemd. Fedora project wiki.- Douglas Barton (2012-12-11).
service. §8. FreeBSD Manual Pages. - Antoine Jacoutot (2014-08-19). Introduce rcctl(8), a simple utility for maintaining rc.conf.local(8).. OpenBSD CVS.
- Jonathan de Boyne Pollard (2015). The nosh package. JdeBP's Softwares.
edited Jan 31 at 15:51
Stephen Kitt
173k24391467
answered Oct 4 '15 at 13:48
JdeBPJdeBP
35.2k470165
add a comment |
Doesn't [it] make sense to replace the old
servicecommand with a wrapper that callsservicectl[sic] instead?Yes, but […] a wrapper could handle it, making the transition to systemd smoother for the users.
… which is, as others have said in comments, what has been done long since.
The /usr/sbin/service command on Debian 8 is part of the sysvinit-utils package. It has been there since 2009. It's a Debian-specific RedHat-originated addition to the original sysvinit source package, and as can be seen from reading the script it recognizes both systemd running and the presence of upstart jobs, farming out commands to systemctl and initctl (via its aliases) respectively. This it has done since 2013.
service name action is quite widely available even on non-Linux operating systems. It will even work on most of the BSDs, as they too have their own service commands. There is also a shim service command in the nosh package that translates to system-control action name. But …
- … get beyond this common subset, and there's far less compatibility all around.
- … OpenBSD has no
servicecommand. - … the BSD
servicecommands have well-known problems of long standing that system administrators have been telling war stories about for decades.
Enabling and disabling services is a similar situation. Although the SuSE chkconfig program (available packaged for Debian and Ubuntu) is very different to the the Fedora one (they being written in entirely different programming languages, even — one compiled, one interpreted), there is a common minimal chkconfig name action syntax, with action being on or off. But …
- … again, beyond this common subset there is less compatibility.
- … there's no
chkconfigon the BSDs, as the conventional tools for this are eithersysrcor the more recent OpenBSDrcctl enableandrcctl disable. There arechkconfigandrcctlshims in the nosh package that translate tosystem-control enable nameandsystem-control disable name. - … only the Fedora
chkconfigknows about systemd and acts as a shim forsystemctl enableandsystemctl disable. The SuSEchkconfighas no knowledge of systemd.
Further reading
"Download sysvinit-utils: List of files". sysvinit-utils package. Debian 8 packages.script/service. init-system-helpers. Debian source archive.- Jonathan de Boyne Pollard (2015).
telinit. nosh Guide. 1.20. JdeBP's Softwares. - Jonathan de Boyne Pollard (2015). No more problems with the
servicecommand. nosh pages. JdeBP's Softwares.
chkconfig package. Debian 8 packages.
"Does chkconfig command work with systemd?". systemd. Fedora project wiki.
"Does service command work with systemd?". systemd. Fedora project wiki.- Douglas Barton (2012-12-11).
service. §8. FreeBSD Manual Pages. - Antoine Jacoutot (2014-08-19). Introduce rcctl(8), a simple utility for maintaining rc.conf.local(8).. OpenBSD CVS.
- Jonathan de Boyne Pollard (2015). The nosh package. JdeBP's Softwares.
edited Jan 31 at 15:51
Stephen Kitt
173k24391467
answered Oct 4 '15 at 13:48
JdeBPJdeBP
35.2k470165
add a comment |
Doesn't [it] make sense to replace the old
servicecommand with a wrapper that callsservicectl[sic] instead?Yes, but […] a wrapper could handle it, making the transition to systemd smoother for the users.
… which is, as others have said in comments, what has been done long since.
The /usr/sbin/service command on Debian 8 is part of the sysvinit-utils package. It has been there since 2009. It's a Debian-specific RedHat-originated addition to the original sysvinit source package, and as can be seen from reading the script it recognizes both systemd running and the presence of upstart jobs, farming out commands to systemctl and initctl (via its aliases) respectively. This it has done since 2013.
service name action is quite widely available even on non-Linux operating systems. It will even work on most of the BSDs, as they too have their own service commands. There is also a shim service command in the nosh package that translates to system-control action name. But …
- … get beyond this common subset, and there's far less compatibility all around.
- … OpenBSD has no
servicecommand. - … the BSD
servicecommands have well-known problems of long standing that system administrators have been telling war stories about for decades.
Enabling and disabling services is a similar situation. Although the SuSE chkconfig program (available packaged for Debian and Ubuntu) is very different to the the Fedora one (they being written in entirely different programming languages, even — one compiled, one interpreted), there is a common minimal chkconfig name action syntax, with action being on or off. But …
- … again, beyond this common subset there is less compatibility.
- … there's no
chkconfigon the BSDs, as the conventional tools for this are eithersysrcor the more recent OpenBSDrcctl enableandrcctl disable. There arechkconfigandrcctlshims in the nosh package that translate tosystem-control enable nameandsystem-control disable name. - … only the Fedora
chkconfigknows about systemd and acts as a shim forsystemctl enableandsystemctl disable. The SuSEchkconfighas no knowledge of systemd.
Further reading
"Download sysvinit-utils: List of files". sysvinit-utils package. Debian 8 packages.script/service. init-system-helpers. Debian source archive.- Jonathan de Boyne Pollard (2015).
telinit. nosh Guide. 1.20. JdeBP's Softwares. - Jonathan de Boyne Pollard (2015). No more problems with the
servicecommand. nosh pages. JdeBP's Softwares.
chkconfig package. Debian 8 packages.
"Does chkconfig command work with systemd?". systemd. Fedora project wiki.
"Does service command work with systemd?". systemd. Fedora project wiki.- Douglas Barton (2012-12-11).
service. §8. FreeBSD Manual Pages. - Antoine Jacoutot (2014-08-19). Introduce rcctl(8), a simple utility for maintaining rc.conf.local(8).. OpenBSD CVS.
- Jonathan de Boyne Pollard (2015). The nosh package. JdeBP's Softwares.
edited Jan 31 at 15:51
Stephen Kitt
173k24391467
answered Oct 4 '15 at 13:48
JdeBPJdeBP
35.2k470165
Doesn't [it] make sense to replace the old
servicecommand with a wrapper that callsservicectl[sic] instead?Yes, but […] a wrapper could handle it, making the transition to systemd smoother for the users.
… which is, as others have said in comments, what has been done long since.
The /usr/sbin/service command on Debian 8 is part of the sysvinit-utils package. It has been there since 2009. It's a Debian-specific RedHat-originated addition to the original sysvinit source package, and as can be seen from reading the script it recognizes both systemd running and the presence of upstart jobs, farming out commands to systemctl and initctl (via its aliases) respectively. This it has done since 2013.
service name action is quite widely available even on non-Linux operating systems. It will even work on most of the BSDs, as they too have their own service commands. There is also a shim service command in the nosh package that translates to system-control action name. But …
- … get beyond this common subset, and there's far less compatibility all around.
- … OpenBSD has no
servicecommand. - … the BSD
servicecommands have well-known problems of long standing that system administrators have been telling war stories about for decades.
Enabling and disabling services is a similar situation. Although the SuSE chkconfig program (available packaged for Debian and Ubuntu) is very different to the the Fedora one (they being written in entirely different programming languages, even — one compiled, one interpreted), there is a common minimal chkconfig name action syntax, with action being on or off. But …
- … again, beyond this common subset there is less compatibility.
- … there's no
chkconfigon the BSDs, as the conventional tools for this are eithersysrcor the more recent OpenBSDrcctl enableandrcctl disable. There arechkconfigandrcctlshims in the nosh package that translate tosystem-control enable nameandsystem-control disable name. - … only the Fedora
chkconfigknows about systemd and acts as a shim forsystemctl enableandsystemctl disable. The SuSEchkconfighas no knowledge of systemd.
Further reading
"Download sysvinit-utils: List of files". sysvinit-utils package. Debian 8 packages.script/service. init-system-helpers. Debian source archive.- Jonathan de Boyne Pollard (2015).
telinit. nosh Guide. 1.20. JdeBP's Softwares. - Jonathan de Boyne Pollard (2015). No more problems with the
servicecommand. nosh pages. JdeBP's Softwares.
chkconfig package. Debian 8 packages.
"Does chkconfig command work with systemd?". systemd. Fedora project wiki.
"Does service command work with systemd?". systemd. Fedora project wiki.- Douglas Barton (2012-12-11).
service. §8. FreeBSD Manual Pages. - Antoine Jacoutot (2014-08-19). Introduce rcctl(8), a simple utility for maintaining rc.conf.local(8).. OpenBSD CVS.
- Jonathan de Boyne Pollard (2015). The nosh package. JdeBP's Softwares.
edited Jan 31 at 15:51
Stephen Kitt
173k24391467
answered Oct 4 '15 at 13:48
JdeBPJdeBP
35.2k470165
edited Jan 31 at 15:51
Stephen Kitt
173k24391467
edited Jan 31 at 15:51
Stephen Kitt
173k24391467
edited Jan 31 at 15:51
Stephen Kitt
173k24391467
173k24391467
answered Oct 4 '15 at 13:48
JdeBPJdeBP
35.2k470165
answered Oct 4 '15 at 13:48
JdeBPJdeBP
35.2k470165
answered Oct 4 '15 at 13:48
JdeBPJdeBP
35.2k470165
35.2k470165
add a comment |
add a comment |
There is no standard way to start and stop services on Linux.
is there something that can save me from this doomed changes?
Try the configuration management/orchestration tool: Ansible, Chef, Saltstack, Puppet or whatever.
You can start and enable a service with Ansible:
ansible all -i inv -m service -a 'name=service-name state=started enabled=true'
Take a look at the LinuxService class in the Ansible's service module:
This is the Linux Service manipulation class - it is currently supporting
a mixture of binaries and init scripts for controlling services started at
boot, as well as for controlling the current state.
answered Oct 2 '15 at 2:26
Evgeny VereshchaginEvgeny Vereshchagin
3,31242236
Somehow it seems that Ubuntu guys were able to keep the service script working after switching to systemd. Looking inside it seems to be smart enough to use the right backend. Cannot say the same about Debian.
– sorin
Oct 2 '15 at 8:41
@sorin, well, service(8): use systemctl on machines that run systemd. But When running "service foo stop" and foo happens to be a service that has one or more .socket files, we also stop the .socket units. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 11:49
@sorin, also The reload action falls back to the sysv init script just in case the systemd service file does not (yet) support reload for a specific service.. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 12:10
add a comment |
There is no standard way to start and stop services on Linux.
is there something that can save me from this doomed changes?
Try the configuration management/orchestration tool: Ansible, Chef, Saltstack, Puppet or whatever.
You can start and enable a service with Ansible:
ansible all -i inv -m service -a 'name=service-name state=started enabled=true'
Take a look at the LinuxService class in the Ansible's service module:
This is the Linux Service manipulation class - it is currently supporting
a mixture of binaries and init scripts for controlling services started at
boot, as well as for controlling the current state.
answered Oct 2 '15 at 2:26
Evgeny VereshchaginEvgeny Vereshchagin
3,31242236
Somehow it seems that Ubuntu guys were able to keep the service script working after switching to systemd. Looking inside it seems to be smart enough to use the right backend. Cannot say the same about Debian.
– sorin
Oct 2 '15 at 8:41
@sorin, well, service(8): use systemctl on machines that run systemd. But When running "service foo stop" and foo happens to be a service that has one or more .socket files, we also stop the .socket units. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 11:49
@sorin, also The reload action falls back to the sysv init script just in case the systemd service file does not (yet) support reload for a specific service.. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 12:10
add a comment |
There is no standard way to start and stop services on Linux.
is there something that can save me from this doomed changes?
Try the configuration management/orchestration tool: Ansible, Chef, Saltstack, Puppet or whatever.
You can start and enable a service with Ansible:
ansible all -i inv -m service -a 'name=service-name state=started enabled=true'
Take a look at the LinuxService class in the Ansible's service module:
This is the Linux Service manipulation class - it is currently supporting
a mixture of binaries and init scripts for controlling services started at
boot, as well as for controlling the current state.
answered Oct 2 '15 at 2:26
Evgeny VereshchaginEvgeny Vereshchagin
3,31242236
There is no standard way to start and stop services on Linux.
is there something that can save me from this doomed changes?
Try the configuration management/orchestration tool: Ansible, Chef, Saltstack, Puppet or whatever.
You can start and enable a service with Ansible:
ansible all -i inv -m service -a 'name=service-name state=started enabled=true'
Take a look at the LinuxService class in the Ansible's service module:
This is the Linux Service manipulation class - it is currently supporting
a mixture of binaries and init scripts for controlling services started at
boot, as well as for controlling the current state.
answered Oct 2 '15 at 2:26
Evgeny VereshchaginEvgeny Vereshchagin
3,31242236
answered Oct 2 '15 at 2:26
Evgeny VereshchaginEvgeny Vereshchagin
3,31242236
answered Oct 2 '15 at 2:26
Evgeny VereshchaginEvgeny Vereshchagin
3,31242236
answered Oct 2 '15 at 2:26
Evgeny VereshchaginEvgeny Vereshchagin
3,31242236
3,31242236
Somehow it seems that Ubuntu guys were able to keep the service script working after switching to systemd. Looking inside it seems to be smart enough to use the right backend. Cannot say the same about Debian.
– sorin
Oct 2 '15 at 8:41
@sorin, well, service(8): use systemctl on machines that run systemd. But When running "service foo stop" and foo happens to be a service that has one or more .socket files, we also stop the .socket units. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 11:49
@sorin, also The reload action falls back to the sysv init script just in case the systemd service file does not (yet) support reload for a specific service.. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 12:10
add a comment |
Somehow it seems that Ubuntu guys were able to keep the service script working after switching to systemd. Looking inside it seems to be smart enough to use the right backend. Cannot say the same about Debian.
– sorin
Oct 2 '15 at 8:41
@sorin, well, service(8): use systemctl on machines that run systemd. But When running "service foo stop" and foo happens to be a service that has one or more .socket files, we also stop the .socket units. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 11:49
@sorin, also The reload action falls back to the sysv init script just in case the systemd service file does not (yet) support reload for a specific service.. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 12:10
Somehow it seems that Ubuntu guys were able to keep the service script working after switching to systemd. Looking inside it seems to be smart enough to use the right backend. Cannot say the same about Debian.
– sorin
Oct 2 '15 at 8:41
Somehow it seems that Ubuntu guys were able to keep the service script working after switching to systemd. Looking inside it seems to be smart enough to use the right backend. Cannot say the same about Debian.
– sorin
Oct 2 '15 at 8:41
@sorin, well, service(8): use systemctl on machines that run systemd. But When running "service foo stop" and foo happens to be a service that has one or more .socket files, we also stop the .socket units. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 11:49
@sorin, well, service(8): use systemctl on machines that run systemd. But When running "service foo stop" and foo happens to be a service that has one or more .socket files, we also stop the .socket units. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 11:49
@sorin, also The reload action falls back to the sysv init script just in case the systemd service file does not (yet) support reload for a specific service.. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 12:10
@sorin, also The reload action falls back to the sysv init script just in case the systemd service file does not (yet) support reload for a specific service.. Is it ok?
– Evgeny Vereshchagin
Oct 2 '15 at 12:10
add a comment |
Your problem is that Debian/Ubuntu have switched to the new systemd as a replacement of the old sysvinit. Ask which one is better and you will start a flame war, but you can allways switch back to the old sysvinit, check this if you want to go back.
answered Oct 1 '15 at 10:38
YoMismoYoMismo
3,0661925
add a comment |
Your problem is that Debian/Ubuntu have switched to the new systemd as a replacement of the old sysvinit. Ask which one is better and you will start a flame war, but you can allways switch back to the old sysvinit, check this if you want to go back.
answered Oct 1 '15 at 10:38
YoMismoYoMismo
3,0661925
add a comment |
Your problem is that Debian/Ubuntu have switched to the new systemd as a replacement of the old sysvinit. Ask which one is better and you will start a flame war, but you can allways switch back to the old sysvinit, check this if you want to go back.
answered Oct 1 '15 at 10:38
YoMismoYoMismo
3,0661925
Your problem is that Debian/Ubuntu have switched to the new systemd as a replacement of the old sysvinit. Ask which one is better and you will start a flame war, but you can allways switch back to the old sysvinit, check this if you want to go back.
answered Oct 1 '15 at 10:38
YoMismoYoMismo
3,0661925
answered Oct 1 '15 at 10:38
YoMismoYoMismo
3,0661925
answered Oct 1 '15 at 10:38
YoMismoYoMismo
3,0661925
answered Oct 1 '15 at 10:38
YoMismoYoMismo
3,0661925
3,0661925
add a comment |
add a comment |
protected by Anthon Apr 16 '16 at 4:39
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
5
Tab completion works for systemctl for me... And, like it or not, systemd is the de facto standard now: may as well get used to it.
– jasonwryan
Oct 1 '15 at 6:55
1
Extra: if service command become useless, can I remove it? What package provides it?
– sorin
Oct 1 '15 at 6:55
3
Doesn't make sense to replace the old
servicecommand with a wrapper that calls servicectl instead?– sorin
Oct 1 '15 at 6:59
4
@jasonwryan Yes, but you also can do just that, and a wrapper could handle it, making the transition to systemd smoother for the users.
– Dmitry Grigoryev
Oct 1 '15 at 7:29
2
Does
servicereally do nothing for you? It works as expected on my LMDE (which is basically Debian testing), I didn't think that was an LMDE-specific thing. It also works as expected in my Ubuntu VM.– terdon♦
Oct 1 '15 at 10:56