Systemd Restart=always is not honored

Clash Royale CLAN TAG#URR8PPP
up vote
39
down vote
favorite
Note: I wrote an article on Medium that explains how to create a service, and how to avoid this particular issue: Creating a Linux service with systemd.
Original question:
I'm using systemd to keep a worker script working at all times:
[Unit]
Description=My worker
After=mysqld.service
[Service]
Type=simple
Restart=always
ExecStart=/path/to/script
[Install]
WantedBy=multi-user.target
Although the restart works fine if the script exits normally after a few minutes, I've noticed that if it repeatedly fails to execute on startup, systemd will just give up trying to start it:
Jun 14 11:10:31 localhost systemd[1]: test.service: Main process exited, code=exited, status=1/FAILURE
Jun 14 11:10:31 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:10:31 localhost systemd[1]: test.service: Failed with result 'exit-code'.
Jun 14 11:10:31 localhost systemd[1]: test.service: Service hold-off time over, scheduling restart.
Jun 14 11:10:31 localhost systemd[1]: test.service: Start request repeated too quickly.
Jun 14 11:10:31 localhost systemd[1]: Failed to start My worker.
Jun 14 11:10:31 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:10:31 localhost systemd[1]: test.service: Failed with result 'start-limit'.
Similarly, if my worker script fails several times with an exit status of 255, systemd gives up trying to restart it:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'exit-code'.
Jun 14 11:25:51 localhost systemd[1]: test.service: Service hold-off time over, scheduling restart.
Jun 14 11:25:51 localhost systemd[1]: test.service: Start request repeated too quickly.
Jun 14 11:25:51 localhost systemd[1]: Failed to start My worker.
Jun 14 11:25:51 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
Is there a way to force systemd to always retry after a few seconds?
systemd
add a comment |Â
up vote
39
down vote
favorite
Note: I wrote an article on Medium that explains how to create a service, and how to avoid this particular issue: Creating a Linux service with systemd.
Original question:
I'm using systemd to keep a worker script working at all times:
[Unit]
Description=My worker
After=mysqld.service
[Service]
Type=simple
Restart=always
ExecStart=/path/to/script
[Install]
WantedBy=multi-user.target
Although the restart works fine if the script exits normally after a few minutes, I've noticed that if it repeatedly fails to execute on startup, systemd will just give up trying to start it:
Jun 14 11:10:31 localhost systemd[1]: test.service: Main process exited, code=exited, status=1/FAILURE
Jun 14 11:10:31 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:10:31 localhost systemd[1]: test.service: Failed with result 'exit-code'.
Jun 14 11:10:31 localhost systemd[1]: test.service: Service hold-off time over, scheduling restart.
Jun 14 11:10:31 localhost systemd[1]: test.service: Start request repeated too quickly.
Jun 14 11:10:31 localhost systemd[1]: Failed to start My worker.
Jun 14 11:10:31 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:10:31 localhost systemd[1]: test.service: Failed with result 'start-limit'.
Similarly, if my worker script fails several times with an exit status of 255, systemd gives up trying to restart it:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'exit-code'.
Jun 14 11:25:51 localhost systemd[1]: test.service: Service hold-off time over, scheduling restart.
Jun 14 11:25:51 localhost systemd[1]: test.service: Start request repeated too quickly.
Jun 14 11:25:51 localhost systemd[1]: Failed to start My worker.
Jun 14 11:25:51 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
Is there a way to force systemd to always retry after a few seconds?
systemd
add a comment |Â
up vote
39
down vote
favorite
up vote
39
down vote
favorite
Note: I wrote an article on Medium that explains how to create a service, and how to avoid this particular issue: Creating a Linux service with systemd.
Original question:
I'm using systemd to keep a worker script working at all times:
[Unit]
Description=My worker
After=mysqld.service
[Service]
Type=simple
Restart=always
ExecStart=/path/to/script
[Install]
WantedBy=multi-user.target
Although the restart works fine if the script exits normally after a few minutes, I've noticed that if it repeatedly fails to execute on startup, systemd will just give up trying to start it:
Jun 14 11:10:31 localhost systemd[1]: test.service: Main process exited, code=exited, status=1/FAILURE
Jun 14 11:10:31 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:10:31 localhost systemd[1]: test.service: Failed with result 'exit-code'.
Jun 14 11:10:31 localhost systemd[1]: test.service: Service hold-off time over, scheduling restart.
Jun 14 11:10:31 localhost systemd[1]: test.service: Start request repeated too quickly.
Jun 14 11:10:31 localhost systemd[1]: Failed to start My worker.
Jun 14 11:10:31 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:10:31 localhost systemd[1]: test.service: Failed with result 'start-limit'.
Similarly, if my worker script fails several times with an exit status of 255, systemd gives up trying to restart it:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'exit-code'.
Jun 14 11:25:51 localhost systemd[1]: test.service: Service hold-off time over, scheduling restart.
Jun 14 11:25:51 localhost systemd[1]: test.service: Start request repeated too quickly.
Jun 14 11:25:51 localhost systemd[1]: Failed to start My worker.
Jun 14 11:25:51 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
Is there a way to force systemd to always retry after a few seconds?
systemd
Note: I wrote an article on Medium that explains how to create a service, and how to avoid this particular issue: Creating a Linux service with systemd.
Original question:
I'm using systemd to keep a worker script working at all times:
[Unit]
Description=My worker
After=mysqld.service
[Service]
Type=simple
Restart=always
ExecStart=/path/to/script
[Install]
WantedBy=multi-user.target
Although the restart works fine if the script exits normally after a few minutes, I've noticed that if it repeatedly fails to execute on startup, systemd will just give up trying to start it:
Jun 14 11:10:31 localhost systemd[1]: test.service: Main process exited, code=exited, status=1/FAILURE
Jun 14 11:10:31 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:10:31 localhost systemd[1]: test.service: Failed with result 'exit-code'.
Jun 14 11:10:31 localhost systemd[1]: test.service: Service hold-off time over, scheduling restart.
Jun 14 11:10:31 localhost systemd[1]: test.service: Start request repeated too quickly.
Jun 14 11:10:31 localhost systemd[1]: Failed to start My worker.
Jun 14 11:10:31 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:10:31 localhost systemd[1]: test.service: Failed with result 'start-limit'.
Similarly, if my worker script fails several times with an exit status of 255, systemd gives up trying to restart it:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'exit-code'.
Jun 14 11:25:51 localhost systemd[1]: test.service: Service hold-off time over, scheduling restart.
Jun 14 11:25:51 localhost systemd[1]: test.service: Start request repeated too quickly.
Jun 14 11:25:51 localhost systemd[1]: Failed to start My worker.
Jun 14 11:25:51 localhost systemd[1]: test.service: Unit entered failed state.
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
Is there a way to force systemd to always retry after a few seconds?
systemd
systemd
edited Sep 5 '17 at 10:41
asked Jun 14 '16 at 9:21
Benjamin
1,17031833
1,17031833
add a comment |Â
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
37
down vote
accepted
I would like to extend Rahul's answer a bit.
SystemD tries to restart multiple times (StartLimitBurst) and stops trying if the attempt count is reached within StartLimitIntervalSec. Both options belong to the [unit] section.
The default delay between executions is 100ms (RestartSec) which causes the rate limit to be reached very fast.
SystemD won't attempt any more automatic restarts ever for units with Restart policy defined:
Note that units which are configured for
Restart=and which reach the
start limit are not attempted to be restarted anymore; however, they
may still be restarted manually at a later point, from which point on,
the restart logic is again activated.
Rahul's answer helps, because the longer delay prevents reaching the error counter within the StartLimitIntervalSec time. The correct answer is to set both RestartSec and StartLimitBurst to reasonable values though.
4
Now that I (finally) understand how it works, after some trial-and-error, I can see that your answer is the most correct. Bottom line for me: setStartLimitIntervalSec=0and voilà .
â Benjamin
Aug 26 '17 at 15:42
add a comment |Â
up vote
20
down vote
Yes, there is. You can specify to retry after x seconds under [Service] section,
[Service]
Type=simple
Restart=always
RestartSec=3
ExecStart=/path/to/script
After saving the file you need to reload the daemon configurations to ensure systemd is aware of the new file,
systemctl daemon-reload
then restart the service to enable changes,
systemctl restart test
As you have requested, Looking at the documentation,
Restart=on-failure
sounds like a decent recommendation.
It seems to work indeed, thank you! So to understand this better, without aRestartSecdirective,systemdattempts severals restarts very quickly, then enters a permanent failure state; something that cannot happen whenRestartSecis specified?
â Benjamin
Jun 14 '16 at 9:48
Also, I've noticed that it delays the "normal" restart of my worker (I'm purposefully exiting the worker gracefully after a few minutes); is there a way to only delay a failed restart?
â Benjamin
Jun 14 '16 at 9:50
@Benjamin see my updates
â Rahul
Jun 14 '16 at 9:53
@Benjamin you can check here for more parameters.
â Rahul
Jun 14 '16 at 9:57
2
Judging by the doc,alwaysis a superset ofon-failure, so it won't help!
â Benjamin
Jun 14 '16 at 10:10
 |Â
show 2 more comments
up vote
4
down vote
systemd gives up trying to restart it
No. systemd gives up trying to restart it for a little while. This is clearly shown in the log that you supply:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
This is rate limiting kicking in.
The length of the little while is specified in the service unit, using the StartLimitIntervalSec= setting. The number of starts that are needed within that interval to trigger the rate limiting mechanism are specified via the StartLimitBurst= setting. If nothing on your system differs from vanilla systemd, including the defaults for these two settings, then it is 5 times within 10 seconds.
StartLimitIntervalSec=0 disables rate limiting. But making your service either not exit so often, or idle enough between exits and restarts that it does not exceed the rate limiting threshold, is a better approach.
Note that rate limiting does not care how your service exited. It triggers on the number of attempts to start/restart it, irrespective of their cause.
Further reading
- Lennart Poettering (2013-10-07).
systemd.unit. systemd manual pages. freedesktop.org. - Systemd's StartLimitIntervalSec and StartLimitBurst never work
4
It does seem to give up permanently, though: "Active: failed (Result: start-limit) since Wed 2016-06-15 01:21:24 CEST; 12h ago". It stays in this state and the script is never executed again. I tried setting manuallyStartLimitIntervalSec=10andStartLimitIntervalSec=5, no luck.
â Benjamin
Jun 15 '16 at 11:55
4
It does give up permanently by default. See github.com/systemd/systemd/issues/2416.
â Adam Goode
Apr 22 '17 at 17:10
1
Bottom line: to stop prevent it from giving up permanently, setStartLimitIntervalSec=0.
â Benjamin
Aug 26 '17 at 15:43
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
37
down vote
accepted
I would like to extend Rahul's answer a bit.
SystemD tries to restart multiple times (StartLimitBurst) and stops trying if the attempt count is reached within StartLimitIntervalSec. Both options belong to the [unit] section.
The default delay between executions is 100ms (RestartSec) which causes the rate limit to be reached very fast.
SystemD won't attempt any more automatic restarts ever for units with Restart policy defined:
Note that units which are configured for
Restart=and which reach the
start limit are not attempted to be restarted anymore; however, they
may still be restarted manually at a later point, from which point on,
the restart logic is again activated.
Rahul's answer helps, because the longer delay prevents reaching the error counter within the StartLimitIntervalSec time. The correct answer is to set both RestartSec and StartLimitBurst to reasonable values though.
4
Now that I (finally) understand how it works, after some trial-and-error, I can see that your answer is the most correct. Bottom line for me: setStartLimitIntervalSec=0and voilà .
â Benjamin
Aug 26 '17 at 15:42
add a comment |Â
up vote
37
down vote
accepted
I would like to extend Rahul's answer a bit.
SystemD tries to restart multiple times (StartLimitBurst) and stops trying if the attempt count is reached within StartLimitIntervalSec. Both options belong to the [unit] section.
The default delay between executions is 100ms (RestartSec) which causes the rate limit to be reached very fast.
SystemD won't attempt any more automatic restarts ever for units with Restart policy defined:
Note that units which are configured for
Restart=and which reach the
start limit are not attempted to be restarted anymore; however, they
may still be restarted manually at a later point, from which point on,
the restart logic is again activated.
Rahul's answer helps, because the longer delay prevents reaching the error counter within the StartLimitIntervalSec time. The correct answer is to set both RestartSec and StartLimitBurst to reasonable values though.
4
Now that I (finally) understand how it works, after some trial-and-error, I can see that your answer is the most correct. Bottom line for me: setStartLimitIntervalSec=0and voilà .
â Benjamin
Aug 26 '17 at 15:42
add a comment |Â
up vote
37
down vote
accepted
up vote
37
down vote
accepted
I would like to extend Rahul's answer a bit.
SystemD tries to restart multiple times (StartLimitBurst) and stops trying if the attempt count is reached within StartLimitIntervalSec. Both options belong to the [unit] section.
The default delay between executions is 100ms (RestartSec) which causes the rate limit to be reached very fast.
SystemD won't attempt any more automatic restarts ever for units with Restart policy defined:
Note that units which are configured for
Restart=and which reach the
start limit are not attempted to be restarted anymore; however, they
may still be restarted manually at a later point, from which point on,
the restart logic is again activated.
Rahul's answer helps, because the longer delay prevents reaching the error counter within the StartLimitIntervalSec time. The correct answer is to set both RestartSec and StartLimitBurst to reasonable values though.
I would like to extend Rahul's answer a bit.
SystemD tries to restart multiple times (StartLimitBurst) and stops trying if the attempt count is reached within StartLimitIntervalSec. Both options belong to the [unit] section.
The default delay between executions is 100ms (RestartSec) which causes the rate limit to be reached very fast.
SystemD won't attempt any more automatic restarts ever for units with Restart policy defined:
Note that units which are configured for
Restart=and which reach the
start limit are not attempted to be restarted anymore; however, they
may still be restarted manually at a later point, from which point on,
the restart logic is again activated.
Rahul's answer helps, because the longer delay prevents reaching the error counter within the StartLimitIntervalSec time. The correct answer is to set both RestartSec and StartLimitBurst to reasonable values though.
edited Apr 19 at 13:18
nik_m
1034
1034
answered Nov 18 '16 at 14:15
MarSik
48632
48632
4
Now that I (finally) understand how it works, after some trial-and-error, I can see that your answer is the most correct. Bottom line for me: setStartLimitIntervalSec=0and voilà .
â Benjamin
Aug 26 '17 at 15:42
add a comment |Â
4
Now that I (finally) understand how it works, after some trial-and-error, I can see that your answer is the most correct. Bottom line for me: setStartLimitIntervalSec=0and voilà .
â Benjamin
Aug 26 '17 at 15:42
4
4
Now that I (finally) understand how it works, after some trial-and-error, I can see that your answer is the most correct. Bottom line for me: set
StartLimitIntervalSec=0 and voilà .â Benjamin
Aug 26 '17 at 15:42
Now that I (finally) understand how it works, after some trial-and-error, I can see that your answer is the most correct. Bottom line for me: set
StartLimitIntervalSec=0 and voilà .â Benjamin
Aug 26 '17 at 15:42
add a comment |Â
up vote
20
down vote
Yes, there is. You can specify to retry after x seconds under [Service] section,
[Service]
Type=simple
Restart=always
RestartSec=3
ExecStart=/path/to/script
After saving the file you need to reload the daemon configurations to ensure systemd is aware of the new file,
systemctl daemon-reload
then restart the service to enable changes,
systemctl restart test
As you have requested, Looking at the documentation,
Restart=on-failure
sounds like a decent recommendation.
It seems to work indeed, thank you! So to understand this better, without aRestartSecdirective,systemdattempts severals restarts very quickly, then enters a permanent failure state; something that cannot happen whenRestartSecis specified?
â Benjamin
Jun 14 '16 at 9:48
Also, I've noticed that it delays the "normal" restart of my worker (I'm purposefully exiting the worker gracefully after a few minutes); is there a way to only delay a failed restart?
â Benjamin
Jun 14 '16 at 9:50
@Benjamin see my updates
â Rahul
Jun 14 '16 at 9:53
@Benjamin you can check here for more parameters.
â Rahul
Jun 14 '16 at 9:57
2
Judging by the doc,alwaysis a superset ofon-failure, so it won't help!
â Benjamin
Jun 14 '16 at 10:10
 |Â
show 2 more comments
up vote
20
down vote
Yes, there is. You can specify to retry after x seconds under [Service] section,
[Service]
Type=simple
Restart=always
RestartSec=3
ExecStart=/path/to/script
After saving the file you need to reload the daemon configurations to ensure systemd is aware of the new file,
systemctl daemon-reload
then restart the service to enable changes,
systemctl restart test
As you have requested, Looking at the documentation,
Restart=on-failure
sounds like a decent recommendation.
It seems to work indeed, thank you! So to understand this better, without aRestartSecdirective,systemdattempts severals restarts very quickly, then enters a permanent failure state; something that cannot happen whenRestartSecis specified?
â Benjamin
Jun 14 '16 at 9:48
Also, I've noticed that it delays the "normal" restart of my worker (I'm purposefully exiting the worker gracefully after a few minutes); is there a way to only delay a failed restart?
â Benjamin
Jun 14 '16 at 9:50
@Benjamin see my updates
â Rahul
Jun 14 '16 at 9:53
@Benjamin you can check here for more parameters.
â Rahul
Jun 14 '16 at 9:57
2
Judging by the doc,alwaysis a superset ofon-failure, so it won't help!
â Benjamin
Jun 14 '16 at 10:10
 |Â
show 2 more comments
up vote
20
down vote
up vote
20
down vote
Yes, there is. You can specify to retry after x seconds under [Service] section,
[Service]
Type=simple
Restart=always
RestartSec=3
ExecStart=/path/to/script
After saving the file you need to reload the daemon configurations to ensure systemd is aware of the new file,
systemctl daemon-reload
then restart the service to enable changes,
systemctl restart test
As you have requested, Looking at the documentation,
Restart=on-failure
sounds like a decent recommendation.
Yes, there is. You can specify to retry after x seconds under [Service] section,
[Service]
Type=simple
Restart=always
RestartSec=3
ExecStart=/path/to/script
After saving the file you need to reload the daemon configurations to ensure systemd is aware of the new file,
systemctl daemon-reload
then restart the service to enable changes,
systemctl restart test
As you have requested, Looking at the documentation,
Restart=on-failure
sounds like a decent recommendation.
edited Jun 14 '16 at 9:52
answered Jun 14 '16 at 9:40
Rahul
8,56612841
8,56612841
It seems to work indeed, thank you! So to understand this better, without aRestartSecdirective,systemdattempts severals restarts very quickly, then enters a permanent failure state; something that cannot happen whenRestartSecis specified?
â Benjamin
Jun 14 '16 at 9:48
Also, I've noticed that it delays the "normal" restart of my worker (I'm purposefully exiting the worker gracefully after a few minutes); is there a way to only delay a failed restart?
â Benjamin
Jun 14 '16 at 9:50
@Benjamin see my updates
â Rahul
Jun 14 '16 at 9:53
@Benjamin you can check here for more parameters.
â Rahul
Jun 14 '16 at 9:57
2
Judging by the doc,alwaysis a superset ofon-failure, so it won't help!
â Benjamin
Jun 14 '16 at 10:10
 |Â
show 2 more comments
It seems to work indeed, thank you! So to understand this better, without aRestartSecdirective,systemdattempts severals restarts very quickly, then enters a permanent failure state; something that cannot happen whenRestartSecis specified?
â Benjamin
Jun 14 '16 at 9:48
Also, I've noticed that it delays the "normal" restart of my worker (I'm purposefully exiting the worker gracefully after a few minutes); is there a way to only delay a failed restart?
â Benjamin
Jun 14 '16 at 9:50
@Benjamin see my updates
â Rahul
Jun 14 '16 at 9:53
@Benjamin you can check here for more parameters.
â Rahul
Jun 14 '16 at 9:57
2
Judging by the doc,alwaysis a superset ofon-failure, so it won't help!
â Benjamin
Jun 14 '16 at 10:10
It seems to work indeed, thank you! So to understand this better, without a
RestartSec directive, systemd attempts severals restarts very quickly, then enters a permanent failure state; something that cannot happen when RestartSec is specified?â Benjamin
Jun 14 '16 at 9:48
It seems to work indeed, thank you! So to understand this better, without a
RestartSec directive, systemd attempts severals restarts very quickly, then enters a permanent failure state; something that cannot happen when RestartSec is specified?â Benjamin
Jun 14 '16 at 9:48
Also, I've noticed that it delays the "normal" restart of my worker (I'm purposefully exiting the worker gracefully after a few minutes); is there a way to only delay a failed restart?
â Benjamin
Jun 14 '16 at 9:50
Also, I've noticed that it delays the "normal" restart of my worker (I'm purposefully exiting the worker gracefully after a few minutes); is there a way to only delay a failed restart?
â Benjamin
Jun 14 '16 at 9:50
@Benjamin see my updates
â Rahul
Jun 14 '16 at 9:53
@Benjamin see my updates
â Rahul
Jun 14 '16 at 9:53
@Benjamin you can check here for more parameters.
â Rahul
Jun 14 '16 at 9:57
@Benjamin you can check here for more parameters.
â Rahul
Jun 14 '16 at 9:57
2
2
Judging by the doc,
always is a superset of on-failure, so it won't help!â Benjamin
Jun 14 '16 at 10:10
Judging by the doc,
always is a superset of on-failure, so it won't help!â Benjamin
Jun 14 '16 at 10:10
 |Â
show 2 more comments
up vote
4
down vote
systemd gives up trying to restart it
No. systemd gives up trying to restart it for a little while. This is clearly shown in the log that you supply:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
This is rate limiting kicking in.
The length of the little while is specified in the service unit, using the StartLimitIntervalSec= setting. The number of starts that are needed within that interval to trigger the rate limiting mechanism are specified via the StartLimitBurst= setting. If nothing on your system differs from vanilla systemd, including the defaults for these two settings, then it is 5 times within 10 seconds.
StartLimitIntervalSec=0 disables rate limiting. But making your service either not exit so often, or idle enough between exits and restarts that it does not exceed the rate limiting threshold, is a better approach.
Note that rate limiting does not care how your service exited. It triggers on the number of attempts to start/restart it, irrespective of their cause.
Further reading
- Lennart Poettering (2013-10-07).
systemd.unit. systemd manual pages. freedesktop.org. - Systemd's StartLimitIntervalSec and StartLimitBurst never work
4
It does seem to give up permanently, though: "Active: failed (Result: start-limit) since Wed 2016-06-15 01:21:24 CEST; 12h ago". It stays in this state and the script is never executed again. I tried setting manuallyStartLimitIntervalSec=10andStartLimitIntervalSec=5, no luck.
â Benjamin
Jun 15 '16 at 11:55
4
It does give up permanently by default. See github.com/systemd/systemd/issues/2416.
â Adam Goode
Apr 22 '17 at 17:10
1
Bottom line: to stop prevent it from giving up permanently, setStartLimitIntervalSec=0.
â Benjamin
Aug 26 '17 at 15:43
add a comment |Â
up vote
4
down vote
systemd gives up trying to restart it
No. systemd gives up trying to restart it for a little while. This is clearly shown in the log that you supply:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
This is rate limiting kicking in.
The length of the little while is specified in the service unit, using the StartLimitIntervalSec= setting. The number of starts that are needed within that interval to trigger the rate limiting mechanism are specified via the StartLimitBurst= setting. If nothing on your system differs from vanilla systemd, including the defaults for these two settings, then it is 5 times within 10 seconds.
StartLimitIntervalSec=0 disables rate limiting. But making your service either not exit so often, or idle enough between exits and restarts that it does not exceed the rate limiting threshold, is a better approach.
Note that rate limiting does not care how your service exited. It triggers on the number of attempts to start/restart it, irrespective of their cause.
Further reading
- Lennart Poettering (2013-10-07).
systemd.unit. systemd manual pages. freedesktop.org. - Systemd's StartLimitIntervalSec and StartLimitBurst never work
4
It does seem to give up permanently, though: "Active: failed (Result: start-limit) since Wed 2016-06-15 01:21:24 CEST; 12h ago". It stays in this state and the script is never executed again. I tried setting manuallyStartLimitIntervalSec=10andStartLimitIntervalSec=5, no luck.
â Benjamin
Jun 15 '16 at 11:55
4
It does give up permanently by default. See github.com/systemd/systemd/issues/2416.
â Adam Goode
Apr 22 '17 at 17:10
1
Bottom line: to stop prevent it from giving up permanently, setStartLimitIntervalSec=0.
â Benjamin
Aug 26 '17 at 15:43
add a comment |Â
up vote
4
down vote
up vote
4
down vote
systemd gives up trying to restart it
No. systemd gives up trying to restart it for a little while. This is clearly shown in the log that you supply:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
This is rate limiting kicking in.
The length of the little while is specified in the service unit, using the StartLimitIntervalSec= setting. The number of starts that are needed within that interval to trigger the rate limiting mechanism are specified via the StartLimitBurst= setting. If nothing on your system differs from vanilla systemd, including the defaults for these two settings, then it is 5 times within 10 seconds.
StartLimitIntervalSec=0 disables rate limiting. But making your service either not exit so often, or idle enough between exits and restarts that it does not exceed the rate limiting threshold, is a better approach.
Note that rate limiting does not care how your service exited. It triggers on the number of attempts to start/restart it, irrespective of their cause.
Further reading
- Lennart Poettering (2013-10-07).
systemd.unit. systemd manual pages. freedesktop.org. - Systemd's StartLimitIntervalSec and StartLimitBurst never work
systemd gives up trying to restart it
No. systemd gives up trying to restart it for a little while. This is clearly shown in the log that you supply:
Jun 14 11:25:51 localhost systemd[1]: test.service: Failed with result 'start-limit'.
This is rate limiting kicking in.
The length of the little while is specified in the service unit, using the StartLimitIntervalSec= setting. The number of starts that are needed within that interval to trigger the rate limiting mechanism are specified via the StartLimitBurst= setting. If nothing on your system differs from vanilla systemd, including the defaults for these two settings, then it is 5 times within 10 seconds.
StartLimitIntervalSec=0 disables rate limiting. But making your service either not exit so often, or idle enough between exits and restarts that it does not exceed the rate limiting threshold, is a better approach.
Note that rate limiting does not care how your service exited. It triggers on the number of attempts to start/restart it, irrespective of their cause.
Further reading
- Lennart Poettering (2013-10-07).
systemd.unit. systemd manual pages. freedesktop.org. - Systemd's StartLimitIntervalSec and StartLimitBurst never work
edited Aug 23 at 9:44
answered Jun 14 '16 at 20:48
JdeBP
29.5k460136
29.5k460136
4
It does seem to give up permanently, though: "Active: failed (Result: start-limit) since Wed 2016-06-15 01:21:24 CEST; 12h ago". It stays in this state and the script is never executed again. I tried setting manuallyStartLimitIntervalSec=10andStartLimitIntervalSec=5, no luck.
â Benjamin
Jun 15 '16 at 11:55
4
It does give up permanently by default. See github.com/systemd/systemd/issues/2416.
â Adam Goode
Apr 22 '17 at 17:10
1
Bottom line: to stop prevent it from giving up permanently, setStartLimitIntervalSec=0.
â Benjamin
Aug 26 '17 at 15:43
add a comment |Â
4
It does seem to give up permanently, though: "Active: failed (Result: start-limit) since Wed 2016-06-15 01:21:24 CEST; 12h ago". It stays in this state and the script is never executed again. I tried setting manuallyStartLimitIntervalSec=10andStartLimitIntervalSec=5, no luck.
â Benjamin
Jun 15 '16 at 11:55
4
It does give up permanently by default. See github.com/systemd/systemd/issues/2416.
â Adam Goode
Apr 22 '17 at 17:10
1
Bottom line: to stop prevent it from giving up permanently, setStartLimitIntervalSec=0.
â Benjamin
Aug 26 '17 at 15:43
4
4
It does seem to give up permanently, though: "Active: failed (Result: start-limit) since Wed 2016-06-15 01:21:24 CEST; 12h ago". It stays in this state and the script is never executed again. I tried setting manually
StartLimitIntervalSec=10 and StartLimitIntervalSec=5, no luck.â Benjamin
Jun 15 '16 at 11:55
It does seem to give up permanently, though: "Active: failed (Result: start-limit) since Wed 2016-06-15 01:21:24 CEST; 12h ago". It stays in this state and the script is never executed again. I tried setting manually
StartLimitIntervalSec=10 and StartLimitIntervalSec=5, no luck.â Benjamin
Jun 15 '16 at 11:55
4
4
It does give up permanently by default. See github.com/systemd/systemd/issues/2416.
â Adam Goode
Apr 22 '17 at 17:10
It does give up permanently by default. See github.com/systemd/systemd/issues/2416.
â Adam Goode
Apr 22 '17 at 17:10
1
1
Bottom line: to stop prevent it from giving up permanently, set
StartLimitIntervalSec=0.â Benjamin
Aug 26 '17 at 15:43
Bottom line: to stop prevent it from giving up permanently, set
StartLimitIntervalSec=0.â Benjamin
Aug 26 '17 at 15:43
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%2f289629%2fsystemd-restart-always-is-not-honored%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