Why in some linux distribution systemd services are enabled by default and in others it is not? [closed]
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I have noticed that after a package installation via apt-get in Debian the service in systemd is enabled by default. However, in other distributions, such as Arch Linux, the service in that package is disabled by default.
My questions are:
- On what does this behavior depend? Is it some setting in the package manager or the package itself decides whether it is enabled or not?
I mean on Debian it looks like systemctl enable docker.service
was executed after installation. And on Arch-linux the docker.service
is disabled.
- How can I change it?
linux debian arch-linux systemd
closed as primarily opinion-based by Ipor Sircer, muru, schily, msp9011, G-Man Aug 13 at 21:45
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
2
down vote
favorite
I have noticed that after a package installation via apt-get in Debian the service in systemd is enabled by default. However, in other distributions, such as Arch Linux, the service in that package is disabled by default.
My questions are:
- On what does this behavior depend? Is it some setting in the package manager or the package itself decides whether it is enabled or not?
I mean on Debian it looks like systemctl enable docker.service
was executed after installation. And on Arch-linux the docker.service
is disabled.
- How can I change it?
linux debian arch-linux systemd
closed as primarily opinion-based by Ipor Sircer, muru, schily, msp9011, G-Man Aug 13 at 21:45
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
There is not much option about avoiding systemd using Linux except if using Slackware or other small distros like AntiX
â Rui F Ribeiro
Aug 13 at 12:37
1
without-systemd.org/wiki/index.php/â¦
â arochester
Aug 13 at 12:46
@RuiFRibeiro My question is not about systemd itself, but about services thar systemd manages.
â RndGuyFromInternet
Aug 13 at 12:47
Arch assumes you know what you are doing; Debian is agnostic on that front.
â jasonwryan
Aug 13 at 17:44
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I have noticed that after a package installation via apt-get in Debian the service in systemd is enabled by default. However, in other distributions, such as Arch Linux, the service in that package is disabled by default.
My questions are:
- On what does this behavior depend? Is it some setting in the package manager or the package itself decides whether it is enabled or not?
I mean on Debian it looks like systemctl enable docker.service
was executed after installation. And on Arch-linux the docker.service
is disabled.
- How can I change it?
linux debian arch-linux systemd
I have noticed that after a package installation via apt-get in Debian the service in systemd is enabled by default. However, in other distributions, such as Arch Linux, the service in that package is disabled by default.
My questions are:
- On what does this behavior depend? Is it some setting in the package manager or the package itself decides whether it is enabled or not?
I mean on Debian it looks like systemctl enable docker.service
was executed after installation. And on Arch-linux the docker.service
is disabled.
- How can I change it?
linux debian arch-linux systemd
linux debian arch-linux systemd
edited Aug 13 at 14:42
GAD3R
22.8k154895
22.8k154895
asked Aug 13 at 10:57
RndGuyFromInternet
163
163
closed as primarily opinion-based by Ipor Sircer, muru, schily, msp9011, G-Man Aug 13 at 21:45
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by Ipor Sircer, muru, schily, msp9011, G-Man Aug 13 at 21:45
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
There is not much option about avoiding systemd using Linux except if using Slackware or other small distros like AntiX
â Rui F Ribeiro
Aug 13 at 12:37
1
without-systemd.org/wiki/index.php/â¦
â arochester
Aug 13 at 12:46
@RuiFRibeiro My question is not about systemd itself, but about services thar systemd manages.
â RndGuyFromInternet
Aug 13 at 12:47
Arch assumes you know what you are doing; Debian is agnostic on that front.
â jasonwryan
Aug 13 at 17:44
add a comment |Â
There is not much option about avoiding systemd using Linux except if using Slackware or other small distros like AntiX
â Rui F Ribeiro
Aug 13 at 12:37
1
without-systemd.org/wiki/index.php/â¦
â arochester
Aug 13 at 12:46
@RuiFRibeiro My question is not about systemd itself, but about services thar systemd manages.
â RndGuyFromInternet
Aug 13 at 12:47
Arch assumes you know what you are doing; Debian is agnostic on that front.
â jasonwryan
Aug 13 at 17:44
There is not much option about avoiding systemd using Linux except if using Slackware or other small distros like AntiX
â Rui F Ribeiro
Aug 13 at 12:37
There is not much option about avoiding systemd using Linux except if using Slackware or other small distros like AntiX
â Rui F Ribeiro
Aug 13 at 12:37
1
1
without-systemd.org/wiki/index.php/â¦
â arochester
Aug 13 at 12:46
without-systemd.org/wiki/index.php/â¦
â arochester
Aug 13 at 12:46
@RuiFRibeiro My question is not about systemd itself, but about services thar systemd manages.
â RndGuyFromInternet
Aug 13 at 12:47
@RuiFRibeiro My question is not about systemd itself, but about services thar systemd manages.
â RndGuyFromInternet
Aug 13 at 12:47
Arch assumes you know what you are doing; Debian is agnostic on that front.
â jasonwryan
Aug 13 at 17:44
Arch assumes you know what you are doing; Debian is agnostic on that front.
â jasonwryan
Aug 13 at 17:44
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
6
down vote
accepted
As the systemd preset blurb states, this is a policy choice made by distributors:
On Fedora all services stay off by default, so that installing a package will not cause a service to be enabled (with some exceptions). On Debian all services are immediately enabled by default, so that installing a package will cause its service(s) to be enabled right-away.
In theory, systemd distributions use the preset system for deciding whether a service should be enabled after package installation, running systemctl preset
rather than systemctl enable
in package post-install maintenance scripts; and applying your local overrides to the distribution policy is as simple as creating your own higher priority presets in /etc/systemd/system-preset/
. (The Arch doco is rather misleading, here. The usual case is to create an individual local preset file that addresses specific services.)
In practice, some systemd distributions do not use the preset system for this, and applying your local overrides to systemd is a matter of employing the distributions' own mechanisms, if they even actually have such.
Further reading
- Raphaël Hertzog (2014-12-08). deb-systemd-helper does not respect systemd Preset files. Debian Bug #772555.
- "Enable installed units by default". systemd. Arch wiki.
add a comment |Â
up vote
3
down vote
1) On what does this behavior depend? Is it some setting in package manager or the package itself decides whether it is enabled or not?
Each distribution may use different package managers like apt in Debian or pacman in Arch Linux. This requires software developers and/or package maintainers to prepare a package in various (often incoherent) ways. Such differences may be related to the settings in the package, but sometimes the package may be prepared without assumption that systemd will be used on the target system.
2) How can I change it?
Find out how the specific package for your distribution is prepared and maintaned, and who is responsible for it. If it's open source, there's a chance that you will be able to modify behaviour by yourself in the installation sources. You may also contact someone from the software developers/maintainers community to suggest changes.
for Debian, relevant link: Debian Policy 9.3.3.1. Managing the links "The default behaviour is to enable autostarting your package's daemon." Since it's the policy manual, it describes choices made. (might not be up to date with systemd)
â A.B
Aug 13 at 13:04
@A.B Thanks for answer. That's exactly what I was looking for.
â RndGuyFromInternet
Aug 13 at 13:14
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
As the systemd preset blurb states, this is a policy choice made by distributors:
On Fedora all services stay off by default, so that installing a package will not cause a service to be enabled (with some exceptions). On Debian all services are immediately enabled by default, so that installing a package will cause its service(s) to be enabled right-away.
In theory, systemd distributions use the preset system for deciding whether a service should be enabled after package installation, running systemctl preset
rather than systemctl enable
in package post-install maintenance scripts; and applying your local overrides to the distribution policy is as simple as creating your own higher priority presets in /etc/systemd/system-preset/
. (The Arch doco is rather misleading, here. The usual case is to create an individual local preset file that addresses specific services.)
In practice, some systemd distributions do not use the preset system for this, and applying your local overrides to systemd is a matter of employing the distributions' own mechanisms, if they even actually have such.
Further reading
- Raphaël Hertzog (2014-12-08). deb-systemd-helper does not respect systemd Preset files. Debian Bug #772555.
- "Enable installed units by default". systemd. Arch wiki.
add a comment |Â
up vote
6
down vote
accepted
As the systemd preset blurb states, this is a policy choice made by distributors:
On Fedora all services stay off by default, so that installing a package will not cause a service to be enabled (with some exceptions). On Debian all services are immediately enabled by default, so that installing a package will cause its service(s) to be enabled right-away.
In theory, systemd distributions use the preset system for deciding whether a service should be enabled after package installation, running systemctl preset
rather than systemctl enable
in package post-install maintenance scripts; and applying your local overrides to the distribution policy is as simple as creating your own higher priority presets in /etc/systemd/system-preset/
. (The Arch doco is rather misleading, here. The usual case is to create an individual local preset file that addresses specific services.)
In practice, some systemd distributions do not use the preset system for this, and applying your local overrides to systemd is a matter of employing the distributions' own mechanisms, if they even actually have such.
Further reading
- Raphaël Hertzog (2014-12-08). deb-systemd-helper does not respect systemd Preset files. Debian Bug #772555.
- "Enable installed units by default". systemd. Arch wiki.
add a comment |Â
up vote
6
down vote
accepted
up vote
6
down vote
accepted
As the systemd preset blurb states, this is a policy choice made by distributors:
On Fedora all services stay off by default, so that installing a package will not cause a service to be enabled (with some exceptions). On Debian all services are immediately enabled by default, so that installing a package will cause its service(s) to be enabled right-away.
In theory, systemd distributions use the preset system for deciding whether a service should be enabled after package installation, running systemctl preset
rather than systemctl enable
in package post-install maintenance scripts; and applying your local overrides to the distribution policy is as simple as creating your own higher priority presets in /etc/systemd/system-preset/
. (The Arch doco is rather misleading, here. The usual case is to create an individual local preset file that addresses specific services.)
In practice, some systemd distributions do not use the preset system for this, and applying your local overrides to systemd is a matter of employing the distributions' own mechanisms, if they even actually have such.
Further reading
- Raphaël Hertzog (2014-12-08). deb-systemd-helper does not respect systemd Preset files. Debian Bug #772555.
- "Enable installed units by default". systemd. Arch wiki.
As the systemd preset blurb states, this is a policy choice made by distributors:
On Fedora all services stay off by default, so that installing a package will not cause a service to be enabled (with some exceptions). On Debian all services are immediately enabled by default, so that installing a package will cause its service(s) to be enabled right-away.
In theory, systemd distributions use the preset system for deciding whether a service should be enabled after package installation, running systemctl preset
rather than systemctl enable
in package post-install maintenance scripts; and applying your local overrides to the distribution policy is as simple as creating your own higher priority presets in /etc/systemd/system-preset/
. (The Arch doco is rather misleading, here. The usual case is to create an individual local preset file that addresses specific services.)
In practice, some systemd distributions do not use the preset system for this, and applying your local overrides to systemd is a matter of employing the distributions' own mechanisms, if they even actually have such.
Further reading
- Raphaël Hertzog (2014-12-08). deb-systemd-helper does not respect systemd Preset files. Debian Bug #772555.
- "Enable installed units by default". systemd. Arch wiki.
answered Aug 13 at 15:02
JdeBP
29.3k460136
29.3k460136
add a comment |Â
add a comment |Â
up vote
3
down vote
1) On what does this behavior depend? Is it some setting in package manager or the package itself decides whether it is enabled or not?
Each distribution may use different package managers like apt in Debian or pacman in Arch Linux. This requires software developers and/or package maintainers to prepare a package in various (often incoherent) ways. Such differences may be related to the settings in the package, but sometimes the package may be prepared without assumption that systemd will be used on the target system.
2) How can I change it?
Find out how the specific package for your distribution is prepared and maintaned, and who is responsible for it. If it's open source, there's a chance that you will be able to modify behaviour by yourself in the installation sources. You may also contact someone from the software developers/maintainers community to suggest changes.
for Debian, relevant link: Debian Policy 9.3.3.1. Managing the links "The default behaviour is to enable autostarting your package's daemon." Since it's the policy manual, it describes choices made. (might not be up to date with systemd)
â A.B
Aug 13 at 13:04
@A.B Thanks for answer. That's exactly what I was looking for.
â RndGuyFromInternet
Aug 13 at 13:14
add a comment |Â
up vote
3
down vote
1) On what does this behavior depend? Is it some setting in package manager or the package itself decides whether it is enabled or not?
Each distribution may use different package managers like apt in Debian or pacman in Arch Linux. This requires software developers and/or package maintainers to prepare a package in various (often incoherent) ways. Such differences may be related to the settings in the package, but sometimes the package may be prepared without assumption that systemd will be used on the target system.
2) How can I change it?
Find out how the specific package for your distribution is prepared and maintaned, and who is responsible for it. If it's open source, there's a chance that you will be able to modify behaviour by yourself in the installation sources. You may also contact someone from the software developers/maintainers community to suggest changes.
for Debian, relevant link: Debian Policy 9.3.3.1. Managing the links "The default behaviour is to enable autostarting your package's daemon." Since it's the policy manual, it describes choices made. (might not be up to date with systemd)
â A.B
Aug 13 at 13:04
@A.B Thanks for answer. That's exactly what I was looking for.
â RndGuyFromInternet
Aug 13 at 13:14
add a comment |Â
up vote
3
down vote
up vote
3
down vote
1) On what does this behavior depend? Is it some setting in package manager or the package itself decides whether it is enabled or not?
Each distribution may use different package managers like apt in Debian or pacman in Arch Linux. This requires software developers and/or package maintainers to prepare a package in various (often incoherent) ways. Such differences may be related to the settings in the package, but sometimes the package may be prepared without assumption that systemd will be used on the target system.
2) How can I change it?
Find out how the specific package for your distribution is prepared and maintaned, and who is responsible for it. If it's open source, there's a chance that you will be able to modify behaviour by yourself in the installation sources. You may also contact someone from the software developers/maintainers community to suggest changes.
1) On what does this behavior depend? Is it some setting in package manager or the package itself decides whether it is enabled or not?
Each distribution may use different package managers like apt in Debian or pacman in Arch Linux. This requires software developers and/or package maintainers to prepare a package in various (often incoherent) ways. Such differences may be related to the settings in the package, but sometimes the package may be prepared without assumption that systemd will be used on the target system.
2) How can I change it?
Find out how the specific package for your distribution is prepared and maintaned, and who is responsible for it. If it's open source, there's a chance that you will be able to modify behaviour by yourself in the installation sources. You may also contact someone from the software developers/maintainers community to suggest changes.
edited Aug 13 at 12:56
Rui F Ribeiro
36.6k1271116
36.6k1271116
answered Aug 13 at 12:55
Michaà  Kasià Âski
311
311
for Debian, relevant link: Debian Policy 9.3.3.1. Managing the links "The default behaviour is to enable autostarting your package's daemon." Since it's the policy manual, it describes choices made. (might not be up to date with systemd)
â A.B
Aug 13 at 13:04
@A.B Thanks for answer. That's exactly what I was looking for.
â RndGuyFromInternet
Aug 13 at 13:14
add a comment |Â
for Debian, relevant link: Debian Policy 9.3.3.1. Managing the links "The default behaviour is to enable autostarting your package's daemon." Since it's the policy manual, it describes choices made. (might not be up to date with systemd)
â A.B
Aug 13 at 13:04
@A.B Thanks for answer. That's exactly what I was looking for.
â RndGuyFromInternet
Aug 13 at 13:14
for Debian, relevant link: Debian Policy 9.3.3.1. Managing the links "The default behaviour is to enable autostarting your package's daemon." Since it's the policy manual, it describes choices made. (might not be up to date with systemd)
â A.B
Aug 13 at 13:04
for Debian, relevant link: Debian Policy 9.3.3.1. Managing the links "The default behaviour is to enable autostarting your package's daemon." Since it's the policy manual, it describes choices made. (might not be up to date with systemd)
â A.B
Aug 13 at 13:04
@A.B Thanks for answer. That's exactly what I was looking for.
â RndGuyFromInternet
Aug 13 at 13:14
@A.B Thanks for answer. That's exactly what I was looking for.
â RndGuyFromInternet
Aug 13 at 13:14
add a comment |Â
There is not much option about avoiding systemd using Linux except if using Slackware or other small distros like AntiX
â Rui F Ribeiro
Aug 13 at 12:37
1
without-systemd.org/wiki/index.php/â¦
â arochester
Aug 13 at 12:46
@RuiFRibeiro My question is not about systemd itself, but about services thar systemd manages.
â RndGuyFromInternet
Aug 13 at 12:47
Arch assumes you know what you are doing; Debian is agnostic on that front.
â jasonwryan
Aug 13 at 17:44