/media/bill/PROJECTS/System_maintenance/Linux/cron notes.txt www.BillHowell.ca 26Nov2018 initial To view cron log for freshclam attempts : cat "/var/log/syslog" | grep "freshclam" What is my setup for cron? To see cron logs : $ cat "/var/log/syslog" | grep "clamd" DON'T use cron - use anacron !!! (for computers that are shut down frequently. triggers on days only, not hours?) scheduled shell scripts are [specified, edited] in the anacron sh : To update cron schedule : $ genie "/media/bill/PROJECTS/System_maintenance/Linux/cron & anacron daily Howell.txt" $ sudo cp "/media/bill/PROJECTS/System_maintenance/Linux/cron & anacron daily Howell.txt" "/etc/cron.daily/cron & anacron daily Howell" "anacrontab" - table : /etc/cron.d/anacron cron schedule : do I need this anymore, or is there [duplication, overlap]? : $ cat "/etc/crontab" (edit with sudo [genie, kwrite]) ********** https://www.wikihow.com/Set-up-a-Crontab-File-on-Linux m minute h hour d day of month m month 1-12 w weekday 0-7, Sun,Mon, etc (Sunday = 0 = 7) It is easy to remember if you think of the way one would say a date: Wednesday, July 29, at 10:30, then reverse the order. ******************************* ******************************* ******** 11Sep2020 d_PROJECTS updated backups daily @ [09:00, 17:00] see "$d_bin""cron PROJECTS.sh" # https://askubuntu.com/questions/848610/confused-about-relationship-between-cron-and-anacron # Both cron and anacron are daemons that can schedule execution of recurring tasks to a certain point in time defined by the user. # The main difference between cron and anacron is that the former assumes that the system is running continuously. If your system is off and you have a job scheduled during this time, the job never gets executed. # On the other hand anacron is 'anachronistic' and is designed for systems that are not running 24x7. For it to work anacron uses time-stamped files to find out when the last time its commands were executed. It also maintains a file /etc/anacrontab just like cron does. In addition, cron.daily runs anacron everyhour. Also, anacron can only run a job once a day, but cron can run as often as every minute. # >> I don't need anacron for this man cron /etc/crontab and the files in /etc/cron.d must be owned by root, and must not be group- or other-writable. In contrast to the spool area, the files under /etc/cron.d or the files under /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly may also be symlinks, provided that both the symlink and the file it points to are owned by root. The files under /etc/cron.d do not need to be executable, while the files under /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly do, as they are run by run-parts (see run-parts(8) for more information). +-----+ https://phoenixnap.com/kb/set-up-cron-job-linux Posted January 9, 2020 Basic Crontab Syntax Cron reads the configuration files for a list of commands to execute. The daemon uses a specific syntax to interpret the lines in the crontab configuration tables. To be able to set up a cron job, we need to understand the basic elements that make up this syntax. The standard form for a crontab line is as follows: a b c d e /directory/command output So, the parts of a cron command are: 1. The first five fields a b c d e specify the time/date and recurrence of the job. 2. In the second section, the /directory/command specifies the location and script you want to run. 3. The final segment output is optional. It defines how the system notifies the user of the job completion. Howell specs for "$d_bin""cron PROJECTS.sh" : 0 9,17 * * * "/media/bill/PROJECTS/cron PROJECTS.sh" >/dev/null 2>&1 To open the crontab configuration file for the current user, enter the following command in your terminal window: $ sudo crontab –e >> it saved it to : /tmp/crontab.kU3mn2/crontab ********* 21Jun2020 freshclam checks every hour for updates, and OCCASIONALLY updates virus stuff. Example : +---+ $ cat "/var/log/syslog" | grep "freshclam" ... Jun 21 12:04:36 dell64 freshclam[19138]: Sun Jun 21 12:04:36 2020 -> Received signal: wake up Jun 21 12:04:36 dell64 freshclam[19138]: Sun Jun 21 12:04:36 2020 -> ClamAV update process started at Sun Jun 21 12:04:36 2020 Jun 21 12:04:36 dell64 freshclam[19138]: Sun Jun 21 12:04:36 2020 -> daily database available for update (local version: 25849, remote version: 25850) Jun 21 12:04:38 dell64 freshclam[19138]: Sun Jun 21 12:04:38 2020 -> Testing database: '/var/lib/clamav/tmp.cd5ba/clamav-f06141511743e35296d493d4e8058512.tmp-daily.cld' ... Jun 21 12:04:44 dell64 freshclam[19138]: Sun Jun 21 12:04:44 2020 -> Database test passed. Jun 21 12:04:45 dell64 freshclam[19138]: Sun Jun 21 12:04:45 2020 -> daily.cld updated (version: 25850, sigs: 2731998, f-level: 63, builder: raynman) Jun 21 12:04:45 dell64 freshclam[19138]: Sun Jun 21 12:04:45 2020 -> main.cld database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr) Jun 21 12:04:45 dell64 freshclam[19138]: Sun Jun 21 12:04:45 2020 -> bytecode.cld database is up to date (version: 331, sigs: 94, f-level: 63, builder: anvilleg) Jun 21 12:04:45 dell64 freshclam[19138]: Sun Jun 21 12:04:45 2020 -> Clamd successfully notified about the update. ... +---+ $ cat "/var/log/syslog" | grep "clamd" Jun 21 11:03:16 dell64 clamd[20356]: Sun Jun 21 11:03:16 2020 -> SelfCheck: Database status OK. Jun 21 12:03:16 dell64 clamd[20356]: Sun Jun 21 12:03:16 2020 -> SelfCheck: Database status OK. Jun 21 12:04:46 dell64 clamd[20356]: Sun Jun 21 12:04:46 2020 -> Reading databases from /var/lib/clamav Jun 21 12:04:59 dell64 clamd[20356]: Sun Jun 21 12:04:59 2020 -> Database correctly reloaded (7303710 signatures) Jun 21 13:04:59 dell64 clamd[20356]: Sun Jun 21 13:04:59 2020 -> SelfCheck: Database status OK. Jun 21 14:04:59 dell64 clamd[20356]: Sun Jun 21 14:04:59 2020 -> SelfCheck: Database status OK. +---+ $ cat "/var/log/syslog" | grep "clamav" >> shows when connect fails +-----+ https://blog.softhints.com/linux-mint-how-to-check-cron-logs-crontab-e/ Step #1: Where is the CRON log in Linux Mint By default the logs in Ubuntu and Linux Mint from CRON execution can be found in: /var/log/syslog. In this log file there are many different log messages so best way to extract CRON related messages is by: grep CRON /var/log/syslog output: Mar 15 09:00:01 vanx-machine CRON[7205]: (root) CMD (timeshift --check --scripted) Mar 15 09:12:01 vanx-machine CRON[8128]: (vanx) CMD (/home/vanx/cron/seoanalyzer.sh) Mar 15 09:17:01 vanx-machine CRON[8638]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Mar 15 09:30:01 vanx-machine CRON[9508]: (vanx) CMD (DISPLAY=:0 /home/vanx/cron/weekly.sh) Mar 15 09:32:29 vanx-machine CRON[9507]: (CRON) info (No MTA installed, discarding output) This command will output all recent executions. If the result is empty most probably nothing was scheduled. Then you can check by: crontab -e ****************************** 04Sep2018 anacron -> where is anacrontab? Do I still use crontab ? still stuck at hourly updates! In spite of searches below, I still can't see where ClamAV is run hourly!!??? +-----+ # /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file # and files in /etc/cron.d. These files also have username fields, # that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) # +-----+ # /etc/cron.d/anacron: crontab entries for the anacron package SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 30 7 * * * root test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d anacron start >/dev/null +-----+ https://askubuntu.com/questions/848610/confused-about-relationship-between-cron-and-anacron Both cron and anacron are daemons that can schedule execution of recurring tasks to a certain point in time defined by the user. The main difference between cron and anacron is that the former assumes that the system is running continuously. If your system is off and you have a job scheduled during this time, the job never gets executed. On the other hand anacron is 'anachronistic' and is designed for systems that are not running 24x7. For it to work anacron uses time-stamped files to find out when the last time its commands were executed. It also maintains a file /etc/anacrontab just like cron does. In addition, cron.daily runs anacron everyhour. Also, anacron can only run a job once a day, but cron can run as often as every minute. From man anacrontab: When executed, Anacron reads a list of jobs from a configuration file, normally /etc/anacrontab (see anacrontab(5)). This file contains the list of jobs that Anacron controls. Each job entry specifies a period in days, a delay in minutes, a unique job identifier, and a shell command. For each job, Anacron checks whether this job has been executed in the last n days, where n is the period specified for that job. If not, Anacron runs the job's shell command, after waiting for the number of minutes specified as the delay parameter. After the command exits, Anacron records the date in a special timestamp file for that job, so it can know when to execute it again. Only the date is used for the time calculations. The hour is not used. This means, if a task is scheduled to be run daily and the computer was turned off during that time, when anacron is run, it can see that the task was last run more than 24 hours ago and execute the task correctly. For example if you specify the following in /etc/anacrontab: 7 15 test.daily /bin/sh /home/username/script.sh and on the day when the script.sh job is supposed to executed, if the system is not running, anacron will execute the script.sh 15 minutes after the system comes back up. Few Reference: Anacron sourceforge page http://anacron.sourceforge.net/ Digital ocean page https://www.digitalocean.com/community/tutorials/how-to-schedule-routine-tasks-with-cron-and-anacron-on-a-vps RedHat documentation on cron and anacron https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Automating_System_Tasks.html edited Aug 21 '17 at 22:26, Arnon answered Nov 12 '16 at 17:19, Ron ************************** 01Sep2018 anacrontab - how to use it? ?? It appears that I merely add a script file to one of anacron has directories /etc/cron.[daily, hourly, monthly, weekly] clamscan should be run once a day or week - for now set once a day I created & saved : +-----+ #!/bin/sh # www.BillHowell.ca 01Sep2018 initial # $ kwrite "/media/bill/PROJECTS/System_maintenance/Linux/cron & anacron daily Howell.txt" # $ sudo cp "/media/bill/PROJECTS/System_maintenance/Linux/cron & anacron daily Howell.txt" "/etc/cron.daily/cron & anacron daily Howell" /usr/local/bin/freshclam --quiet +-----+ >> check tomorrow if works? ************************** 01Sep2018 anacrontab file contents : # /etc/anacrontab: configuration file for anacron # See anacron(8) and anacrontab(5) for details. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root LOGNAME=root # These replace cron's entries 1 5 cron.daily run-parts --report /etc/cron.daily 7 10 cron.weekly run-parts --report /etc/cron.weekly @monthly 15 cron.monthly run-parts --report /etc/cron.monthly **************************** NAME /etc/anacrontab - configuration file for anacron DESCRIPTION The file /etc/anacrontab describes the jobs controlled by anacron(8). Its lines can be of three kinds: job-description lines, environment assignments, or empty lines. Job-description lines are of one of these two forms: period delay job-identifier command @period_name delay job-identify command The period is specified in days, the delay in minutes. The job-identifier can contain any non-blank char‐ acter, except slashes. It is used to identify the job in Anacron messages, and as the name for the job's timestamp file. The command can be any shell command. The fields can be separated by blank spaces or tabs. The period_name can only be set to monthly at the present time. This will ensure jobs are only run once a month, no matter the number of days in this month, or the previous month. Environment assignment lines are of the form: VAR = VALUE Spaces around VAR are removed. No spaces around VALUE are allowed (unless you want them to be part of the value). The assignment takes effect from the next line to the end of the file, or to the next assignment of the same variable. Empty lines are either blank lines, line containing white-space only, or lines with white-space followed by a '#' followed by an arbitrary comment. You can continue a line onto the next line by ending it with a '\'. SEE ALSO anacron(8) The Anacron README file. AUTHOR Itai Tzur Currently maintained by Pascal Hakim . ***************************** 01Sep2018 search "anacron package" https://packages.debian.org/sid/anacron Package: anacron (2.3-24) cron-like program that doesn't go by time Anacron (like "anac(h)ronistic") is a periodic command scheduler. It executes commands at intervals specified in days. Unlike cron, it does not assume that the system is running continuously. It can therefore be used to control the execution of daily, weekly, and monthly jobs (or anything with a period of n days), on systems that don't run 24 hours a day. When installed and configured properly, Anacron will make sure that the commands are run at the specified intervals as closely as machine uptime permits. This package is pre-configured to execute the daily jobs of the Debian system. You should install this program if your system isn't powered on 24 hours a day to make sure the maintenance jobs of other Debian packages are executed each day. +-----+ man anacron NAME anacron - runs commands periodically SYNOPSIS anacron [-s] [-f] [-n] [-d] [-q] [-t anacrontab] [-S spooldir] [job] ... anacron [-S spooldir] -u [-t anacrontab] [job] ... anacron [-V|-h] anacron -T [-t anacrontab] DESCRIPTION Anacron can be used to execute commands periodically, with a frequency specified in days. Unlike cron(8), it does not assume that the machine is running continuously. Hence, it can be used on machines that aren't running 24 hours a day, to control daily, weekly, and monthly jobs that are usually controlled by cron. When executed, Anacron reads a list of jobs from a configuration file, normally /etc/anacrontab (see anacrontab(5)). This file contains the list of jobs that Anacron controls. Each job entry specifies a period in days, a delay in minutes, a unique job identifier, and a shell command. For each job, Anacron checks whether this job has been executed in the last n days, where n is the period specified for that job. If not, Anacron runs the job's shell command, after waiting for the number of min‐ utes specified as the delay parameter. After the command exits, Anacron records the date in a special timestamp file for that job, so it can know when to execute it again. Only the date is used for the time calculations. The hour is not used. When there are no more jobs to be run, Anacron exits. Anacron only considers jobs whose identifier, as specified in the anacrontab matches any of the job com‐ mand-line arguments. The job arguments can be shell wildcard patterns (be sure to protect them from your shell with adequate quoting). Specifying no job arguments, is equivalent to specifying "*" (That is, all jobs will be considered). Unless the -d option is given (see below), Anacron forks to the background when it starts, and the parent process exits immediately. Unless the -s or -n options are given, Anacron starts jobs immediately when their delay is over. The exe‐ cution of different jobs is completely independent. If a job generates any output on its standard output or standard error, the output is mailed to the user running Anacron (usually root), or to the address contained by the MAILTO environment variable in the crontab, if such exists. Informative messages about what Anacron is doing are sent to syslogd(8) under facility cron, priority notice. Error messages are sent at priority error. "Active" jobs (i.e. jobs that Anacron already decided to run and now wait for their delay to pass, and jobs that are currently being executed by Anacron), are "locked", so that other copies of Anacron won't run them at the same time. OPTIONS -f Force execution of the jobs, ignoring the timestamps. -u Only update the timestamps of the jobs, to the current date, but don't run anything. -s Serialize execution of jobs. Anacron will not start a new job before the previous one finished. -n Run jobs now. Ignore the delay specifications in the /etc/anacrontab file. This options implies -s. -d Don't fork to the background. In this mode, Anacron will output informational messages to standard error, as well as to syslog. The output of jobs is mailed as usual. -q Suppress messages to standard error. Only applicable with -d. -t anacrontab Use specified anacrontab, rather than the default -T Anacrontab testing. The configuration file will be tested for validity. If there is an error in the file, an error will be shown and anacron will return 1. Valid anacrontabs will return 0. -S spooldir Use the specified spooldir to store timestamps in. This option is required for users who wish to run anacron themselves. -V Print version information, and exit. -h Print short usage message, and exit. FILES /etc/anacrontab Contains specifications of jobs. See anacrontab(5) for a complete description. /var/spool/anacron This directory is used by Anacron for storing timestamp files. +-----+ NAME crontab - maintain crontab files for individual users (Vixie Cron) SYNOPSIS crontab [ -u user ] file crontab [ -u user ] [ -i ] { -e | -l | -r } DESCRIPTION crontab is the program used to install, deinstall or list the tables used to drive the cron(8) daemon in Vixie Cron. Each user can have their own crontab, and though these are files in /var/spool/cron/crontabs, they are not intended to be edited directly. If the /etc/cron.allow file exists, then you must be listed (one user per line) therein in order to be allowed to use this command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use this command. If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use this command, or all users will be able to use this command. If both files exist then /etc/cron.allow takes precedence. Which means that /etc/cron.deny is not consid‐ ered and your user must be listed in /etc/cron.allow in order to be able to use the crontab. Regardless of the existance of any of these files, the root administrative user is always allowed to setup a crontab. For standard Debian systems, all users may use this command. If the -u option is given, it specifies the name of the user whose crontab is to be used (when listing) or modified (when editing). If this option is not given, crontab examines "your" crontab, i.e., the crontab of the person executing the command. Note that su(8) can confuse crontab and that if you are running inside of su(8) you should always use the -u option for safety's sake. The first form of this command is used to install a new crontab from some named file or standard input if the pseudo-filename ``-'' is given. The -l option causes the current crontab to be displayed on standard output. See the note under DEBIAN SPE‐ CIFIC below. The -r option causes the current crontab to be removed. The -e option is used to edit the current crontab using the editor specified by the VISUAL or EDITOR envi‐ ronment variables. After you exit from the editor, the modified crontab will be installed automatically. If neither of the environment variables is defined, then the default editor /usr/bin/editor is used. The -i option modifies the -r option to prompt the user for a 'y/Y' response before actually removing the crontab. ****************************** 01Sep2018 15:33 /etc/crontab # /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file # and files in /etc/cron.d. These files also have username fields, # that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) anacron has directories /etc/cron.[daily, hourly, monthly, weekly] what is /etc/cron.d? is it cron or anacron -> anacron +-----+ # /etc/cron.d/anacron: crontab entries for the anacron package SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 30 7 * * * root test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d anacron start >/dev/null ****************************** 01Sep2018 crontab -> freshclam frequency It's dumb to do this every hour - it hasn't even been activated for 1.5 years!! change to once per day +-----+ # /media/bill/PROJECTS/System_maintenance/security/crontab_howell.txt # www.BillHowell.ca 30Aug2018 * 10 * * * /usr/local/bin/freshclam --quiet +-----+ m h d m w https://www.wikihow.com/Set-up-a-Crontab-File-on-Linux m minute h hour d day of month m month 1-12 w weekday 0-7, Sun,Mon, etc (Sunday = 0 = 7) It is easy to remember if you think of the way one would say a date: Wednesday, July 29, at 10:30, then reverse the order. $ sudo kwrite "/media/bill/PROJECTS/System_maintenance/security/crontab_howell.txt" ************************* 26Nov2015 Audio alarm for low battery http://unix.stackexchange.com/questions/60778/how-can-i-get-an-alert-when-my-battery-is-about-to-die-in-linux-mint NOTE: (This would be a comment to orangenarwhals answer, but I do not have enough reputation either..) I do now run the following: $ crontab -e */5 * * * * /home//bin/checkLowBattery $ cat /home//bin/checkLowBattery #!/bin/bash POWERSUPPLY="/sys/class/power_supply/ACAD/online" # could be different on your system! TOO_LOW=20 # how low is too low? NOT_CHARGING="0" ICON="/usr/share/icons/ubuntu-mono-dark/status/24/battery-low.svg" # eye candy export DISPLAY=:0 BATTERY_LEVEL=$(acpi -b | grep -P -o '[0-9]+(?=%)') STATUS=$(cat $POWERSUPPLY) if [ $BATTERY_LEVEL -le $TOO_LOW -a $STATUS = $NOT_CHARGING ] then /usr/bin/notify-send -u critical -i "$ICON" -t 3000 "Battery low" "Battery level is ${BATTERY_LEVEL}%!" fi exit 0 As you can see this is just orangenarwhals code with some changes: no dbus trickery, somehow I didn't need it put some "constants" into variables at the beginning of code implemented warnings only when battery is not charging (take a look at man test, it explains how to do ANDs, among other things.) added icon (find some candidates on your system with something like: $ find /usr/share/icons/ -iname "*batt*low*") expiry-time in milliseconds don't forget to chmod +x your scripts, you can then run them directly from cron(tab), no need for sh. (This works on Ubuntu using Xmonad.) shareimprove this answer edited Sep 30 at 3:47 slm♦ 137k26209379 answered Mar 14 at 15:07 +-----+ 1 down vote I have the same issue and it is really frustrating. I solved by using the BatteryAlert.sh script: #!/bin/bash BATTERY=$(upower -e | grep 'BAT') while [ 1 ] do BATTERY_PERCENTAGE=$(upower -i $BATTERY|grep percentage|awk '{ print $2 }'|sed s/'%'/''/g) if [[ "$BATTERY_PERCENTAGE" -lt "5" ]]; then notify-send --urgency=critical "WARNING: Battery is about to die" "Plug in the power cable" play /usr/share/sounds/KDE-Sys-Warning.ogg &> /dev/null fi sleep 10 done I am using KDE but you can use it with every desktop environment. You don't have to run this as root user or go crazy with crontab syntax. You need only to change the notification sound if you want a sound alert. If you wan't to start the script automatically when the desktop environment starts put the script in $USER/bin folder with the BatteryAlertLauncher.sh script: #!/bin/bash function getRunningProcesses { ps -aux | grep -v grep | grep BatteryAlert.sh } if [[ -n "$(getRunningProcesses)" ]] ; then exit fi BatteryAlert.sh& Make sure that they are executable: chmod u+x $USER/bin/BatteryAlert* Then just run the following command: ln -s /home/$(USER)/bin/BatteryAlertLauncher.sh .config/autostart/ You can also running the alert script manually from bash by entering this command: BatteryAlertLauncher.sh enddoc