Difference between systemctl and service commands
systemd
gives us the systemctl
commands suite which is mostly used to enable services to start at boot time. We can also start, stop, reload, restart and check status of services with the help of systemctl
.
We can do, for example, sudo systemctl enable service_name
, and service_name
will automatically start at boot time. We can also disable services not to start at boot time.
Is the only difference between the service
and systemctl
commands that systemctl
can be used to enable the start of services at run time? Can we use systemctl
on any service? What other significant differences are there?
command-line services systemd
add a comment |
systemd
gives us the systemctl
commands suite which is mostly used to enable services to start at boot time. We can also start, stop, reload, restart and check status of services with the help of systemctl
.
We can do, for example, sudo systemctl enable service_name
, and service_name
will automatically start at boot time. We can also disable services not to start at boot time.
Is the only difference between the service
and systemctl
commands that systemctl
can be used to enable the start of services at run time? Can we use systemctl
on any service? What other significant differences are there?
command-line services systemd
I think you picked the wrong answer, myself.
– Evan Carroll
Dec 17 '17 at 4:58
add a comment |
systemd
gives us the systemctl
commands suite which is mostly used to enable services to start at boot time. We can also start, stop, reload, restart and check status of services with the help of systemctl
.
We can do, for example, sudo systemctl enable service_name
, and service_name
will automatically start at boot time. We can also disable services not to start at boot time.
Is the only difference between the service
and systemctl
commands that systemctl
can be used to enable the start of services at run time? Can we use systemctl
on any service? What other significant differences are there?
command-line services systemd
systemd
gives us the systemctl
commands suite which is mostly used to enable services to start at boot time. We can also start, stop, reload, restart and check status of services with the help of systemctl
.
We can do, for example, sudo systemctl enable service_name
, and service_name
will automatically start at boot time. We can also disable services not to start at boot time.
Is the only difference between the service
and systemctl
commands that systemctl
can be used to enable the start of services at run time? Can we use systemctl
on any service? What other significant differences are there?
command-line services systemd
command-line services systemd
edited Dec 24 at 22:57
Guy Avraham
1136
1136
asked Apr 10 '17 at 21:35
luv.preet
1,36721229
1,36721229
I think you picked the wrong answer, myself.
– Evan Carroll
Dec 17 '17 at 4:58
add a comment |
I think you picked the wrong answer, myself.
– Evan Carroll
Dec 17 '17 at 4:58
I think you picked the wrong answer, myself.
– Evan Carroll
Dec 17 '17 at 4:58
I think you picked the wrong answer, myself.
– Evan Carroll
Dec 17 '17 at 4:58
add a comment |
2 Answers
2
active
oldest
votes
The service
command is a wrapper script that allows system administrators to start, stop, and check the status of services without worrying too much about the actual init system being used. Prior to systemd's introduction, it was a wrapper for /etc/init.d
scripts and Upstart's initctl
command, and now it is a wrapper for these two and systemctl
as well.
Use the source, Luke!
It checks for Upstart:
# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null
&& initctl version 2>/dev/null | grep -q upstart
&& initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
# Upstart configuration exists for this job and we're running on upstart
If that doesn't work, it looks for systemd:
if [ -d /run/systemd/system ]; then
is_systemd=1
fi
...
# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then
And if that fails as well, it falls back to System V /etc/init.d
scripts:
run_via_sysvinit() {
# Otherwise, use the traditional sysvinit
if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
else
echo "${SERVICE}: unrecognized service" >&2
exit 1
fi
}
...
run_via_sysvinit
Since the service
command is a fairly simple wrapper, it only supports a limited subset of actions compared to what the actual init system might provide.
For portability over various versions of Ubuntu, users can reliably use the service
command to start, stop, restart or examine the status of a service. For more complex tasks, however, the actual command being used, be that initctl
or systemctl
or the /etc/init.d
script might have to be used directly.
Further, being a wrapper, the service
script in some cases also does more than the direct equivalent command might do. For example:
- It always executes
/etc/init.d
scripts in a clean environment. (Note the longenv
command invocation in therun_via_sysvinit
function above.) - It maps
restart
on Upstart systems to a combination ofstop
/start
, since a plaininitctl restart
will error out if the service isn't running already.
It stops sockets when stopping systemd services which have associated sockets:
case "${ACTION}" in
restart|status)
exec systemctl $sctl_args ${ACTION} ${UNIT}
;;
start|stop)
# Follow the principle of least surprise for SysV people:
# 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.
# Users who need more control will use systemctl directly.
Upstart services were enabled directly in the service configuration file (or disabled via overrides), and System V scripts were enabled or disabled with the update-rc.d
command (which managed symlinks in the /etc/rc*
directories), so the service
command was never involved in enabling or disabling services on boot.
1
superb explanation, thanks.
– Willa O Ng'wana
May 9 at 21:49
add a comment |
- systemd is backwards compatible with SysV.
- loads services parallel at startup
- it's provides on-demand activation of a service
- it's dependency based
- and a lot more I guess...
There are a lot more than what you mentioned that systemctl
is capable of.
systemd
works with units, there are different type of units: targets, services, sockets, etc. targets are same concept as runlevels, they are a bunch of units together.
You can use systemctl
to set or get the default system target.
systemctl get-default
You can go into other targets:
systemctl isolate multiuser.target
Other targets are: multiuser, graphical, recue, emergency, reboot, poweroff.
As you said, you can use systemctl
to manage services, some of the other commands related to service management which I'm aware of are:
# Restarts a service only if it is running.
systemctl try-restart name.service
# Reloads configuration if it's possible.
systemctl reload name.service
# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service
You can use it to find out about a service status:
systemctl status name.service
systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load
You can mask or unmask a service:
systemctl mask name.service
systemctl unmask name.service
Wen you mask a service it will be linked to /dev/null
, so manually or automatically other services can't active/enable it. (you should unmask it first).
Another usage of systemctl is to list units:
systemctl list-units
Which list all kind of units, loaded and active.
List service units:
systemctl list-units --type=service
Or to list all available units not just loaded and activated ones:
systemctl list-unit-files
You can create aliases or even control remote machines
systemctl --host ravexina@192.168.56.4 list-units
At the other hand service
does what it have to do, managing services and having nothing to do with other peoples business ;)
1
that was a perfect answer, Is there anything whichservice
can do but notsystemctl
?
– luv.preet
Apr 10 '17 at 23:10
Nothing that I'm aware of that, I think having a look at service man page would be helpful.
– Ravexina
Apr 10 '17 at 23:12
There's couple obvious differences. Syntax is one. Another is that systemv scripts never dealt with sockets, as far as i know. The fact that systemd is trying to deal with network type of stuff is another, and it's a frequent point of critique. Over all, systemd is trying to do more than just starting services
– Sergiy Kolodyazhnyy
Apr 11 '17 at 1:28
I would like to make a complaint here about systemd hiding log messages from failedservice start
attempts. Pre-systemd,service start
would let me see right away why my service wouldn't start. Post-systemd, I have to look at four or five different logs before I can find it. All that said, my comment is undoubtedly off topic and will probably be deleted.
– Ross Presser
Apr 11 '17 at 2:23
5
AFAICS This answer doesn't seem to tell anything about theservice
command, wasn't that part of the question?
– ilkkachu
Apr 11 '17 at 8:04
|
show 4 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f903354%2fdifference-between-systemctl-and-service-commands%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The service
command is a wrapper script that allows system administrators to start, stop, and check the status of services without worrying too much about the actual init system being used. Prior to systemd's introduction, it was a wrapper for /etc/init.d
scripts and Upstart's initctl
command, and now it is a wrapper for these two and systemctl
as well.
Use the source, Luke!
It checks for Upstart:
# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null
&& initctl version 2>/dev/null | grep -q upstart
&& initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
# Upstart configuration exists for this job and we're running on upstart
If that doesn't work, it looks for systemd:
if [ -d /run/systemd/system ]; then
is_systemd=1
fi
...
# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then
And if that fails as well, it falls back to System V /etc/init.d
scripts:
run_via_sysvinit() {
# Otherwise, use the traditional sysvinit
if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
else
echo "${SERVICE}: unrecognized service" >&2
exit 1
fi
}
...
run_via_sysvinit
Since the service
command is a fairly simple wrapper, it only supports a limited subset of actions compared to what the actual init system might provide.
For portability over various versions of Ubuntu, users can reliably use the service
command to start, stop, restart or examine the status of a service. For more complex tasks, however, the actual command being used, be that initctl
or systemctl
or the /etc/init.d
script might have to be used directly.
Further, being a wrapper, the service
script in some cases also does more than the direct equivalent command might do. For example:
- It always executes
/etc/init.d
scripts in a clean environment. (Note the longenv
command invocation in therun_via_sysvinit
function above.) - It maps
restart
on Upstart systems to a combination ofstop
/start
, since a plaininitctl restart
will error out if the service isn't running already.
It stops sockets when stopping systemd services which have associated sockets:
case "${ACTION}" in
restart|status)
exec systemctl $sctl_args ${ACTION} ${UNIT}
;;
start|stop)
# Follow the principle of least surprise for SysV people:
# 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.
# Users who need more control will use systemctl directly.
Upstart services were enabled directly in the service configuration file (or disabled via overrides), and System V scripts were enabled or disabled with the update-rc.d
command (which managed symlinks in the /etc/rc*
directories), so the service
command was never involved in enabling or disabling services on boot.
1
superb explanation, thanks.
– Willa O Ng'wana
May 9 at 21:49
add a comment |
The service
command is a wrapper script that allows system administrators to start, stop, and check the status of services without worrying too much about the actual init system being used. Prior to systemd's introduction, it was a wrapper for /etc/init.d
scripts and Upstart's initctl
command, and now it is a wrapper for these two and systemctl
as well.
Use the source, Luke!
It checks for Upstart:
# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null
&& initctl version 2>/dev/null | grep -q upstart
&& initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
# Upstart configuration exists for this job and we're running on upstart
If that doesn't work, it looks for systemd:
if [ -d /run/systemd/system ]; then
is_systemd=1
fi
...
# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then
And if that fails as well, it falls back to System V /etc/init.d
scripts:
run_via_sysvinit() {
# Otherwise, use the traditional sysvinit
if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
else
echo "${SERVICE}: unrecognized service" >&2
exit 1
fi
}
...
run_via_sysvinit
Since the service
command is a fairly simple wrapper, it only supports a limited subset of actions compared to what the actual init system might provide.
For portability over various versions of Ubuntu, users can reliably use the service
command to start, stop, restart or examine the status of a service. For more complex tasks, however, the actual command being used, be that initctl
or systemctl
or the /etc/init.d
script might have to be used directly.
Further, being a wrapper, the service
script in some cases also does more than the direct equivalent command might do. For example:
- It always executes
/etc/init.d
scripts in a clean environment. (Note the longenv
command invocation in therun_via_sysvinit
function above.) - It maps
restart
on Upstart systems to a combination ofstop
/start
, since a plaininitctl restart
will error out if the service isn't running already.
It stops sockets when stopping systemd services which have associated sockets:
case "${ACTION}" in
restart|status)
exec systemctl $sctl_args ${ACTION} ${UNIT}
;;
start|stop)
# Follow the principle of least surprise for SysV people:
# 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.
# Users who need more control will use systemctl directly.
Upstart services were enabled directly in the service configuration file (or disabled via overrides), and System V scripts were enabled or disabled with the update-rc.d
command (which managed symlinks in the /etc/rc*
directories), so the service
command was never involved in enabling or disabling services on boot.
1
superb explanation, thanks.
– Willa O Ng'wana
May 9 at 21:49
add a comment |
The service
command is a wrapper script that allows system administrators to start, stop, and check the status of services without worrying too much about the actual init system being used. Prior to systemd's introduction, it was a wrapper for /etc/init.d
scripts and Upstart's initctl
command, and now it is a wrapper for these two and systemctl
as well.
Use the source, Luke!
It checks for Upstart:
# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null
&& initctl version 2>/dev/null | grep -q upstart
&& initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
# Upstart configuration exists for this job and we're running on upstart
If that doesn't work, it looks for systemd:
if [ -d /run/systemd/system ]; then
is_systemd=1
fi
...
# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then
And if that fails as well, it falls back to System V /etc/init.d
scripts:
run_via_sysvinit() {
# Otherwise, use the traditional sysvinit
if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
else
echo "${SERVICE}: unrecognized service" >&2
exit 1
fi
}
...
run_via_sysvinit
Since the service
command is a fairly simple wrapper, it only supports a limited subset of actions compared to what the actual init system might provide.
For portability over various versions of Ubuntu, users can reliably use the service
command to start, stop, restart or examine the status of a service. For more complex tasks, however, the actual command being used, be that initctl
or systemctl
or the /etc/init.d
script might have to be used directly.
Further, being a wrapper, the service
script in some cases also does more than the direct equivalent command might do. For example:
- It always executes
/etc/init.d
scripts in a clean environment. (Note the longenv
command invocation in therun_via_sysvinit
function above.) - It maps
restart
on Upstart systems to a combination ofstop
/start
, since a plaininitctl restart
will error out if the service isn't running already.
It stops sockets when stopping systemd services which have associated sockets:
case "${ACTION}" in
restart|status)
exec systemctl $sctl_args ${ACTION} ${UNIT}
;;
start|stop)
# Follow the principle of least surprise for SysV people:
# 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.
# Users who need more control will use systemctl directly.
Upstart services were enabled directly in the service configuration file (or disabled via overrides), and System V scripts were enabled or disabled with the update-rc.d
command (which managed symlinks in the /etc/rc*
directories), so the service
command was never involved in enabling or disabling services on boot.
The service
command is a wrapper script that allows system administrators to start, stop, and check the status of services without worrying too much about the actual init system being used. Prior to systemd's introduction, it was a wrapper for /etc/init.d
scripts and Upstart's initctl
command, and now it is a wrapper for these two and systemctl
as well.
Use the source, Luke!
It checks for Upstart:
# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null
&& initctl version 2>/dev/null | grep -q upstart
&& initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
# Upstart configuration exists for this job and we're running on upstart
If that doesn't work, it looks for systemd:
if [ -d /run/systemd/system ]; then
is_systemd=1
fi
...
# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then
And if that fails as well, it falls back to System V /etc/init.d
scripts:
run_via_sysvinit() {
# Otherwise, use the traditional sysvinit
if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
else
echo "${SERVICE}: unrecognized service" >&2
exit 1
fi
}
...
run_via_sysvinit
Since the service
command is a fairly simple wrapper, it only supports a limited subset of actions compared to what the actual init system might provide.
For portability over various versions of Ubuntu, users can reliably use the service
command to start, stop, restart or examine the status of a service. For more complex tasks, however, the actual command being used, be that initctl
or systemctl
or the /etc/init.d
script might have to be used directly.
Further, being a wrapper, the service
script in some cases also does more than the direct equivalent command might do. For example:
- It always executes
/etc/init.d
scripts in a clean environment. (Note the longenv
command invocation in therun_via_sysvinit
function above.) - It maps
restart
on Upstart systems to a combination ofstop
/start
, since a plaininitctl restart
will error out if the service isn't running already.
It stops sockets when stopping systemd services which have associated sockets:
case "${ACTION}" in
restart|status)
exec systemctl $sctl_args ${ACTION} ${UNIT}
;;
start|stop)
# Follow the principle of least surprise for SysV people:
# 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.
# Users who need more control will use systemctl directly.
Upstart services were enabled directly in the service configuration file (or disabled via overrides), and System V scripts were enabled or disabled with the update-rc.d
command (which managed symlinks in the /etc/rc*
directories), so the service
command was never involved in enabling or disabling services on boot.
answered Apr 11 '17 at 3:03
muru
1
1
1
superb explanation, thanks.
– Willa O Ng'wana
May 9 at 21:49
add a comment |
1
superb explanation, thanks.
– Willa O Ng'wana
May 9 at 21:49
1
1
superb explanation, thanks.
– Willa O Ng'wana
May 9 at 21:49
superb explanation, thanks.
– Willa O Ng'wana
May 9 at 21:49
add a comment |
- systemd is backwards compatible with SysV.
- loads services parallel at startup
- it's provides on-demand activation of a service
- it's dependency based
- and a lot more I guess...
There are a lot more than what you mentioned that systemctl
is capable of.
systemd
works with units, there are different type of units: targets, services, sockets, etc. targets are same concept as runlevels, they are a bunch of units together.
You can use systemctl
to set or get the default system target.
systemctl get-default
You can go into other targets:
systemctl isolate multiuser.target
Other targets are: multiuser, graphical, recue, emergency, reboot, poweroff.
As you said, you can use systemctl
to manage services, some of the other commands related to service management which I'm aware of are:
# Restarts a service only if it is running.
systemctl try-restart name.service
# Reloads configuration if it's possible.
systemctl reload name.service
# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service
You can use it to find out about a service status:
systemctl status name.service
systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load
You can mask or unmask a service:
systemctl mask name.service
systemctl unmask name.service
Wen you mask a service it will be linked to /dev/null
, so manually or automatically other services can't active/enable it. (you should unmask it first).
Another usage of systemctl is to list units:
systemctl list-units
Which list all kind of units, loaded and active.
List service units:
systemctl list-units --type=service
Or to list all available units not just loaded and activated ones:
systemctl list-unit-files
You can create aliases or even control remote machines
systemctl --host ravexina@192.168.56.4 list-units
At the other hand service
does what it have to do, managing services and having nothing to do with other peoples business ;)
1
that was a perfect answer, Is there anything whichservice
can do but notsystemctl
?
– luv.preet
Apr 10 '17 at 23:10
Nothing that I'm aware of that, I think having a look at service man page would be helpful.
– Ravexina
Apr 10 '17 at 23:12
There's couple obvious differences. Syntax is one. Another is that systemv scripts never dealt with sockets, as far as i know. The fact that systemd is trying to deal with network type of stuff is another, and it's a frequent point of critique. Over all, systemd is trying to do more than just starting services
– Sergiy Kolodyazhnyy
Apr 11 '17 at 1:28
I would like to make a complaint here about systemd hiding log messages from failedservice start
attempts. Pre-systemd,service start
would let me see right away why my service wouldn't start. Post-systemd, I have to look at four or five different logs before I can find it. All that said, my comment is undoubtedly off topic and will probably be deleted.
– Ross Presser
Apr 11 '17 at 2:23
5
AFAICS This answer doesn't seem to tell anything about theservice
command, wasn't that part of the question?
– ilkkachu
Apr 11 '17 at 8:04
|
show 4 more comments
- systemd is backwards compatible with SysV.
- loads services parallel at startup
- it's provides on-demand activation of a service
- it's dependency based
- and a lot more I guess...
There are a lot more than what you mentioned that systemctl
is capable of.
systemd
works with units, there are different type of units: targets, services, sockets, etc. targets are same concept as runlevels, they are a bunch of units together.
You can use systemctl
to set or get the default system target.
systemctl get-default
You can go into other targets:
systemctl isolate multiuser.target
Other targets are: multiuser, graphical, recue, emergency, reboot, poweroff.
As you said, you can use systemctl
to manage services, some of the other commands related to service management which I'm aware of are:
# Restarts a service only if it is running.
systemctl try-restart name.service
# Reloads configuration if it's possible.
systemctl reload name.service
# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service
You can use it to find out about a service status:
systemctl status name.service
systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load
You can mask or unmask a service:
systemctl mask name.service
systemctl unmask name.service
Wen you mask a service it will be linked to /dev/null
, so manually or automatically other services can't active/enable it. (you should unmask it first).
Another usage of systemctl is to list units:
systemctl list-units
Which list all kind of units, loaded and active.
List service units:
systemctl list-units --type=service
Or to list all available units not just loaded and activated ones:
systemctl list-unit-files
You can create aliases or even control remote machines
systemctl --host ravexina@192.168.56.4 list-units
At the other hand service
does what it have to do, managing services and having nothing to do with other peoples business ;)
1
that was a perfect answer, Is there anything whichservice
can do but notsystemctl
?
– luv.preet
Apr 10 '17 at 23:10
Nothing that I'm aware of that, I think having a look at service man page would be helpful.
– Ravexina
Apr 10 '17 at 23:12
There's couple obvious differences. Syntax is one. Another is that systemv scripts never dealt with sockets, as far as i know. The fact that systemd is trying to deal with network type of stuff is another, and it's a frequent point of critique. Over all, systemd is trying to do more than just starting services
– Sergiy Kolodyazhnyy
Apr 11 '17 at 1:28
I would like to make a complaint here about systemd hiding log messages from failedservice start
attempts. Pre-systemd,service start
would let me see right away why my service wouldn't start. Post-systemd, I have to look at four or five different logs before I can find it. All that said, my comment is undoubtedly off topic and will probably be deleted.
– Ross Presser
Apr 11 '17 at 2:23
5
AFAICS This answer doesn't seem to tell anything about theservice
command, wasn't that part of the question?
– ilkkachu
Apr 11 '17 at 8:04
|
show 4 more comments
- systemd is backwards compatible with SysV.
- loads services parallel at startup
- it's provides on-demand activation of a service
- it's dependency based
- and a lot more I guess...
There are a lot more than what you mentioned that systemctl
is capable of.
systemd
works with units, there are different type of units: targets, services, sockets, etc. targets are same concept as runlevels, they are a bunch of units together.
You can use systemctl
to set or get the default system target.
systemctl get-default
You can go into other targets:
systemctl isolate multiuser.target
Other targets are: multiuser, graphical, recue, emergency, reboot, poweroff.
As you said, you can use systemctl
to manage services, some of the other commands related to service management which I'm aware of are:
# Restarts a service only if it is running.
systemctl try-restart name.service
# Reloads configuration if it's possible.
systemctl reload name.service
# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service
You can use it to find out about a service status:
systemctl status name.service
systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load
You can mask or unmask a service:
systemctl mask name.service
systemctl unmask name.service
Wen you mask a service it will be linked to /dev/null
, so manually or automatically other services can't active/enable it. (you should unmask it first).
Another usage of systemctl is to list units:
systemctl list-units
Which list all kind of units, loaded and active.
List service units:
systemctl list-units --type=service
Or to list all available units not just loaded and activated ones:
systemctl list-unit-files
You can create aliases or even control remote machines
systemctl --host ravexina@192.168.56.4 list-units
At the other hand service
does what it have to do, managing services and having nothing to do with other peoples business ;)
- systemd is backwards compatible with SysV.
- loads services parallel at startup
- it's provides on-demand activation of a service
- it's dependency based
- and a lot more I guess...
There are a lot more than what you mentioned that systemctl
is capable of.
systemd
works with units, there are different type of units: targets, services, sockets, etc. targets are same concept as runlevels, they are a bunch of units together.
You can use systemctl
to set or get the default system target.
systemctl get-default
You can go into other targets:
systemctl isolate multiuser.target
Other targets are: multiuser, graphical, recue, emergency, reboot, poweroff.
As you said, you can use systemctl
to manage services, some of the other commands related to service management which I'm aware of are:
# Restarts a service only if it is running.
systemctl try-restart name.service
# Reloads configuration if it's possible.
systemctl reload name.service
# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service
You can use it to find out about a service status:
systemctl status name.service
systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load
You can mask or unmask a service:
systemctl mask name.service
systemctl unmask name.service
Wen you mask a service it will be linked to /dev/null
, so manually or automatically other services can't active/enable it. (you should unmask it first).
Another usage of systemctl is to list units:
systemctl list-units
Which list all kind of units, loaded and active.
List service units:
systemctl list-units --type=service
Or to list all available units not just loaded and activated ones:
systemctl list-unit-files
You can create aliases or even control remote machines
systemctl --host ravexina@192.168.56.4 list-units
At the other hand service
does what it have to do, managing services and having nothing to do with other peoples business ;)
edited Apr 10 '17 at 22:04
answered Apr 10 '17 at 21:53
Ravexina
31.1k1481109
31.1k1481109
1
that was a perfect answer, Is there anything whichservice
can do but notsystemctl
?
– luv.preet
Apr 10 '17 at 23:10
Nothing that I'm aware of that, I think having a look at service man page would be helpful.
– Ravexina
Apr 10 '17 at 23:12
There's couple obvious differences. Syntax is one. Another is that systemv scripts never dealt with sockets, as far as i know. The fact that systemd is trying to deal with network type of stuff is another, and it's a frequent point of critique. Over all, systemd is trying to do more than just starting services
– Sergiy Kolodyazhnyy
Apr 11 '17 at 1:28
I would like to make a complaint here about systemd hiding log messages from failedservice start
attempts. Pre-systemd,service start
would let me see right away why my service wouldn't start. Post-systemd, I have to look at four or five different logs before I can find it. All that said, my comment is undoubtedly off topic and will probably be deleted.
– Ross Presser
Apr 11 '17 at 2:23
5
AFAICS This answer doesn't seem to tell anything about theservice
command, wasn't that part of the question?
– ilkkachu
Apr 11 '17 at 8:04
|
show 4 more comments
1
that was a perfect answer, Is there anything whichservice
can do but notsystemctl
?
– luv.preet
Apr 10 '17 at 23:10
Nothing that I'm aware of that, I think having a look at service man page would be helpful.
– Ravexina
Apr 10 '17 at 23:12
There's couple obvious differences. Syntax is one. Another is that systemv scripts never dealt with sockets, as far as i know. The fact that systemd is trying to deal with network type of stuff is another, and it's a frequent point of critique. Over all, systemd is trying to do more than just starting services
– Sergiy Kolodyazhnyy
Apr 11 '17 at 1:28
I would like to make a complaint here about systemd hiding log messages from failedservice start
attempts. Pre-systemd,service start
would let me see right away why my service wouldn't start. Post-systemd, I have to look at four or five different logs before I can find it. All that said, my comment is undoubtedly off topic and will probably be deleted.
– Ross Presser
Apr 11 '17 at 2:23
5
AFAICS This answer doesn't seem to tell anything about theservice
command, wasn't that part of the question?
– ilkkachu
Apr 11 '17 at 8:04
1
1
that was a perfect answer, Is there anything which
service
can do but not systemctl
?– luv.preet
Apr 10 '17 at 23:10
that was a perfect answer, Is there anything which
service
can do but not systemctl
?– luv.preet
Apr 10 '17 at 23:10
Nothing that I'm aware of that, I think having a look at service man page would be helpful.
– Ravexina
Apr 10 '17 at 23:12
Nothing that I'm aware of that, I think having a look at service man page would be helpful.
– Ravexina
Apr 10 '17 at 23:12
There's couple obvious differences. Syntax is one. Another is that systemv scripts never dealt with sockets, as far as i know. The fact that systemd is trying to deal with network type of stuff is another, and it's a frequent point of critique. Over all, systemd is trying to do more than just starting services
– Sergiy Kolodyazhnyy
Apr 11 '17 at 1:28
There's couple obvious differences. Syntax is one. Another is that systemv scripts never dealt with sockets, as far as i know. The fact that systemd is trying to deal with network type of stuff is another, and it's a frequent point of critique. Over all, systemd is trying to do more than just starting services
– Sergiy Kolodyazhnyy
Apr 11 '17 at 1:28
I would like to make a complaint here about systemd hiding log messages from failed
service start
attempts. Pre-systemd, service start
would let me see right away why my service wouldn't start. Post-systemd, I have to look at four or five different logs before I can find it. All that said, my comment is undoubtedly off topic and will probably be deleted.– Ross Presser
Apr 11 '17 at 2:23
I would like to make a complaint here about systemd hiding log messages from failed
service start
attempts. Pre-systemd, service start
would let me see right away why my service wouldn't start. Post-systemd, I have to look at four or five different logs before I can find it. All that said, my comment is undoubtedly off topic and will probably be deleted.– Ross Presser
Apr 11 '17 at 2:23
5
5
AFAICS This answer doesn't seem to tell anything about the
service
command, wasn't that part of the question?– ilkkachu
Apr 11 '17 at 8:04
AFAICS This answer doesn't seem to tell anything about the
service
command, wasn't that part of the question?– ilkkachu
Apr 11 '17 at 8:04
|
show 4 more comments
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f903354%2fdifference-between-systemctl-and-service-commands%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I think you picked the wrong answer, myself.
– Evan Carroll
Dec 17 '17 at 4:58