Is [Install] section obligatory for autostart services in systemd?
up vote
1
down vote
favorite
I am reading https://www.freedesktop.org/software/systemd/man/systemd.service.html and can not find information if [Install] section is required for service autostart.
systemd
asked Nov 27 at 5:47
anatoly techtonik
862825
add a comment |
up vote
1
down vote
favorite
I am reading https://www.freedesktop.org/software/systemd/man/systemd.service.html and can not find information if [Install] section is required for service autostart.
systemd
asked Nov 27 at 5:47
anatoly techtonik
862825
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am reading https://www.freedesktop.org/software/systemd/man/systemd.service.html and can not find information if [Install] section is required for service autostart.
systemd
asked Nov 27 at 5:47
anatoly techtonik
862825
I am reading https://www.freedesktop.org/software/systemd/man/systemd.service.html and can not find information if [Install] section is required for service autostart.
systemd
systemd
asked Nov 27 at 5:47
anatoly techtonik
862825
asked Nov 27 at 5:47
anatoly techtonik
862825
asked Nov 27 at 5:47
anatoly techtonik
862825
asked Nov 27 at 5:47
anatoly techtonik
862825
asked Nov 27 at 5:47
anatoly techtonik
862825
862825
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
The standard way to make some program executed on startup with systemd is to create .service file for it, place that file into corresponding directory and run systemctl enable <service> to enable it for startup sequence. [Install] section is mandatory here, because it tells systemd at which moment during boot process your service should be started. You process should be linked to some generic boot targets such as multi-user.target or graphical.target, or to a special purpose target (such as network-online.target), or a custom local target.
Example:
[Install]
WantedBy=multi-user.target
Here systemd will inject your service as a dependency for multi-user.target. systemd will start your service whenever multi-user target is started.
systemd reads files (or symlinks) in its configuration directories to see which units should be started in what order. systemctl enable creates such symlinks for services that it already knows, and places these symlinks at the points at the boot process when the service should be started (e.g. in special multi-user.target.wants/ subdirectory.)
There is also another way how operating system uses systemd to start its own services at startup. It is not something that should you do, but since the question is about [Install] section...
There are systemd units called "static" units and they are not managed by systemctl enable (or systemctl disable.) They are started on boot through hardcoded symlinks in /usr/lib/systemd/system/ (instead of /etc/systemd/system/), and if you encounter them while looking at units in your system... know that they don't have [Install] section.
(You can see the discussion in this forum post for even more details on static units.)
answered Nov 27 at 5:53
Filipe Brandenburger
6,6701732
OMG. That's surely confusing! I thought there is only one way to autostartsystemdservices. That is - withsystemctl enable. Now I need to study a whole chapter about those "static". =)
– anatoly techtonik
Nov 27 at 7:32
Actually, for the most part you should just ignore "static" units. They're meant to be used by the Linux distribution, for services they want to always start and not allow the administrator to control them... In practice, you'll always want to use non-static units, so always include an[Install]section is a good advice.
– Filipe Brandenburger
Nov 27 at 7:37
1
Well, the[Install]section is obligatory for.services that you want to manage withsystemctl enable. I'd argue that in 99% of cases, you want to be able to manage your.services withsystemctl enable. If you're curious, there's also this other thing called "static" units, which will also auto-start on boot, but they don't have an[Install]section (and can't be managed withsystemctl disable), but that feature is meant to be used by Linux distributions only, so you should really not care about it, and always include an[Install]section. :-)
– Filipe Brandenburger
Nov 27 at 7:55
1
I edited you answer with all info I wanted to know, but was afraid to ask. Please, check that I did't misguide anyone. I thought that symlinking is too low level detail until I understand high level logic, so I omitted it until the very end.
– anatoly techtonik
Nov 27 at 12:16
1
@anatolytechtonik I reviewed your edits, moved things around a little bit and approved it. One point is that "static" units are not as opposed to "service" units. You can have units of any kind ("service", "target", "socket", "path") that are "static", so it's an orthogonal concept. Thanks for your edit, your suggestions were great. Cheers!
– Filipe Brandenburger
Nov 27 at 15:44
|
show 3 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
The standard way to make some program executed on startup with systemd is to create .service file for it, place that file into corresponding directory and run systemctl enable <service> to enable it for startup sequence. [Install] section is mandatory here, because it tells systemd at which moment during boot process your service should be started. You process should be linked to some generic boot targets such as multi-user.target or graphical.target, or to a special purpose target (such as network-online.target), or a custom local target.
Example:
[Install]
WantedBy=multi-user.target
Here systemd will inject your service as a dependency for multi-user.target. systemd will start your service whenever multi-user target is started.
systemd reads files (or symlinks) in its configuration directories to see which units should be started in what order. systemctl enable creates such symlinks for services that it already knows, and places these symlinks at the points at the boot process when the service should be started (e.g. in special multi-user.target.wants/ subdirectory.)
There is also another way how operating system uses systemd to start its own services at startup. It is not something that should you do, but since the question is about [Install] section...
There are systemd units called "static" units and they are not managed by systemctl enable (or systemctl disable.) They are started on boot through hardcoded symlinks in /usr/lib/systemd/system/ (instead of /etc/systemd/system/), and if you encounter them while looking at units in your system... know that they don't have [Install] section.
(You can see the discussion in this forum post for even more details on static units.)
answered Nov 27 at 5:53
Filipe Brandenburger
6,6701732
OMG. That's surely confusing! I thought there is only one way to autostartsystemdservices. That is - withsystemctl enable. Now I need to study a whole chapter about those "static". =)
– anatoly techtonik
Nov 27 at 7:32
Actually, for the most part you should just ignore "static" units. They're meant to be used by the Linux distribution, for services they want to always start and not allow the administrator to control them... In practice, you'll always want to use non-static units, so always include an[Install]section is a good advice.
– Filipe Brandenburger
Nov 27 at 7:37
1
Well, the[Install]section is obligatory for.services that you want to manage withsystemctl enable. I'd argue that in 99% of cases, you want to be able to manage your.services withsystemctl enable. If you're curious, there's also this other thing called "static" units, which will also auto-start on boot, but they don't have an[Install]section (and can't be managed withsystemctl disable), but that feature is meant to be used by Linux distributions only, so you should really not care about it, and always include an[Install]section. :-)
– Filipe Brandenburger
Nov 27 at 7:55
1
I edited you answer with all info I wanted to know, but was afraid to ask. Please, check that I did't misguide anyone. I thought that symlinking is too low level detail until I understand high level logic, so I omitted it until the very end.
– anatoly techtonik
Nov 27 at 12:16
1
@anatolytechtonik I reviewed your edits, moved things around a little bit and approved it. One point is that "static" units are not as opposed to "service" units. You can have units of any kind ("service", "target", "socket", "path") that are "static", so it's an orthogonal concept. Thanks for your edit, your suggestions were great. Cheers!
– Filipe Brandenburger
Nov 27 at 15:44
|
show 3 more comments
up vote
1
down vote
accepted
The standard way to make some program executed on startup with systemd is to create .service file for it, place that file into corresponding directory and run systemctl enable <service> to enable it for startup sequence. [Install] section is mandatory here, because it tells systemd at which moment during boot process your service should be started. You process should be linked to some generic boot targets such as multi-user.target or graphical.target, or to a special purpose target (such as network-online.target), or a custom local target.
Example:
[Install]
WantedBy=multi-user.target
Here systemd will inject your service as a dependency for multi-user.target. systemd will start your service whenever multi-user target is started.
systemd reads files (or symlinks) in its configuration directories to see which units should be started in what order. systemctl enable creates such symlinks for services that it already knows, and places these symlinks at the points at the boot process when the service should be started (e.g. in special multi-user.target.wants/ subdirectory.)
There is also another way how operating system uses systemd to start its own services at startup. It is not something that should you do, but since the question is about [Install] section...
There are systemd units called "static" units and they are not managed by systemctl enable (or systemctl disable.) They are started on boot through hardcoded symlinks in /usr/lib/systemd/system/ (instead of /etc/systemd/system/), and if you encounter them while looking at units in your system... know that they don't have [Install] section.
(You can see the discussion in this forum post for even more details on static units.)
answered Nov 27 at 5:53
Filipe Brandenburger
6,6701732
OMG. That's surely confusing! I thought there is only one way to autostartsystemdservices. That is - withsystemctl enable. Now I need to study a whole chapter about those "static". =)
– anatoly techtonik
Nov 27 at 7:32
Actually, for the most part you should just ignore "static" units. They're meant to be used by the Linux distribution, for services they want to always start and not allow the administrator to control them... In practice, you'll always want to use non-static units, so always include an[Install]section is a good advice.
– Filipe Brandenburger
Nov 27 at 7:37
1
Well, the[Install]section is obligatory for.services that you want to manage withsystemctl enable. I'd argue that in 99% of cases, you want to be able to manage your.services withsystemctl enable. If you're curious, there's also this other thing called "static" units, which will also auto-start on boot, but they don't have an[Install]section (and can't be managed withsystemctl disable), but that feature is meant to be used by Linux distributions only, so you should really not care about it, and always include an[Install]section. :-)
– Filipe Brandenburger
Nov 27 at 7:55
1
I edited you answer with all info I wanted to know, but was afraid to ask. Please, check that I did't misguide anyone. I thought that symlinking is too low level detail until I understand high level logic, so I omitted it until the very end.
– anatoly techtonik
Nov 27 at 12:16
1
@anatolytechtonik I reviewed your edits, moved things around a little bit and approved it. One point is that "static" units are not as opposed to "service" units. You can have units of any kind ("service", "target", "socket", "path") that are "static", so it's an orthogonal concept. Thanks for your edit, your suggestions were great. Cheers!
– Filipe Brandenburger
Nov 27 at 15:44
|
show 3 more comments
up vote
1
down vote
accepted
up vote
1
down vote
accepted
The standard way to make some program executed on startup with systemd is to create .service file for it, place that file into corresponding directory and run systemctl enable <service> to enable it for startup sequence. [Install] section is mandatory here, because it tells systemd at which moment during boot process your service should be started. You process should be linked to some generic boot targets such as multi-user.target or graphical.target, or to a special purpose target (such as network-online.target), or a custom local target.
Example:
[Install]
WantedBy=multi-user.target
Here systemd will inject your service as a dependency for multi-user.target. systemd will start your service whenever multi-user target is started.
systemd reads files (or symlinks) in its configuration directories to see which units should be started in what order. systemctl enable creates such symlinks for services that it already knows, and places these symlinks at the points at the boot process when the service should be started (e.g. in special multi-user.target.wants/ subdirectory.)
There is also another way how operating system uses systemd to start its own services at startup. It is not something that should you do, but since the question is about [Install] section...
There are systemd units called "static" units and they are not managed by systemctl enable (or systemctl disable.) They are started on boot through hardcoded symlinks in /usr/lib/systemd/system/ (instead of /etc/systemd/system/), and if you encounter them while looking at units in your system... know that they don't have [Install] section.
(You can see the discussion in this forum post for even more details on static units.)
answered Nov 27 at 5:53
Filipe Brandenburger
6,6701732
The standard way to make some program executed on startup with systemd is to create .service file for it, place that file into corresponding directory and run systemctl enable <service> to enable it for startup sequence. [Install] section is mandatory here, because it tells systemd at which moment during boot process your service should be started. You process should be linked to some generic boot targets such as multi-user.target or graphical.target, or to a special purpose target (such as network-online.target), or a custom local target.
Example:
[Install]
WantedBy=multi-user.target
Here systemd will inject your service as a dependency for multi-user.target. systemd will start your service whenever multi-user target is started.
systemd reads files (or symlinks) in its configuration directories to see which units should be started in what order. systemctl enable creates such symlinks for services that it already knows, and places these symlinks at the points at the boot process when the service should be started (e.g. in special multi-user.target.wants/ subdirectory.)
There is also another way how operating system uses systemd to start its own services at startup. It is not something that should you do, but since the question is about [Install] section...
There are systemd units called "static" units and they are not managed by systemctl enable (or systemctl disable.) They are started on boot through hardcoded symlinks in /usr/lib/systemd/system/ (instead of /etc/systemd/system/), and if you encounter them while looking at units in your system... know that they don't have [Install] section.
(You can see the discussion in this forum post for even more details on static units.)
answered Nov 27 at 5:53
Filipe Brandenburger
6,6701732
edited Nov 27 at 15:43
answered Nov 27 at 5:53
Filipe Brandenburger
6,6701732
answered Nov 27 at 5:53
Filipe Brandenburger
6,6701732
answered Nov 27 at 5:53
Filipe Brandenburger
6,6701732
6,6701732
OMG. That's surely confusing! I thought there is only one way to autostartsystemdservices. That is - withsystemctl enable. Now I need to study a whole chapter about those "static". =)
– anatoly techtonik
Nov 27 at 7:32
Actually, for the most part you should just ignore "static" units. They're meant to be used by the Linux distribution, for services they want to always start and not allow the administrator to control them... In practice, you'll always want to use non-static units, so always include an[Install]section is a good advice.
– Filipe Brandenburger
Nov 27 at 7:37
1
Well, the[Install]section is obligatory for.services that you want to manage withsystemctl enable. I'd argue that in 99% of cases, you want to be able to manage your.services withsystemctl enable. If you're curious, there's also this other thing called "static" units, which will also auto-start on boot, but they don't have an[Install]section (and can't be managed withsystemctl disable), but that feature is meant to be used by Linux distributions only, so you should really not care about it, and always include an[Install]section. :-)
– Filipe Brandenburger
Nov 27 at 7:55
1
I edited you answer with all info I wanted to know, but was afraid to ask. Please, check that I did't misguide anyone. I thought that symlinking is too low level detail until I understand high level logic, so I omitted it until the very end.
– anatoly techtonik
Nov 27 at 12:16
1
@anatolytechtonik I reviewed your edits, moved things around a little bit and approved it. One point is that "static" units are not as opposed to "service" units. You can have units of any kind ("service", "target", "socket", "path") that are "static", so it's an orthogonal concept. Thanks for your edit, your suggestions were great. Cheers!
– Filipe Brandenburger
Nov 27 at 15:44
|
show 3 more comments
OMG. That's surely confusing! I thought there is only one way to autostartsystemdservices. That is - withsystemctl enable. Now I need to study a whole chapter about those "static". =)
– anatoly techtonik
Nov 27 at 7:32
Actually, for the most part you should just ignore "static" units. They're meant to be used by the Linux distribution, for services they want to always start and not allow the administrator to control them... In practice, you'll always want to use non-static units, so always include an[Install]section is a good advice.
– Filipe Brandenburger
Nov 27 at 7:37
1
Well, the[Install]section is obligatory for.services that you want to manage withsystemctl enable. I'd argue that in 99% of cases, you want to be able to manage your.services withsystemctl enable. If you're curious, there's also this other thing called "static" units, which will also auto-start on boot, but they don't have an[Install]section (and can't be managed withsystemctl disable), but that feature is meant to be used by Linux distributions only, so you should really not care about it, and always include an[Install]section. :-)
– Filipe Brandenburger
Nov 27 at 7:55
1
I edited you answer with all info I wanted to know, but was afraid to ask. Please, check that I did't misguide anyone. I thought that symlinking is too low level detail until I understand high level logic, so I omitted it until the very end.
– anatoly techtonik
Nov 27 at 12:16
1
@anatolytechtonik I reviewed your edits, moved things around a little bit and approved it. One point is that "static" units are not as opposed to "service" units. You can have units of any kind ("service", "target", "socket", "path") that are "static", so it's an orthogonal concept. Thanks for your edit, your suggestions were great. Cheers!
– Filipe Brandenburger
Nov 27 at 15:44
OMG. That's surely confusing! I thought there is only one way to autostart
systemd services. That is - with systemctl enable. Now I need to study a whole chapter about those "static". =)– anatoly techtonik
Nov 27 at 7:32
OMG. That's surely confusing! I thought there is only one way to autostart
systemd services. That is - with systemctl enable. Now I need to study a whole chapter about those "static". =)– anatoly techtonik
Nov 27 at 7:32
Actually, for the most part you should just ignore "static" units. They're meant to be used by the Linux distribution, for services they want to always start and not allow the administrator to control them... In practice, you'll always want to use non-static units, so always include an
[Install] section is a good advice.– Filipe Brandenburger
Nov 27 at 7:37
Actually, for the most part you should just ignore "static" units. They're meant to be used by the Linux distribution, for services they want to always start and not allow the administrator to control them... In practice, you'll always want to use non-static units, so always include an
[Install] section is a good advice.– Filipe Brandenburger
Nov 27 at 7:37
1
1
Well, the
[Install] section is obligatory for .services that you want to manage with systemctl enable. I'd argue that in 99% of cases, you want to be able to manage your .services with systemctl enable. If you're curious, there's also this other thing called "static" units, which will also auto-start on boot, but they don't have an [Install] section (and can't be managed with systemctl disable), but that feature is meant to be used by Linux distributions only, so you should really not care about it, and always include an [Install] section. :-)– Filipe Brandenburger
Nov 27 at 7:55
Well, the
[Install] section is obligatory for .services that you want to manage with systemctl enable. I'd argue that in 99% of cases, you want to be able to manage your .services with systemctl enable. If you're curious, there's also this other thing called "static" units, which will also auto-start on boot, but they don't have an [Install] section (and can't be managed with systemctl disable), but that feature is meant to be used by Linux distributions only, so you should really not care about it, and always include an [Install] section. :-)– Filipe Brandenburger
Nov 27 at 7:55
1
1
I edited you answer with all info I wanted to know, but was afraid to ask. Please, check that I did't misguide anyone. I thought that symlinking is too low level detail until I understand high level logic, so I omitted it until the very end.
– anatoly techtonik
Nov 27 at 12:16
I edited you answer with all info I wanted to know, but was afraid to ask. Please, check that I did't misguide anyone. I thought that symlinking is too low level detail until I understand high level logic, so I omitted it until the very end.
– anatoly techtonik
Nov 27 at 12:16
1
1
@anatolytechtonik I reviewed your edits, moved things around a little bit and approved it. One point is that "static" units are not as opposed to "service" units. You can have units of any kind ("service", "target", "socket", "path") that are "static", so it's an orthogonal concept. Thanks for your edit, your suggestions were great. Cheers!
– Filipe Brandenburger
Nov 27 at 15:44
@anatolytechtonik I reviewed your edits, moved things around a little bit and approved it. One point is that "static" units are not as opposed to "service" units. You can have units of any kind ("service", "target", "socket", "path") that are "static", so it's an orthogonal concept. Thanks for your edit, your suggestions were great. Cheers!
– Filipe Brandenburger
Nov 27 at 15:44
|
show 3 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f484366%2fis-install-section-obligatory-for-autostart-services-in-systemd%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
