On Linux servers, cron can be used to schedule jobs that run commands and shell scripts at fixed times, dates or intervals. It's great for repetitive tasks like backups, downloads and deleting log files.

Set the default editor
Here's how to use the Vi text editor in a one-time session or as the default crontab editor.
Run the export command to set the default editor for the session
export VISUAL=vi
Change to user's home directory and edit the user's environment PATH settings (CentOS) to permanently set the user's default editor
cd ~
vi .bashrc
Append the following
# User specific aliases and functions
export VISUAL=vi
export EDITOR=$VISUAL
Activate the change in settings
. ~/.bashrc
Crontab
Each line in a crontab file represents a scheduled job. Each job begins with time parameters in the following sequence:
minute: between 0 and 59.
hour: between 0 and 23.
day: day of month, depends on month.
month: between 1 and 12.
day of week: between 0 and 7, where Sunday can be both 0 or 7.
command: the command to execute.
* any value (placeholder or unused date parameter)
/ step values.
- range of values.
, value list separator.
Run a shell script at 11:00am every day
0 11 * * * sh /home/user/script.sh
Run a shell script every two hours, on the hour
0 */2 * * * sh /home/user/script.sh
Run a shell script every fifteen minutes
*/15 * * * * sh /home/user/script.sh
Run a shell at 11:00am every Tuesday
0 11 * * 2 sh /home/user/script.sh
Make sure the crontab file ends with an empty line
SELinux problems?sudo setenforce 0disables SELinux enforcement temporarily. For a permanent fix, configure the correct SELinux context for your scripts withchconorsemanage fcontextinstead.
Commands
sudo systemctl status crond check service status
crontab -l list jobs
crontab -e edit jobs
Redirecting output to log files
This example has three jobs. Each job runs a different shell script, silences cron error messages and then appends any remaining output to a specific log file.
01 01 * * * /home/ontology.sh > /dev/null 2>> /home/saf/logs/cron.log
01 01 * * * /home/webapps.sh > /dev/null 2>> /home/saf/logs/cron.log
01 01 * * * /home/logs.sh > /dev/null 2>> /home/saf/logs/cron.log
> is for redirect
/dev/null is a black hole for data
2 is the file descriptor for Standard Error (STDERR)
>> append to file
Disabling a job without removing it
There are a couple ways to disable a job without removing it or just using a comment # in a couple of different scenarios.
Linux cron
For cases where you need to toggle without editing the crontab, use a flag file guard. Cron still fires on schedule, but the command exits immediately if the flag file exists.
0 11 * * * [ -f /home/user/.disable_script ] || sh /home/user/script.sh
To disable: touch /home/user/.disable_script
To re-enable: rm /home/user/.disable_script
Kubernetes Helm chart
In Kubernetes, the Helm values file is the toggle. Make each cronjob's enabled state a value in values.yaml:
cronjobs:
- name: citrix-sessions
enabled: true
schedule: "0 11 * * *"
- name: citrix-connections
enabled: false
schedule: "0 12 * * *"
In the Helm template, only render the CronJob when enabled is true:
{{- range .Values.cronjobs }}
{{- if .enabled }}
apiVersion: batch/v1
kind: CronJob
metadata:
name: {{ .name }}
spec:
schedule: {{ .schedule | quote }}
{{- end }}
{{- end }}
When enabled: false, the CronJob doesn't exist in the cluster. Set enabled: true and ArgoCD syncs it back. The job definition stays in the chart as a record, and toggling goes through Git with PR review and version history.
