Crontab tasks aren't running











up vote
1
down vote

favorite












I tried created a very simple cron task that echo's "Hello World" into a file named /tmp/example.txt.



You can see from the screenshot, I tried:



28 23 * * * echo "Hello World" >> /tmp/example.txt

28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt


Also in the screenshot, you can see the date. I have also tried getting the exact date in the cron task (e.g.: 28 23 29 11 4), but that didn't work either.



I also tried using an actual file



28 23 * * * ./pingstuff


The pingstuff file just pings Google. I can run this file and it executes properly. But, when I try using it in the crontab -e, nothing happens at the scheduled time. (Times have been changed accordingly after each attempt.)



I am logged in as a super user. I have permissions to read/write/execute all of these files. I'm not really sure what I'm doing wrong.



enter image description here










share|improve this question









New contributor




Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1




    What Linux distribution are you using? Is your cron daemon enabled and started?
    – n.st
    1 hour ago










  • Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.
    – n.st
    1 hour ago















up vote
1
down vote

favorite












I tried created a very simple cron task that echo's "Hello World" into a file named /tmp/example.txt.



You can see from the screenshot, I tried:



28 23 * * * echo "Hello World" >> /tmp/example.txt

28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt


Also in the screenshot, you can see the date. I have also tried getting the exact date in the cron task (e.g.: 28 23 29 11 4), but that didn't work either.



I also tried using an actual file



28 23 * * * ./pingstuff


The pingstuff file just pings Google. I can run this file and it executes properly. But, when I try using it in the crontab -e, nothing happens at the scheduled time. (Times have been changed accordingly after each attempt.)



I am logged in as a super user. I have permissions to read/write/execute all of these files. I'm not really sure what I'm doing wrong.



enter image description here










share|improve this question









New contributor




Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1




    What Linux distribution are you using? Is your cron daemon enabled and started?
    – n.st
    1 hour ago










  • Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.
    – n.st
    1 hour ago













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I tried created a very simple cron task that echo's "Hello World" into a file named /tmp/example.txt.



You can see from the screenshot, I tried:



28 23 * * * echo "Hello World" >> /tmp/example.txt

28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt


Also in the screenshot, you can see the date. I have also tried getting the exact date in the cron task (e.g.: 28 23 29 11 4), but that didn't work either.



I also tried using an actual file



28 23 * * * ./pingstuff


The pingstuff file just pings Google. I can run this file and it executes properly. But, when I try using it in the crontab -e, nothing happens at the scheduled time. (Times have been changed accordingly after each attempt.)



I am logged in as a super user. I have permissions to read/write/execute all of these files. I'm not really sure what I'm doing wrong.



enter image description here










share|improve this question









New contributor




Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I tried created a very simple cron task that echo's "Hello World" into a file named /tmp/example.txt.



You can see from the screenshot, I tried:



28 23 * * * echo "Hello World" >> /tmp/example.txt

28 23 * * * root /bin/bash echo "Hello World" >> /tmp/example.txt


Also in the screenshot, you can see the date. I have also tried getting the exact date in the cron task (e.g.: 28 23 29 11 4), but that didn't work either.



I also tried using an actual file



28 23 * * * ./pingstuff


The pingstuff file just pings Google. I can run this file and it executes properly. But, when I try using it in the crontab -e, nothing happens at the scheduled time. (Times have been changed accordingly after each attempt.)



I am logged in as a super user. I have permissions to read/write/execute all of these files. I'm not really sure what I'm doing wrong.



enter image description here







linux bash cron






share|improve this question









New contributor




Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 1 hour ago









Rui F Ribeiro

38.3k1475127




38.3k1475127






New contributor




Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 1 hour ago









Pixii Bomb

61




61




New contributor




Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Pixii Bomb is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 1




    What Linux distribution are you using? Is your cron daemon enabled and started?
    – n.st
    1 hour ago










  • Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.
    – n.st
    1 hour ago














  • 1




    What Linux distribution are you using? Is your cron daemon enabled and started?
    – n.st
    1 hour ago










  • Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.
    – n.st
    1 hour ago








1




1




What Linux distribution are you using? Is your cron daemon enabled and started?
– n.st
1 hour ago




What Linux distribution are you using? Is your cron daemon enabled and started?
– n.st
1 hour ago












Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.
– n.st
1 hour ago




Also, when you're testing crontabs, set an execution time that's more than one minute in the future. Some (but not all) cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.
– n.st
1 hour ago










2 Answers
2






active

oldest

votes

















up vote
4
down vote













A cronjob may fail to execute because




  • the cron daemon is not running

  • there's a syntax error in the crontab

  • there's a syntax error in the command

  • or there's a permission problem (e.g. execute bit not set)


To check if the daemon is running, try service cron status or systemctl status cron (the service manager depends on your distribution). The daemon may also be called something slightly different, like crond or cronie.

If it's not running, start it (replace status with start).



If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog, /var/log/messages, a daemon-specific file like /var/log/cron, or a systemd binary log file (journalctl -u cron to view). You should see a line for each execution of the job.



When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.



If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh).

One common pitfall (though not the case here) are % characters in the command: they are treated specially by cron and need to be escaped (%) to be seen by the actual command invocation.

Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail command.






share|improve this answer























  • Several good points.
    – G-Man
    1 hour ago


















up vote
1
down vote













Your biggest problem is that /bin/bash echo "Hello World"
is not a valid command. 
It looks for a script called echo
Try /bin/bash -c 'echo "Hello World"' instead.



The second problem is that you should specify an absolute pathname
for pingstuff.



A third issue that caught my eye is that /tmp/example.txt
already exists (the cat command didn't get an error message). 
Are you sure that you have write permission to it? 
(Of course, that shouldn't be an issue if you're running as root.)



See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
although it probably isn't related.






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: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });






    Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485065%2fcrontab-tasks-arent-running%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    4
    down vote













    A cronjob may fail to execute because




    • the cron daemon is not running

    • there's a syntax error in the crontab

    • there's a syntax error in the command

    • or there's a permission problem (e.g. execute bit not set)


    To check if the daemon is running, try service cron status or systemctl status cron (the service manager depends on your distribution). The daemon may also be called something slightly different, like crond or cronie.

    If it's not running, start it (replace status with start).



    If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog, /var/log/messages, a daemon-specific file like /var/log/cron, or a systemd binary log file (journalctl -u cron to view). You should see a line for each execution of the job.



    When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.



    If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh).

    One common pitfall (though not the case here) are % characters in the command: they are treated specially by cron and need to be escaped (%) to be seen by the actual command invocation.

    Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail command.






    share|improve this answer























    • Several good points.
      – G-Man
      1 hour ago















    up vote
    4
    down vote













    A cronjob may fail to execute because




    • the cron daemon is not running

    • there's a syntax error in the crontab

    • there's a syntax error in the command

    • or there's a permission problem (e.g. execute bit not set)


    To check if the daemon is running, try service cron status or systemctl status cron (the service manager depends on your distribution). The daemon may also be called something slightly different, like crond or cronie.

    If it's not running, start it (replace status with start).



    If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog, /var/log/messages, a daemon-specific file like /var/log/cron, or a systemd binary log file (journalctl -u cron to view). You should see a line for each execution of the job.



    When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.



    If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh).

    One common pitfall (though not the case here) are % characters in the command: they are treated specially by cron and need to be escaped (%) to be seen by the actual command invocation.

    Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail command.






    share|improve this answer























    • Several good points.
      – G-Man
      1 hour ago













    up vote
    4
    down vote










    up vote
    4
    down vote









    A cronjob may fail to execute because




    • the cron daemon is not running

    • there's a syntax error in the crontab

    • there's a syntax error in the command

    • or there's a permission problem (e.g. execute bit not set)


    To check if the daemon is running, try service cron status or systemctl status cron (the service manager depends on your distribution). The daemon may also be called something slightly different, like crond or cronie.

    If it's not running, start it (replace status with start).



    If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog, /var/log/messages, a daemon-specific file like /var/log/cron, or a systemd binary log file (journalctl -u cron to view). You should see a line for each execution of the job.



    When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.



    If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh).

    One common pitfall (though not the case here) are % characters in the command: they are treated specially by cron and need to be escaped (%) to be seen by the actual command invocation.

    Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail command.






    share|improve this answer














    A cronjob may fail to execute because




    • the cron daemon is not running

    • there's a syntax error in the crontab

    • there's a syntax error in the command

    • or there's a permission problem (e.g. execute bit not set)


    To check if the daemon is running, try service cron status or systemctl status cron (the service manager depends on your distribution). The daemon may also be called something slightly different, like crond or cronie.

    If it's not running, start it (replace status with start).



    If it's running, proceed to check the relevant log files to see whether the job was actually run. Depending on your distribution, this might be logged to /var/log/syslog, /var/log/messages, a daemon-specific file like /var/log/cron, or a systemd binary log file (journalctl -u cron to view). You should see a line for each execution of the job.



    When testing crontabs, set an execution time that's more than one minute in the future. Some cron implementations "pre-plan" what tasks to run, i.e. they'll decide at 12:33:00 what to run at 12:34:00, so you'll miss the window of opportunity if you add a 34 12 … cronjob at 12:33:30.



    If the job runs but doesn't produce the expected result, try running the command from the crontab manually, as the same user, with the same shell (usually the minimalistic /bin/sh).

    One common pitfall (though not the case here) are % characters in the command: they are treated specially by cron and need to be escaped (%) to be seen by the actual command invocation.

    Most cron implementations also send the output (if any) of each cronjob as an email. If you haven't set up mail delivery over the internet, those mails should be stored locally and be readable using the mail command.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 1 hour ago

























    answered 1 hour ago









    n.st

    5,03311741




    5,03311741












    • Several good points.
      – G-Man
      1 hour ago


















    • Several good points.
      – G-Man
      1 hour ago
















    Several good points.
    – G-Man
    1 hour ago




    Several good points.
    – G-Man
    1 hour ago












    up vote
    1
    down vote













    Your biggest problem is that /bin/bash echo "Hello World"
    is not a valid command. 
    It looks for a script called echo
    Try /bin/bash -c 'echo "Hello World"' instead.



    The second problem is that you should specify an absolute pathname
    for pingstuff.



    A third issue that caught my eye is that /tmp/example.txt
    already exists (the cat command didn't get an error message). 
    Are you sure that you have write permission to it? 
    (Of course, that shouldn't be an issue if you're running as root.)



    See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
    although it probably isn't related.






    share|improve this answer



























      up vote
      1
      down vote













      Your biggest problem is that /bin/bash echo "Hello World"
      is not a valid command. 
      It looks for a script called echo
      Try /bin/bash -c 'echo "Hello World"' instead.



      The second problem is that you should specify an absolute pathname
      for pingstuff.



      A third issue that caught my eye is that /tmp/example.txt
      already exists (the cat command didn't get an error message). 
      Are you sure that you have write permission to it? 
      (Of course, that shouldn't be an issue if you're running as root.)



      See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
      although it probably isn't related.






      share|improve this answer

























        up vote
        1
        down vote










        up vote
        1
        down vote









        Your biggest problem is that /bin/bash echo "Hello World"
        is not a valid command. 
        It looks for a script called echo
        Try /bin/bash -c 'echo "Hello World"' instead.



        The second problem is that you should specify an absolute pathname
        for pingstuff.



        A third issue that caught my eye is that /tmp/example.txt
        already exists (the cat command didn't get an error message). 
        Are you sure that you have write permission to it? 
        (Of course, that shouldn't be an issue if you're running as root.)



        See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
        although it probably isn't related.






        share|improve this answer














        Your biggest problem is that /bin/bash echo "Hello World"
        is not a valid command. 
        It looks for a script called echo
        Try /bin/bash -c 'echo "Hello World"' instead.



        The second problem is that you should specify an absolute pathname
        for pingstuff.



        A third issue that caught my eye is that /tmp/example.txt
        already exists (the cat command didn't get an error message). 
        Are you sure that you have write permission to it? 
        (Of course, that shouldn't be an issue if you're running as root.)



        See also Ubuntu 14.04, 16.04, 18.04 Cron job doesn't execute,
        although it probably isn't related.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 1 hour ago

























        answered 1 hour ago









        G-Man

        12.3k92961




        12.3k92961






















            Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.













            Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.












            Pixii Bomb is a new contributor. Be nice, and check out our Code of Conduct.
















            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485065%2fcrontab-tasks-arent-running%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Bundesstraße 106

            Verónica Boquete

            Ida-Boy-Ed-Garten