Systemd timer won't start in time

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












Trying to replace some cron jobs with systemd timers on an ArchLinux installation, I've created a simple timer/service as described here:



[Unit]
Description=Test timer

[Timer]
Persistent=false
OnCalendar=*-*-* *:05:05
Unit=test-timer.service

[Install]
WantedBy=timers.target


systemd-analyze calendar '*-*-* *:05:05' always correctly shows the next elapse, but the timer never starts at that time. Also, systemctl list-timers shows that the next start is in 3+ hours:



NEXT LEFT LAST PASSED UNIT ACTIVATES 
Fri 2018-08-24 02:05:05 +03 3h 9min left n/a n/a test.timer test-timer.service
...


systemctl daemon-reload seems to fix the issue. What may be the reason for it? I have systemd 238.










share|improve this question























  • Its fairly normal to require a daemon-reload after editing a unit file. Maybe this should be a RFE/minor bug report for making systemd-analyze calendar to identify unloaded unit file rather than presenting not yet activated data. I've never used timers so I might be a bit off with this response.
    – danblack
    Aug 23 at 23:22










  • It happens even after reboot, with no prior editing of unit files.
    – Eugene Yarmash
    Aug 24 at 5:31










  • I'd write it up as a bug report then: github.com/systemd/systemd/issues
    – danblack
    Aug 24 at 5:52










  • Just to make sure – did you enable and start the timer?
    – Lucas Werkmeister
    Aug 24 at 14:09














up vote
0
down vote

favorite












Trying to replace some cron jobs with systemd timers on an ArchLinux installation, I've created a simple timer/service as described here:



[Unit]
Description=Test timer

[Timer]
Persistent=false
OnCalendar=*-*-* *:05:05
Unit=test-timer.service

[Install]
WantedBy=timers.target


systemd-analyze calendar '*-*-* *:05:05' always correctly shows the next elapse, but the timer never starts at that time. Also, systemctl list-timers shows that the next start is in 3+ hours:



NEXT LEFT LAST PASSED UNIT ACTIVATES 
Fri 2018-08-24 02:05:05 +03 3h 9min left n/a n/a test.timer test-timer.service
...


systemctl daemon-reload seems to fix the issue. What may be the reason for it? I have systemd 238.










share|improve this question























  • Its fairly normal to require a daemon-reload after editing a unit file. Maybe this should be a RFE/minor bug report for making systemd-analyze calendar to identify unloaded unit file rather than presenting not yet activated data. I've never used timers so I might be a bit off with this response.
    – danblack
    Aug 23 at 23:22










  • It happens even after reboot, with no prior editing of unit files.
    – Eugene Yarmash
    Aug 24 at 5:31










  • I'd write it up as a bug report then: github.com/systemd/systemd/issues
    – danblack
    Aug 24 at 5:52










  • Just to make sure – did you enable and start the timer?
    – Lucas Werkmeister
    Aug 24 at 14:09












up vote
0
down vote

favorite









up vote
0
down vote

favorite











Trying to replace some cron jobs with systemd timers on an ArchLinux installation, I've created a simple timer/service as described here:



[Unit]
Description=Test timer

[Timer]
Persistent=false
OnCalendar=*-*-* *:05:05
Unit=test-timer.service

[Install]
WantedBy=timers.target


systemd-analyze calendar '*-*-* *:05:05' always correctly shows the next elapse, but the timer never starts at that time. Also, systemctl list-timers shows that the next start is in 3+ hours:



NEXT LEFT LAST PASSED UNIT ACTIVATES 
Fri 2018-08-24 02:05:05 +03 3h 9min left n/a n/a test.timer test-timer.service
...


systemctl daemon-reload seems to fix the issue. What may be the reason for it? I have systemd 238.










share|improve this question















Trying to replace some cron jobs with systemd timers on an ArchLinux installation, I've created a simple timer/service as described here:



[Unit]
Description=Test timer

[Timer]
Persistent=false
OnCalendar=*-*-* *:05:05
Unit=test-timer.service

[Install]
WantedBy=timers.target


systemd-analyze calendar '*-*-* *:05:05' always correctly shows the next elapse, but the timer never starts at that time. Also, systemctl list-timers shows that the next start is in 3+ hours:



NEXT LEFT LAST PASSED UNIT ACTIVATES 
Fri 2018-08-24 02:05:05 +03 3h 9min left n/a n/a test.timer test-timer.service
...


systemctl daemon-reload seems to fix the issue. What may be the reason for it? I have systemd 238.







systemd systemd-timer






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 23 at 22:21









jasonwryan

47.3k14128178




47.3k14128178










asked Aug 23 at 20:13









Eugene Yarmash

4,47182844




4,47182844











  • Its fairly normal to require a daemon-reload after editing a unit file. Maybe this should be a RFE/minor bug report for making systemd-analyze calendar to identify unloaded unit file rather than presenting not yet activated data. I've never used timers so I might be a bit off with this response.
    – danblack
    Aug 23 at 23:22










  • It happens even after reboot, with no prior editing of unit files.
    – Eugene Yarmash
    Aug 24 at 5:31










  • I'd write it up as a bug report then: github.com/systemd/systemd/issues
    – danblack
    Aug 24 at 5:52










  • Just to make sure – did you enable and start the timer?
    – Lucas Werkmeister
    Aug 24 at 14:09
















  • Its fairly normal to require a daemon-reload after editing a unit file. Maybe this should be a RFE/minor bug report for making systemd-analyze calendar to identify unloaded unit file rather than presenting not yet activated data. I've never used timers so I might be a bit off with this response.
    – danblack
    Aug 23 at 23:22










  • It happens even after reboot, with no prior editing of unit files.
    – Eugene Yarmash
    Aug 24 at 5:31










  • I'd write it up as a bug report then: github.com/systemd/systemd/issues
    – danblack
    Aug 24 at 5:52










  • Just to make sure – did you enable and start the timer?
    – Lucas Werkmeister
    Aug 24 at 14:09















Its fairly normal to require a daemon-reload after editing a unit file. Maybe this should be a RFE/minor bug report for making systemd-analyze calendar to identify unloaded unit file rather than presenting not yet activated data. I've never used timers so I might be a bit off with this response.
– danblack
Aug 23 at 23:22




Its fairly normal to require a daemon-reload after editing a unit file. Maybe this should be a RFE/minor bug report for making systemd-analyze calendar to identify unloaded unit file rather than presenting not yet activated data. I've never used timers so I might be a bit off with this response.
– danblack
Aug 23 at 23:22












It happens even after reboot, with no prior editing of unit files.
– Eugene Yarmash
Aug 24 at 5:31




It happens even after reboot, with no prior editing of unit files.
– Eugene Yarmash
Aug 24 at 5:31












I'd write it up as a bug report then: github.com/systemd/systemd/issues
– danblack
Aug 24 at 5:52




I'd write it up as a bug report then: github.com/systemd/systemd/issues
– danblack
Aug 24 at 5:52












Just to make sure – did you enable and start the timer?
– Lucas Werkmeister
Aug 24 at 14:09




Just to make sure – did you enable and start the timer?
– Lucas Werkmeister
Aug 24 at 14:09










1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










It looks like clock synchronization somehow got messed up on my system. Switching from ntpd to systemd-timesyncd solved the problem:



sudo systemctl disable ntpd.service
sudo timedatectl set-ntp true
sudo reboot





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%2f464497%2fsystemd-timer-wont-start-in-time%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote



    accepted










    It looks like clock synchronization somehow got messed up on my system. Switching from ntpd to systemd-timesyncd solved the problem:



    sudo systemctl disable ntpd.service
    sudo timedatectl set-ntp true
    sudo reboot





    share|improve this answer
























      up vote
      0
      down vote



      accepted










      It looks like clock synchronization somehow got messed up on my system. Switching from ntpd to systemd-timesyncd solved the problem:



      sudo systemctl disable ntpd.service
      sudo timedatectl set-ntp true
      sudo reboot





      share|improve this answer






















        up vote
        0
        down vote



        accepted







        up vote
        0
        down vote



        accepted






        It looks like clock synchronization somehow got messed up on my system. Switching from ntpd to systemd-timesyncd solved the problem:



        sudo systemctl disable ntpd.service
        sudo timedatectl set-ntp true
        sudo reboot





        share|improve this answer












        It looks like clock synchronization somehow got messed up on my system. Switching from ntpd to systemd-timesyncd solved the problem:



        sudo systemctl disable ntpd.service
        sudo timedatectl set-ntp true
        sudo reboot






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 24 at 19:31









        Eugene Yarmash

        4,47182844




        4,47182844



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f464497%2fsystemd-timer-wont-start-in-time%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?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay