Cron Monthly job works randomly using `0 0 1 * *`












2















I have this sudo crontab -e job entry I setup in April then forgot about:



0   0   1   *   *     /bin/journalctl --vacuum-size=200M


What it does is keep down the size of journalctl files each month so they are only 200 MB in size (or thereabouts).



I followed these instructions:




  • https://serverfault.com/questions/87472/how-to-create-a-cron-job-that-runs-on-the-first-day-of-month


However I only received the following e-mail on January 1st, 2019 saying the job has finally run. I don't recall receiving an e-mail after setting the job up in April 2018. Why is this monthly job only running on New Year's Eve? :



cron monthly journalctl.png



(... SNIP ...)



cron monthly journalctl end.png



At the very end it says 1.2 GB of space was freed. However it means about 1 GB was wasted until the job ran on New Year's Eve.










share|improve this question




















  • 3





    Possible duplicate of Running command at certain time or after that as soon as possible

    – PerlDuck
    Jan 10 at 11:58
















2















I have this sudo crontab -e job entry I setup in April then forgot about:



0   0   1   *   *     /bin/journalctl --vacuum-size=200M


What it does is keep down the size of journalctl files each month so they are only 200 MB in size (or thereabouts).



I followed these instructions:




  • https://serverfault.com/questions/87472/how-to-create-a-cron-job-that-runs-on-the-first-day-of-month


However I only received the following e-mail on January 1st, 2019 saying the job has finally run. I don't recall receiving an e-mail after setting the job up in April 2018. Why is this monthly job only running on New Year's Eve? :



cron monthly journalctl.png



(... SNIP ...)



cron monthly journalctl end.png



At the very end it says 1.2 GB of space was freed. However it means about 1 GB was wasted until the job ran on New Year's Eve.










share|improve this question




















  • 3





    Possible duplicate of Running command at certain time or after that as soon as possible

    – PerlDuck
    Jan 10 at 11:58














2












2








2








I have this sudo crontab -e job entry I setup in April then forgot about:



0   0   1   *   *     /bin/journalctl --vacuum-size=200M


What it does is keep down the size of journalctl files each month so they are only 200 MB in size (or thereabouts).



I followed these instructions:




  • https://serverfault.com/questions/87472/how-to-create-a-cron-job-that-runs-on-the-first-day-of-month


However I only received the following e-mail on January 1st, 2019 saying the job has finally run. I don't recall receiving an e-mail after setting the job up in April 2018. Why is this monthly job only running on New Year's Eve? :



cron monthly journalctl.png



(... SNIP ...)



cron monthly journalctl end.png



At the very end it says 1.2 GB of space was freed. However it means about 1 GB was wasted until the job ran on New Year's Eve.










share|improve this question
















I have this sudo crontab -e job entry I setup in April then forgot about:



0   0   1   *   *     /bin/journalctl --vacuum-size=200M


What it does is keep down the size of journalctl files each month so they are only 200 MB in size (or thereabouts).



I followed these instructions:




  • https://serverfault.com/questions/87472/how-to-create-a-cron-job-that-runs-on-the-first-day-of-month


However I only received the following e-mail on January 1st, 2019 saying the job has finally run. I don't recall receiving an e-mail after setting the job up in April 2018. Why is this monthly job only running on New Year's Eve? :



cron monthly journalctl.png



(... SNIP ...)



cron monthly journalctl end.png



At the very end it says 1.2 GB of space was freed. However it means about 1 GB was wasted until the job ran on New Year's Eve.







cron






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 10 at 11:53







WinEunuuchs2Unix

















asked Jan 10 at 3:09









WinEunuuchs2UnixWinEunuuchs2Unix

45.3k1086176




45.3k1086176








  • 3





    Possible duplicate of Running command at certain time or after that as soon as possible

    – PerlDuck
    Jan 10 at 11:58














  • 3





    Possible duplicate of Running command at certain time or after that as soon as possible

    – PerlDuck
    Jan 10 at 11:58








3




3





Possible duplicate of Running command at certain time or after that as soon as possible

– PerlDuck
Jan 10 at 11:58





Possible duplicate of Running command at certain time or after that as soon as possible

– PerlDuck
Jan 10 at 11:58










1 Answer
1






active

oldest

votes


















2














The reason the job only ran on New Year's Eve is all the other first days of the month your machine was shut off at the stroke of midnight.



The easiest way is to not use sudo crontab -e but rather create a bash script in the directory /etc/cron.monthly. Make sure the script filename doesn't contain a . in it. Filenames containing a . such as Monthly job.cron or MonthlyUpdate.sh will not run.





In this case use:



sudo -H gedit /etc/cron.monthly/journal_vacuum


Insert these lines:



#!/bin/sh
#
# NAME: journal_vacuum
# DESC: Reduce size of system journals (journalctl) each month.
# DATE: January 9, 2019.

# NOTE: Replaces `0 0 1 * * /bin/journalctl --vacuum-size=200M` which
# which only runs if machine is turned on at midnight.

/bin/journalctl --vacuum-size=200M


Save the file and exit gedit. Make the script executable using:



sudo chmod a+x /etc/cron.monthly/journal_vacuum


Now the first time the machine is turned on each month, be it 1st day of month at 7:00am or even 2nd day of month the cron job will run.





Update 1



Once per month is unpredictable. The cron job was setup on January 9, 2019 and then ran on January 30, 2019:



monthly cron job.png



Hopefully the cron job runs again on Feb 1, 2019 as anticipated!





Update 2



The script in /etc/cron.monthly/ did not run on February 1, 2019. Digging deeper I found this explanation:




  • [SOLVED] cron.monthly not running - everything else is


Following the link's explanation I discovered:



$ sudo cat /var/spool/anacron/cron.monthly
20190130


Therefore with sudo powers I used:



rick@alien:~$ sudo -i
root@alien:~# echo 20190101 > /var/spool/anacron/cron.monthly
root@alien:~# exit


Now cron believes that last time monthly jobs were run is January 1, 2019.



Time to reboot and test...





Update 3



After reboot an email was almost instantly sent:



Anacron <XxxxxXxxxx999@gmail.com>    7:45 AM (3 minutes ago)
to root, bcc: XxxxxXxxxx999

/etc/cron.monthly/journal_vacuum:
Vacuuming done, freed 0B of archived journals on disk.


Now we can see:



$ sudo cat /var/spool/anacron/cron.monthly
20190203


The last step is to replace 20190203 with 20190201 using technique in Update 2.






share|improve this answer


























  • This answer relies on anacron, and anacron is not installed by default using the server installer.

    – pim
    Jan 10 at 13:03








  • 1





    If you want to avoid rebooting to trigger anacron you can also simply delete /var/spool/anacron/cron.monthly and then run sudo anacron -dsq or just sudo anacron. Or use sudo anacron -f to have it run now regardless of any timestamps. On systemd systems (like Ubuntu 18.04 desktop) anacron is run by systemd units. See systemctl cat anacron.service anacron.timer. The timer unit starts the service unit every hour which in turn runs /usr/sbin/anacron -dsq and that would be the "workaround command" if rebooting isn't convenient.

    – PerlDuck
    Feb 3 at 15:22













  • @PerlDuck Thank you. Your elaborate comment could be posted as a self-answered question :) PS you nominated to close this question last month so it's kind you would comment today.

    – WinEunuuchs2Unix
    Feb 3 at 15:24













  • You're welcome. But the question How to Manually run an Anacron Job has already been asked ;-)

    – PerlDuck
    Feb 3 at 15:31






  • 1





    @PerlDuck True but this question is specific about cron's 0 0 1 * * and how it works best for 24/7 server but not so well for home users who don't have machine turned on the first of the month at midnight. You will find 0 0 1 * * littered throughout the internet as an example of running first of month. I think the internet search will mislead many non-server users like it did myself for 8 month ends.

    – WinEunuuchs2Unix
    Feb 3 at 15:37











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1108456%2fcron-monthly-job-works-randomly-using-0-0-1%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














The reason the job only ran on New Year's Eve is all the other first days of the month your machine was shut off at the stroke of midnight.



The easiest way is to not use sudo crontab -e but rather create a bash script in the directory /etc/cron.monthly. Make sure the script filename doesn't contain a . in it. Filenames containing a . such as Monthly job.cron or MonthlyUpdate.sh will not run.





In this case use:



sudo -H gedit /etc/cron.monthly/journal_vacuum


Insert these lines:



#!/bin/sh
#
# NAME: journal_vacuum
# DESC: Reduce size of system journals (journalctl) each month.
# DATE: January 9, 2019.

# NOTE: Replaces `0 0 1 * * /bin/journalctl --vacuum-size=200M` which
# which only runs if machine is turned on at midnight.

/bin/journalctl --vacuum-size=200M


Save the file and exit gedit. Make the script executable using:



sudo chmod a+x /etc/cron.monthly/journal_vacuum


Now the first time the machine is turned on each month, be it 1st day of month at 7:00am or even 2nd day of month the cron job will run.





Update 1



Once per month is unpredictable. The cron job was setup on January 9, 2019 and then ran on January 30, 2019:



monthly cron job.png



Hopefully the cron job runs again on Feb 1, 2019 as anticipated!





Update 2



The script in /etc/cron.monthly/ did not run on February 1, 2019. Digging deeper I found this explanation:




  • [SOLVED] cron.monthly not running - everything else is


Following the link's explanation I discovered:



$ sudo cat /var/spool/anacron/cron.monthly
20190130


Therefore with sudo powers I used:



rick@alien:~$ sudo -i
root@alien:~# echo 20190101 > /var/spool/anacron/cron.monthly
root@alien:~# exit


Now cron believes that last time monthly jobs were run is January 1, 2019.



Time to reboot and test...





Update 3



After reboot an email was almost instantly sent:



Anacron <XxxxxXxxxx999@gmail.com>    7:45 AM (3 minutes ago)
to root, bcc: XxxxxXxxxx999

/etc/cron.monthly/journal_vacuum:
Vacuuming done, freed 0B of archived journals on disk.


Now we can see:



$ sudo cat /var/spool/anacron/cron.monthly
20190203


The last step is to replace 20190203 with 20190201 using technique in Update 2.






share|improve this answer


























  • This answer relies on anacron, and anacron is not installed by default using the server installer.

    – pim
    Jan 10 at 13:03








  • 1





    If you want to avoid rebooting to trigger anacron you can also simply delete /var/spool/anacron/cron.monthly and then run sudo anacron -dsq or just sudo anacron. Or use sudo anacron -f to have it run now regardless of any timestamps. On systemd systems (like Ubuntu 18.04 desktop) anacron is run by systemd units. See systemctl cat anacron.service anacron.timer. The timer unit starts the service unit every hour which in turn runs /usr/sbin/anacron -dsq and that would be the "workaround command" if rebooting isn't convenient.

    – PerlDuck
    Feb 3 at 15:22













  • @PerlDuck Thank you. Your elaborate comment could be posted as a self-answered question :) PS you nominated to close this question last month so it's kind you would comment today.

    – WinEunuuchs2Unix
    Feb 3 at 15:24













  • You're welcome. But the question How to Manually run an Anacron Job has already been asked ;-)

    – PerlDuck
    Feb 3 at 15:31






  • 1





    @PerlDuck True but this question is specific about cron's 0 0 1 * * and how it works best for 24/7 server but not so well for home users who don't have machine turned on the first of the month at midnight. You will find 0 0 1 * * littered throughout the internet as an example of running first of month. I think the internet search will mislead many non-server users like it did myself for 8 month ends.

    – WinEunuuchs2Unix
    Feb 3 at 15:37
















2














The reason the job only ran on New Year's Eve is all the other first days of the month your machine was shut off at the stroke of midnight.



The easiest way is to not use sudo crontab -e but rather create a bash script in the directory /etc/cron.monthly. Make sure the script filename doesn't contain a . in it. Filenames containing a . such as Monthly job.cron or MonthlyUpdate.sh will not run.





In this case use:



sudo -H gedit /etc/cron.monthly/journal_vacuum


Insert these lines:



#!/bin/sh
#
# NAME: journal_vacuum
# DESC: Reduce size of system journals (journalctl) each month.
# DATE: January 9, 2019.

# NOTE: Replaces `0 0 1 * * /bin/journalctl --vacuum-size=200M` which
# which only runs if machine is turned on at midnight.

/bin/journalctl --vacuum-size=200M


Save the file and exit gedit. Make the script executable using:



sudo chmod a+x /etc/cron.monthly/journal_vacuum


Now the first time the machine is turned on each month, be it 1st day of month at 7:00am or even 2nd day of month the cron job will run.





Update 1



Once per month is unpredictable. The cron job was setup on January 9, 2019 and then ran on January 30, 2019:



monthly cron job.png



Hopefully the cron job runs again on Feb 1, 2019 as anticipated!





Update 2



The script in /etc/cron.monthly/ did not run on February 1, 2019. Digging deeper I found this explanation:




  • [SOLVED] cron.monthly not running - everything else is


Following the link's explanation I discovered:



$ sudo cat /var/spool/anacron/cron.monthly
20190130


Therefore with sudo powers I used:



rick@alien:~$ sudo -i
root@alien:~# echo 20190101 > /var/spool/anacron/cron.monthly
root@alien:~# exit


Now cron believes that last time monthly jobs were run is January 1, 2019.



Time to reboot and test...





Update 3



After reboot an email was almost instantly sent:



Anacron <XxxxxXxxxx999@gmail.com>    7:45 AM (3 minutes ago)
to root, bcc: XxxxxXxxxx999

/etc/cron.monthly/journal_vacuum:
Vacuuming done, freed 0B of archived journals on disk.


Now we can see:



$ sudo cat /var/spool/anacron/cron.monthly
20190203


The last step is to replace 20190203 with 20190201 using technique in Update 2.






share|improve this answer


























  • This answer relies on anacron, and anacron is not installed by default using the server installer.

    – pim
    Jan 10 at 13:03








  • 1





    If you want to avoid rebooting to trigger anacron you can also simply delete /var/spool/anacron/cron.monthly and then run sudo anacron -dsq or just sudo anacron. Or use sudo anacron -f to have it run now regardless of any timestamps. On systemd systems (like Ubuntu 18.04 desktop) anacron is run by systemd units. See systemctl cat anacron.service anacron.timer. The timer unit starts the service unit every hour which in turn runs /usr/sbin/anacron -dsq and that would be the "workaround command" if rebooting isn't convenient.

    – PerlDuck
    Feb 3 at 15:22













  • @PerlDuck Thank you. Your elaborate comment could be posted as a self-answered question :) PS you nominated to close this question last month so it's kind you would comment today.

    – WinEunuuchs2Unix
    Feb 3 at 15:24













  • You're welcome. But the question How to Manually run an Anacron Job has already been asked ;-)

    – PerlDuck
    Feb 3 at 15:31






  • 1





    @PerlDuck True but this question is specific about cron's 0 0 1 * * and how it works best for 24/7 server but not so well for home users who don't have machine turned on the first of the month at midnight. You will find 0 0 1 * * littered throughout the internet as an example of running first of month. I think the internet search will mislead many non-server users like it did myself for 8 month ends.

    – WinEunuuchs2Unix
    Feb 3 at 15:37














2












2








2







The reason the job only ran on New Year's Eve is all the other first days of the month your machine was shut off at the stroke of midnight.



The easiest way is to not use sudo crontab -e but rather create a bash script in the directory /etc/cron.monthly. Make sure the script filename doesn't contain a . in it. Filenames containing a . such as Monthly job.cron or MonthlyUpdate.sh will not run.





In this case use:



sudo -H gedit /etc/cron.monthly/journal_vacuum


Insert these lines:



#!/bin/sh
#
# NAME: journal_vacuum
# DESC: Reduce size of system journals (journalctl) each month.
# DATE: January 9, 2019.

# NOTE: Replaces `0 0 1 * * /bin/journalctl --vacuum-size=200M` which
# which only runs if machine is turned on at midnight.

/bin/journalctl --vacuum-size=200M


Save the file and exit gedit. Make the script executable using:



sudo chmod a+x /etc/cron.monthly/journal_vacuum


Now the first time the machine is turned on each month, be it 1st day of month at 7:00am or even 2nd day of month the cron job will run.





Update 1



Once per month is unpredictable. The cron job was setup on January 9, 2019 and then ran on January 30, 2019:



monthly cron job.png



Hopefully the cron job runs again on Feb 1, 2019 as anticipated!





Update 2



The script in /etc/cron.monthly/ did not run on February 1, 2019. Digging deeper I found this explanation:




  • [SOLVED] cron.monthly not running - everything else is


Following the link's explanation I discovered:



$ sudo cat /var/spool/anacron/cron.monthly
20190130


Therefore with sudo powers I used:



rick@alien:~$ sudo -i
root@alien:~# echo 20190101 > /var/spool/anacron/cron.monthly
root@alien:~# exit


Now cron believes that last time monthly jobs were run is January 1, 2019.



Time to reboot and test...





Update 3



After reboot an email was almost instantly sent:



Anacron <XxxxxXxxxx999@gmail.com>    7:45 AM (3 minutes ago)
to root, bcc: XxxxxXxxxx999

/etc/cron.monthly/journal_vacuum:
Vacuuming done, freed 0B of archived journals on disk.


Now we can see:



$ sudo cat /var/spool/anacron/cron.monthly
20190203


The last step is to replace 20190203 with 20190201 using technique in Update 2.






share|improve this answer















The reason the job only ran on New Year's Eve is all the other first days of the month your machine was shut off at the stroke of midnight.



The easiest way is to not use sudo crontab -e but rather create a bash script in the directory /etc/cron.monthly. Make sure the script filename doesn't contain a . in it. Filenames containing a . such as Monthly job.cron or MonthlyUpdate.sh will not run.





In this case use:



sudo -H gedit /etc/cron.monthly/journal_vacuum


Insert these lines:



#!/bin/sh
#
# NAME: journal_vacuum
# DESC: Reduce size of system journals (journalctl) each month.
# DATE: January 9, 2019.

# NOTE: Replaces `0 0 1 * * /bin/journalctl --vacuum-size=200M` which
# which only runs if machine is turned on at midnight.

/bin/journalctl --vacuum-size=200M


Save the file and exit gedit. Make the script executable using:



sudo chmod a+x /etc/cron.monthly/journal_vacuum


Now the first time the machine is turned on each month, be it 1st day of month at 7:00am or even 2nd day of month the cron job will run.





Update 1



Once per month is unpredictable. The cron job was setup on January 9, 2019 and then ran on January 30, 2019:



monthly cron job.png



Hopefully the cron job runs again on Feb 1, 2019 as anticipated!





Update 2



The script in /etc/cron.monthly/ did not run on February 1, 2019. Digging deeper I found this explanation:




  • [SOLVED] cron.monthly not running - everything else is


Following the link's explanation I discovered:



$ sudo cat /var/spool/anacron/cron.monthly
20190130


Therefore with sudo powers I used:



rick@alien:~$ sudo -i
root@alien:~# echo 20190101 > /var/spool/anacron/cron.monthly
root@alien:~# exit


Now cron believes that last time monthly jobs were run is January 1, 2019.



Time to reboot and test...





Update 3



After reboot an email was almost instantly sent:



Anacron <XxxxxXxxxx999@gmail.com>    7:45 AM (3 minutes ago)
to root, bcc: XxxxxXxxxx999

/etc/cron.monthly/journal_vacuum:
Vacuuming done, freed 0B of archived journals on disk.


Now we can see:



$ sudo cat /var/spool/anacron/cron.monthly
20190203


The last step is to replace 20190203 with 20190201 using technique in Update 2.







share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 3 at 14:53

























answered Jan 10 at 3:09









WinEunuuchs2UnixWinEunuuchs2Unix

45.3k1086176




45.3k1086176













  • This answer relies on anacron, and anacron is not installed by default using the server installer.

    – pim
    Jan 10 at 13:03








  • 1





    If you want to avoid rebooting to trigger anacron you can also simply delete /var/spool/anacron/cron.monthly and then run sudo anacron -dsq or just sudo anacron. Or use sudo anacron -f to have it run now regardless of any timestamps. On systemd systems (like Ubuntu 18.04 desktop) anacron is run by systemd units. See systemctl cat anacron.service anacron.timer. The timer unit starts the service unit every hour which in turn runs /usr/sbin/anacron -dsq and that would be the "workaround command" if rebooting isn't convenient.

    – PerlDuck
    Feb 3 at 15:22













  • @PerlDuck Thank you. Your elaborate comment could be posted as a self-answered question :) PS you nominated to close this question last month so it's kind you would comment today.

    – WinEunuuchs2Unix
    Feb 3 at 15:24













  • You're welcome. But the question How to Manually run an Anacron Job has already been asked ;-)

    – PerlDuck
    Feb 3 at 15:31






  • 1





    @PerlDuck True but this question is specific about cron's 0 0 1 * * and how it works best for 24/7 server but not so well for home users who don't have machine turned on the first of the month at midnight. You will find 0 0 1 * * littered throughout the internet as an example of running first of month. I think the internet search will mislead many non-server users like it did myself for 8 month ends.

    – WinEunuuchs2Unix
    Feb 3 at 15:37



















  • This answer relies on anacron, and anacron is not installed by default using the server installer.

    – pim
    Jan 10 at 13:03








  • 1





    If you want to avoid rebooting to trigger anacron you can also simply delete /var/spool/anacron/cron.monthly and then run sudo anacron -dsq or just sudo anacron. Or use sudo anacron -f to have it run now regardless of any timestamps. On systemd systems (like Ubuntu 18.04 desktop) anacron is run by systemd units. See systemctl cat anacron.service anacron.timer. The timer unit starts the service unit every hour which in turn runs /usr/sbin/anacron -dsq and that would be the "workaround command" if rebooting isn't convenient.

    – PerlDuck
    Feb 3 at 15:22













  • @PerlDuck Thank you. Your elaborate comment could be posted as a self-answered question :) PS you nominated to close this question last month so it's kind you would comment today.

    – WinEunuuchs2Unix
    Feb 3 at 15:24













  • You're welcome. But the question How to Manually run an Anacron Job has already been asked ;-)

    – PerlDuck
    Feb 3 at 15:31






  • 1





    @PerlDuck True but this question is specific about cron's 0 0 1 * * and how it works best for 24/7 server but not so well for home users who don't have machine turned on the first of the month at midnight. You will find 0 0 1 * * littered throughout the internet as an example of running first of month. I think the internet search will mislead many non-server users like it did myself for 8 month ends.

    – WinEunuuchs2Unix
    Feb 3 at 15:37

















This answer relies on anacron, and anacron is not installed by default using the server installer.

– pim
Jan 10 at 13:03







This answer relies on anacron, and anacron is not installed by default using the server installer.

– pim
Jan 10 at 13:03






1




1





If you want to avoid rebooting to trigger anacron you can also simply delete /var/spool/anacron/cron.monthly and then run sudo anacron -dsq or just sudo anacron. Or use sudo anacron -f to have it run now regardless of any timestamps. On systemd systems (like Ubuntu 18.04 desktop) anacron is run by systemd units. See systemctl cat anacron.service anacron.timer. The timer unit starts the service unit every hour which in turn runs /usr/sbin/anacron -dsq and that would be the "workaround command" if rebooting isn't convenient.

– PerlDuck
Feb 3 at 15:22







If you want to avoid rebooting to trigger anacron you can also simply delete /var/spool/anacron/cron.monthly and then run sudo anacron -dsq or just sudo anacron. Or use sudo anacron -f to have it run now regardless of any timestamps. On systemd systems (like Ubuntu 18.04 desktop) anacron is run by systemd units. See systemctl cat anacron.service anacron.timer. The timer unit starts the service unit every hour which in turn runs /usr/sbin/anacron -dsq and that would be the "workaround command" if rebooting isn't convenient.

– PerlDuck
Feb 3 at 15:22















@PerlDuck Thank you. Your elaborate comment could be posted as a self-answered question :) PS you nominated to close this question last month so it's kind you would comment today.

– WinEunuuchs2Unix
Feb 3 at 15:24







@PerlDuck Thank you. Your elaborate comment could be posted as a self-answered question :) PS you nominated to close this question last month so it's kind you would comment today.

– WinEunuuchs2Unix
Feb 3 at 15:24















You're welcome. But the question How to Manually run an Anacron Job has already been asked ;-)

– PerlDuck
Feb 3 at 15:31





You're welcome. But the question How to Manually run an Anacron Job has already been asked ;-)

– PerlDuck
Feb 3 at 15:31




1




1





@PerlDuck True but this question is specific about cron's 0 0 1 * * and how it works best for 24/7 server but not so well for home users who don't have machine turned on the first of the month at midnight. You will find 0 0 1 * * littered throughout the internet as an example of running first of month. I think the internet search will mislead many non-server users like it did myself for 8 month ends.

– WinEunuuchs2Unix
Feb 3 at 15:37





@PerlDuck True but this question is specific about cron's 0 0 1 * * and how it works best for 24/7 server but not so well for home users who don't have machine turned on the first of the month at midnight. You will find 0 0 1 * * littered throughout the internet as an example of running first of month. I think the internet search will mislead many non-server users like it did myself for 8 month ends.

– WinEunuuchs2Unix
Feb 3 at 15:37


















draft saved

draft discarded




















































Thanks for contributing an answer to Ask Ubuntu!


  • 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%2faskubuntu.com%2fquestions%2f1108456%2fcron-monthly-job-works-randomly-using-0-0-1%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

Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

ComboBox Display Member on multiple fields

Is it possible to collect Nectar points via Trainline?