Systemd's StartLimitIntervalSec and StartLimitBurst never work
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I tried to restrict the number of a service (in a container) restart. The OS version is centos-release-7-5, the service file is pretty much as below (removed some parameters for reading convenience). It should be pretty straight forward as some other posts pointed out (Post of Server Fault restart limit 1 , Post of Stack Overflow restart limit 2 ). Yet StartLimitBurst and StartLimitIntervalSec never works for me.
I tested with several ways: (1) I check the service PID, kill the service with "kill -9 ****" several times. The service always gets restarted after 20s! (2) I also tried to mess up the service file, make the container never runs. Still, it doesn't work, the service file just keep restarting.
Any idea?
[Unit]
Description=Hello Fluentd
After=docker.service
Requires=docker.service
StartLimitBurst=2
StartLimitIntervalSec=150s
[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker stop "fluentd"
ExecStartPre=-/usr/bin/docker rm -f "fluentd"
ExecStart=/usr/bin/docker run fluentd
ExecStop=/usr/bin/docker stop "fluentd"
Restart=always
RestartSec=20s
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
linux systemd
add a comment |Â
up vote
3
down vote
favorite
I tried to restrict the number of a service (in a container) restart. The OS version is centos-release-7-5, the service file is pretty much as below (removed some parameters for reading convenience). It should be pretty straight forward as some other posts pointed out (Post of Server Fault restart limit 1 , Post of Stack Overflow restart limit 2 ). Yet StartLimitBurst and StartLimitIntervalSec never works for me.
I tested with several ways: (1) I check the service PID, kill the service with "kill -9 ****" several times. The service always gets restarted after 20s! (2) I also tried to mess up the service file, make the container never runs. Still, it doesn't work, the service file just keep restarting.
Any idea?
[Unit]
Description=Hello Fluentd
After=docker.service
Requires=docker.service
StartLimitBurst=2
StartLimitIntervalSec=150s
[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker stop "fluentd"
ExecStartPre=-/usr/bin/docker rm -f "fluentd"
ExecStart=/usr/bin/docker run fluentd
ExecStop=/usr/bin/docker stop "fluentd"
Restart=always
RestartSec=20s
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
linux systemd
2
This is more significant than someone forgetting to type "Sec", as shown by the answers. I do not think it is helpful to close such a question, which was asked with so many of the details we want.
â sourcejedi
Aug 22 at 10:28
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I tried to restrict the number of a service (in a container) restart. The OS version is centos-release-7-5, the service file is pretty much as below (removed some parameters for reading convenience). It should be pretty straight forward as some other posts pointed out (Post of Server Fault restart limit 1 , Post of Stack Overflow restart limit 2 ). Yet StartLimitBurst and StartLimitIntervalSec never works for me.
I tested with several ways: (1) I check the service PID, kill the service with "kill -9 ****" several times. The service always gets restarted after 20s! (2) I also tried to mess up the service file, make the container never runs. Still, it doesn't work, the service file just keep restarting.
Any idea?
[Unit]
Description=Hello Fluentd
After=docker.service
Requires=docker.service
StartLimitBurst=2
StartLimitIntervalSec=150s
[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker stop "fluentd"
ExecStartPre=-/usr/bin/docker rm -f "fluentd"
ExecStart=/usr/bin/docker run fluentd
ExecStop=/usr/bin/docker stop "fluentd"
Restart=always
RestartSec=20s
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
linux systemd
I tried to restrict the number of a service (in a container) restart. The OS version is centos-release-7-5, the service file is pretty much as below (removed some parameters for reading convenience). It should be pretty straight forward as some other posts pointed out (Post of Server Fault restart limit 1 , Post of Stack Overflow restart limit 2 ). Yet StartLimitBurst and StartLimitIntervalSec never works for me.
I tested with several ways: (1) I check the service PID, kill the service with "kill -9 ****" several times. The service always gets restarted after 20s! (2) I also tried to mess up the service file, make the container never runs. Still, it doesn't work, the service file just keep restarting.
Any idea?
[Unit]
Description=Hello Fluentd
After=docker.service
Requires=docker.service
StartLimitBurst=2
StartLimitIntervalSec=150s
[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker stop "fluentd"
ExecStartPre=-/usr/bin/docker rm -f "fluentd"
ExecStart=/usr/bin/docker run fluentd
ExecStop=/usr/bin/docker stop "fluentd"
Restart=always
RestartSec=20s
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
linux systemd
linux systemd
asked Aug 21 at 16:40
batilei
384
384
2
This is more significant than someone forgetting to type "Sec", as shown by the answers. I do not think it is helpful to close such a question, which was asked with so many of the details we want.
â sourcejedi
Aug 22 at 10:28
add a comment |Â
2
This is more significant than someone forgetting to type "Sec", as shown by the answers. I do not think it is helpful to close such a question, which was asked with so many of the details we want.
â sourcejedi
Aug 22 at 10:28
2
2
This is more significant than someone forgetting to type "Sec", as shown by the answers. I do not think it is helpful to close such a question, which was asked with so many of the details we want.
â sourcejedi
Aug 22 at 10:28
This is more significant than someone forgetting to type "Sec", as shown by the answers. I do not think it is helpful to close such a question, which was asked with so many of the details we want.
â sourcejedi
Aug 22 at 10:28
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
4
down vote
accepted
StartLimitIntervalSec=
was added as part of systemd v230. In systemd v229 and below, you can only use StartLimitInterval=
. You will also need to put StartLimitInterval=
and StartLimitBurst=
in the [Service]
section - not the [Unit]
section.
To check your systemd version on CentOS, run rpm -q systemd
.
If you ever upgrade to systemd v230 or above, the old names in the [Service]
section will continue to work.
Source: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html
You can have this problem without seeing any error at all, because systemd ignores unknown directives. systemd assumes that many newer directives can be ignored and still allow the service to run.
It is possible to manually check a unit file for unknown directives. At least it seems to work on recent systemd:
$ systemd-analyze verify foo.service
/etc/systemd/system/foo.service:9: Unknown lvalue 'FancyNewOption' in section 'Service'
I suggest you make this answer complete by indicating that the problem should be solved by moving the directive from Unit to Service and using the old name. Right now, this answer only makes sense after reading the other one, but this one has way more details, so would make sense as the accepted answer, as long as it is complete on its own...
â Filipe Brandenburger
Aug 22 at 13:59
1
@FilipeBrandenburger indeed, hope this is better.
â sourcejedi
Aug 22 at 14:16
add a comment |Â
up vote
2
down vote
I think I found the issue. All the doc online suggests those all parameters are in UNIT file (systemd unit file), but still in my system (centos 7.5), they are in service file. Besides the name is "StartLimitInterval", not "StartLimitIntervalSec".
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
StartLimitIntervalSec=
was added as part of systemd v230. In systemd v229 and below, you can only use StartLimitInterval=
. You will also need to put StartLimitInterval=
and StartLimitBurst=
in the [Service]
section - not the [Unit]
section.
To check your systemd version on CentOS, run rpm -q systemd
.
If you ever upgrade to systemd v230 or above, the old names in the [Service]
section will continue to work.
Source: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html
You can have this problem without seeing any error at all, because systemd ignores unknown directives. systemd assumes that many newer directives can be ignored and still allow the service to run.
It is possible to manually check a unit file for unknown directives. At least it seems to work on recent systemd:
$ systemd-analyze verify foo.service
/etc/systemd/system/foo.service:9: Unknown lvalue 'FancyNewOption' in section 'Service'
I suggest you make this answer complete by indicating that the problem should be solved by moving the directive from Unit to Service and using the old name. Right now, this answer only makes sense after reading the other one, but this one has way more details, so would make sense as the accepted answer, as long as it is complete on its own...
â Filipe Brandenburger
Aug 22 at 13:59
1
@FilipeBrandenburger indeed, hope this is better.
â sourcejedi
Aug 22 at 14:16
add a comment |Â
up vote
4
down vote
accepted
StartLimitIntervalSec=
was added as part of systemd v230. In systemd v229 and below, you can only use StartLimitInterval=
. You will also need to put StartLimitInterval=
and StartLimitBurst=
in the [Service]
section - not the [Unit]
section.
To check your systemd version on CentOS, run rpm -q systemd
.
If you ever upgrade to systemd v230 or above, the old names in the [Service]
section will continue to work.
Source: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html
You can have this problem without seeing any error at all, because systemd ignores unknown directives. systemd assumes that many newer directives can be ignored and still allow the service to run.
It is possible to manually check a unit file for unknown directives. At least it seems to work on recent systemd:
$ systemd-analyze verify foo.service
/etc/systemd/system/foo.service:9: Unknown lvalue 'FancyNewOption' in section 'Service'
I suggest you make this answer complete by indicating that the problem should be solved by moving the directive from Unit to Service and using the old name. Right now, this answer only makes sense after reading the other one, but this one has way more details, so would make sense as the accepted answer, as long as it is complete on its own...
â Filipe Brandenburger
Aug 22 at 13:59
1
@FilipeBrandenburger indeed, hope this is better.
â sourcejedi
Aug 22 at 14:16
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
StartLimitIntervalSec=
was added as part of systemd v230. In systemd v229 and below, you can only use StartLimitInterval=
. You will also need to put StartLimitInterval=
and StartLimitBurst=
in the [Service]
section - not the [Unit]
section.
To check your systemd version on CentOS, run rpm -q systemd
.
If you ever upgrade to systemd v230 or above, the old names in the [Service]
section will continue to work.
Source: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html
You can have this problem without seeing any error at all, because systemd ignores unknown directives. systemd assumes that many newer directives can be ignored and still allow the service to run.
It is possible to manually check a unit file for unknown directives. At least it seems to work on recent systemd:
$ systemd-analyze verify foo.service
/etc/systemd/system/foo.service:9: Unknown lvalue 'FancyNewOption' in section 'Service'
StartLimitIntervalSec=
was added as part of systemd v230. In systemd v229 and below, you can only use StartLimitInterval=
. You will also need to put StartLimitInterval=
and StartLimitBurst=
in the [Service]
section - not the [Unit]
section.
To check your systemd version on CentOS, run rpm -q systemd
.
If you ever upgrade to systemd v230 or above, the old names in the [Service]
section will continue to work.
Source: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html
You can have this problem without seeing any error at all, because systemd ignores unknown directives. systemd assumes that many newer directives can be ignored and still allow the service to run.
It is possible to manually check a unit file for unknown directives. At least it seems to work on recent systemd:
$ systemd-analyze verify foo.service
/etc/systemd/system/foo.service:9: Unknown lvalue 'FancyNewOption' in section 'Service'
edited Aug 22 at 14:20
answered Aug 22 at 10:06
sourcejedi
20.1k42886
20.1k42886
I suggest you make this answer complete by indicating that the problem should be solved by moving the directive from Unit to Service and using the old name. Right now, this answer only makes sense after reading the other one, but this one has way more details, so would make sense as the accepted answer, as long as it is complete on its own...
â Filipe Brandenburger
Aug 22 at 13:59
1
@FilipeBrandenburger indeed, hope this is better.
â sourcejedi
Aug 22 at 14:16
add a comment |Â
I suggest you make this answer complete by indicating that the problem should be solved by moving the directive from Unit to Service and using the old name. Right now, this answer only makes sense after reading the other one, but this one has way more details, so would make sense as the accepted answer, as long as it is complete on its own...
â Filipe Brandenburger
Aug 22 at 13:59
1
@FilipeBrandenburger indeed, hope this is better.
â sourcejedi
Aug 22 at 14:16
I suggest you make this answer complete by indicating that the problem should be solved by moving the directive from Unit to Service and using the old name. Right now, this answer only makes sense after reading the other one, but this one has way more details, so would make sense as the accepted answer, as long as it is complete on its own...
â Filipe Brandenburger
Aug 22 at 13:59
I suggest you make this answer complete by indicating that the problem should be solved by moving the directive from Unit to Service and using the old name. Right now, this answer only makes sense after reading the other one, but this one has way more details, so would make sense as the accepted answer, as long as it is complete on its own...
â Filipe Brandenburger
Aug 22 at 13:59
1
1
@FilipeBrandenburger indeed, hope this is better.
â sourcejedi
Aug 22 at 14:16
@FilipeBrandenburger indeed, hope this is better.
â sourcejedi
Aug 22 at 14:16
add a comment |Â
up vote
2
down vote
I think I found the issue. All the doc online suggests those all parameters are in UNIT file (systemd unit file), but still in my system (centos 7.5), they are in service file. Besides the name is "StartLimitInterval", not "StartLimitIntervalSec".
add a comment |Â
up vote
2
down vote
I think I found the issue. All the doc online suggests those all parameters are in UNIT file (systemd unit file), but still in my system (centos 7.5), they are in service file. Besides the name is "StartLimitInterval", not "StartLimitIntervalSec".
add a comment |Â
up vote
2
down vote
up vote
2
down vote
I think I found the issue. All the doc online suggests those all parameters are in UNIT file (systemd unit file), but still in my system (centos 7.5), they are in service file. Besides the name is "StartLimitInterval", not "StartLimitIntervalSec".
I think I found the issue. All the doc online suggests those all parameters are in UNIT file (systemd unit file), but still in my system (centos 7.5), they are in service file. Besides the name is "StartLimitInterval", not "StartLimitIntervalSec".
answered Aug 21 at 18:19
batilei
384
384
add a comment |Â
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f463917%2fsystemds-startlimitintervalsec-and-startlimitburst-never-work%23new-answer', 'question_page');
);
Post as a guest
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
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
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
2
This is more significant than someone forgetting to type "Sec", as shown by the answers. I do not think it is helpful to close such a question, which was asked with so many of the details we want.
â sourcejedi
Aug 22 at 10:28