Dev Stack Source

Answer : Your command is fine! To run from 7.00 until 19.45, every 15 minutes just use */15 as follows: */15 07-19 * * * /path/script ^^^^ ^^^^^ That is, the content */15 in the minutes column will do something every 15 minutes, while the second column, for hours, will do that thing on the specified range of hours. If you want it to run until 19.00 then you have to write two lines: */15 07-18 * * * /path/script 0 19 * * * /path/script You can have a full description of the command in crontab.guru: https://crontab.guru/# /15_7-19_ _ _ Yes, that's correct. The entry in crontab would should be: */15 7-19 * * * /path/script >/dev/null 2>&1

Answer : The Croniter package seems like it may get what you need. Example from the docs: >>> from croniter import croniter >>> from datetime import datetime >>> base = datetime(2010, 1, 25, 4, 46) >>> iter = croniter('*/5 * * * *', base) # every 5 minites >>> print iter.get_next(datetime) # 2010-01-25 04:50:00 >>> print iter.get_next(datetime) # 2010-01-25 04:55:00 >>> print iter.get_next(datetime) # 2010-01-25 05:00:00 >>> >>> iter = croniter('2 4 * * mon,fri', base) # 04:02 on every Monday and Friday >>> print iter.get_next(datetime) # 2010-01-26 04:02:00 >>> print iter.get_next(datetime) # 2010-01-30 04:02:00 >>> print iter.get_next(datetime) # 2010-02-02 04:02:00 Per the code, it also appears to do validation on the entered format. Likely that you came across this already, but just in case :) Since the accepted answer is quite old, the same l...

Answer : 0 and 7 both stand for Sunday, you can use the one you want, so writing 0-6 or 1-7 has the same result. Also, as suggested by @Henrik, it is possible to replace numbers by shortened name of days, such as MON , THU , etc: 0 - Sun Sunday 1 - Mon Monday 2 - Tue Tuesday 3 - Wed Wednesday 4 - Thu Thursday 5 - Fri Friday 6 - Sat Saturday 7 - Sun Sunday Graphically: ┌────────── minute (0 - 59) │ ┌──────── hour (0 - 23) │ │ ┌────── day of month (1 - 31) │ │ │ ┌──── month (1 - 12) │ │ │ │ ┌── day of week (0 - 6 => Sunday - Saturday, or │ │ │ │ │ 1 - 7 => Monday - Sunday) ↓ ↓ ↓ ↓ ↓ * * * * * command to be executed Finally, if you want to specify day by day, you can separate days with commas, for example SUN,MON,THU will exectute the command only on sundays, mondays on thursdays. You can read further details in Wikipedia's article about Cron. :-) Sunday | 0 -> Sun | Mo...

Answer : A Java library that converts cron expressions into human readable strings: https://github.com/RedHogs/cron-parser Well yes I did understand your question. But I should have explained my answer a little better. No I don’t know any tool that will help you get a cron expression in “human” readable form. But by getting access to the CronExpression you can create you own. Try calling cronTrigger.getExpressionSummary() on the cron expression: "0/2 * * 4 * ?" it returns the following String: seconds: 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58 minutes: * hours: * daysOfMonth: 4 months: * daysOfWeek: ? lastdayOfWeek: false nearestWeekday: false NthDayOfWeek: 0 lastdayOfMonth: false calendardayOfWeek: false calendardayOfMonth: false years: * By having access to the CronExpression object, you can create your own "human" explenation. cron-utils may be useful for this task, since provides human readable descriptions and does ...

Answer : Solution 1: Monthly is not frequent enough. This script should run at least weekly, and preferably daily. Remember that certs don't get renewed unless they are near to expiration, and monthly could cause your existing certs to occasionally be expired already before they get renewed. The name of the program is certbot , which was renamed from letsencrypt . If you are still using letsencrypt , you need to update to the current version. Aside from those issues, it's about the same as my cron jobs. 43 6 * * * certbot renew --post-hook "systemctl reload nginx" Note: in 18.04 LTS the letsencrypt package has been (finally) renamed to certbot . It now includes a systemd timer which you can enable to schedule certbot renewals, with systemctl enable certbot.timer and systemctl start certbot.timer . However, Ubuntu did not provide a way to specify hooks. You'll need to set up an override for certbot.service to override ExecStart= with your desired command l...

Answer : This can be a bit of a confusing topic because there are different implementations of cron. Also there were several bugs that broke this feature, and there are also some use cases where it simply won't work, specifically if you do a shutdown/boot vs. a reboot. Bugs datapoint #1 One such bug in Debian is covered here, titled: cron: @reboot jobs are not run. This seems to have made it's way into Ubuntu as well, which I can't confirm directly. datapoint #2 Evidence of the bug in Ubuntu would seem to be confirmed here in this SO Q&A titled: @reboot cronjob not executing. excerpt comment #1: .... 3) your version of crond may not support @reboot are you using vix's crond? ... show results of crontab -l -u user comment #2: ... It might be a good idea to set it up as an init script instead of relying on a specific version of cron's @reboot. comment #3: ... @MarkRoberts removed the reboot and modified the 1 * * * * , to */1 * * * * , problem is solv...

Answer : Linux uses mail for sending notifications to the user. Most Linux distributions have a mail service including an MTA (Mail Transfer Agent) installed. Ubuntu doesn't though. You can install a mail service, postfix for example, to solve this problem. sudo apt-get install postfix Or you can ignore it. I don't think the inability of cron to send messages has anything to do with the CPU spike (that's linked to the underlying job that cron is running). It might be safest to install an MTA and then read through the messages ( mutt is a good system mail reader). This happens because your cron jobs are producing output and then the cron daemon tries to email that output to you (i.e. root). If you don't need that output, the easiest way to solve this is to discard it at the crontab: sudo crontab -e and add >/dev/null 2>&1 to every job: * * * * * yourCommand >/dev/null 2>&1 In my case, the message was hinting at a permissions problem with the bash...