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?

            Christian Cage

            How to properly install USB display driver for Fresco Logic FL2000DX on Ubuntu?