Systemd's StartLimitIntervalSec and StartLimitBurst never work

The name of the pictureThe name of the pictureThe name of the pictureClash 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









share|improve this question

















  • 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















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









share|improve this question

















  • 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













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









share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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













  • 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











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'





share|improve this answer






















  • 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

















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".






share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    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






























    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'





    share|improve this answer






















    • 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














    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'





    share|improve this answer






















    • 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












    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'





    share|improve this answer














    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'






    share|improve this answer














    share|improve this answer



    share|improve this answer








    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
















    • 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












    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".






    share|improve this answer
























      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".






      share|improve this answer






















        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".






        share|improve this answer












        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".







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 21 at 18:19









        batilei

        384




        384



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?