Preliminary Parameter in Oracle DBA

Some time ago a customer had problems with an application that generates many blocking sessions. In the end all the blocking session grows up and exceeds the available processes on the database so that the ORA-00020 maximum number of processes exceeded error occurred. The customer also asks me, to analyze the problem to know which statement is the root cause of the problem.

The problem now is that the database preventing new connections to that instance (normal users and for sysdba connection). Sure you can now kill some session at OS level to get a process for your connection or restart the database, but if you kill the wrong connection you may not find the root cause of the problem.

[oracle@server1 prelim]$ sqlplus scott/tiger

SQL*Plus: Release 12.1.0.1.0 Production on Sun Jun 15 16:08:35 2014

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

ERROR:

ORA-00020: maximum number of processes (300) exceeded

The same issue occur if we try to login as sysdba user.

[oracle@server1 DB12EE]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Sun Jun 15 16:11:40 2014

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

ERROR:

ORA-00020: maximum number of processes (300) exceeded

What we can do here is to use the Preliminary Parameter to start a sqlplus session. Using a sqlplus preliminary connection you will be able to connect to the database since no session is actually created, but you will have limited access to the SGA. This will help in capturing diagnostic information like a systemstate dump to aid in problem resolution.

[oracle@server1 DB12EE]$ sqlplus -prelim / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Sun Jun 15 16:20:09 2014

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> oradebug setmypid

Statement processed.

SQL> oradebug hanganalyze 3

Statement processed.

SQL> oradebug TRACEFILE_NAME

/u01/app/oracle/diag/rdbms/db12ee/DB12EE_1/trace/DB12EE_1_ora_24689.trc

With 11.2.0.2 onwards oradebug hanganalyze will not produce output under a sqlplus „preliminary connection“. If you do this as shown in this example oradebug seems to run successful but when we look into the trace file generated we only see this message.

Processing Oradebug command 'hanganalyze 3'

===============================================================================

HANG ANALYSIS:

ERROR: Cannot perform hang analysis dump without a process

       state object and a session state object.

  ( process=(nil), sess=(nil) )

===============================================================================

Now we can make a systemstate dump of the database. The trace files generated here are also helpful to analyze a problem like here described. Also read the documentation which level is suitable for your problem.

SQL> oradebug setmypid

Statement processed.

SQL> oradebug unlimit

Statement processed.

SQL> oradebug dump systemstate 267

Statement processed.

SQL> oradebug TRACEFILE_NAME

/u01/app/oracle/diag/rdbms/db12ee/DB12EE_1/trace/DB12EE_1_ora_24689.trc

After you have created your trace files you can try to kill some of the database session so a normal login is possible. To kill a database session you can use „kill -9“ on Unix or „orakill“ on windows. Once you have a connection to the database you can do further analyze of the problem.

I want to talk about a situation that happened to me a few days ago. I logged in to one of my databases and my connection was hanged. My database was not accepting new connections. Now bound to the database server and I checked the status of the listener.

# lsnrctl status

Everything was normal. The listener is listening to my database. So I didn’t get any error from listener. I tried to log in with “sqlplus / as sysdba” but I failed. A connection on the server was also hanging. I checked the background processes.

# ps -ef | grep ora_

Everything was normal. And I learned something I did not know until that day. The backdoor entry of the Oracle database! You can enter to the database through the back door using SQL * Plus tool with “Prelim” parameter:)  Prelim, directly connects to the SGA but it does not open a session.

You can connect to the database with Prelim as following

# sqlplus -prelim / as sysdba
SQL>

Or

# sqlplus /nolog
SQL> set _prelim on
SQL> conn / as sysdba
Prelim connection established

Now, you can analyze the SGA using oradebug command.

Resolve huge archive gap between PRIMARY and STANDBY Large gaps

A Physical Standby database synchs with Primary by continuous applies of archive logs from a Primary Database.

When the logs are missing on standby difference is huge (say more than 500 logs), you have to rebuild the standby database from scratch.

Without rebuild standby database, as an enhancement from 10g, an incremental backup created with BACKUP INCREMENTAL… FROM SCN can be used to refresh the standby database.

Please use below query to find out archive gap on Standby:

SELECT ARCH.THREAD# “Thread”, ARCH.SEQUENCE# “Last Sequence Received”, APPL.SEQUENCE# “Last Sequence Applied”, (ARCH.SEQUENCE# – APPL.SEQUENCE#) “Difference” FROM (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH, (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL WHERE ARCH.THREAD# = APPL.THREAD# ORDER BY 1;

 Thread        Last Sequence Received      Last Sequence Applied      Difference

———-              ———————-                  ———————             ———-  

1                               8254                                      7954                          300

Find the SCN on the PRIMARY:

SQL> select current_scn from v$database;

CURRENT_SCN

———–  

242671761

Find the SCN on the STANDBY:

SQL> select current_scn from v$database;

CURRENT_SCN

———–  

223771173

Clearly you can see there is difference

Stop and shutdown the managed standby apply process:

SQL> alter database recover managed standby database cancel;

Database altered.

Shutdown the standby database

SQL> shut immediate

On the primary, take an incremental backup from the SCN number where the standby current value 223771173:

 RMAN> run { allocate channel c1 type disk format ‘/backup/%U.bkp’;

backup incremental from scn 223771173 database;

 }

On the primary, create a new standby controlfile:

SQL> alter database create standby controlfile as ‘/backup/for_standby.ctl’;

Database altered.

Copy the standby controlfile to STANDBY and bring up the standby instance in nomount status with standby controlfile:

SQL> startup nomount

SQL> alter database mount standby database;

Connect to RMAN on STANDBY, Catalog backup files to RMAN using below commands:

$ rman target=/

RMAN> catalog start with ‘/backup’;

PERFORM RECOVER:

RMAN> recover database;

Start managed recovery process:

SQL> alter database recover managed standby database disconnect from session;

Database altered.

Check the SCN’s in primary and standby it should be close to each other.

Resolve archive gap between PRIMARY and STANDBY less than 10-15 numbers

A Physical Standby database synchs with Primary by continuous applies of archive logs from a Primary Database.

When the logs are missing on standby is less than 10-15 numbers, We can simple ship the logs which are missing in the standby database from primary database by using SCP/FTP and then register the logfiles in standby to resolve the gap.

Please use below query to find out archive gap on Standby:

SELECT ARCH.THREAD# “Thread”, ARCH.SEQUENCE# “Last Sequence Received”, APPL.SEQUENCE# “Last Sequence Applied”, (ARCH.SEQUENCE# – APPL.SEQUENCE#) “Difference” FROM (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH, (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL WHERE ARCH.THREAD# = APPL.THREAD# ORDER BY 1;

 

Thread  Last Sequence Received   Last Sequence Applied     Difference

———-  ———————-                          ———————        ———-  

1                   9545                                             9535                   10

SQL> SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED=’YES’;

 MAX(SEQUENCE#)

————–

9535

COPY ARCHIVELOG FILE TO STANDBY FROM PRIMARY:

$ scp log_file_n.arc oracle@standby:/log_location/log_file_n.arc

REGISTER LOGFILE AT STANDBY:

SQL> alter database register logfile ‘/log_location/log_file_n.arc’; logfile registered

Repeat the same process for all the log files which are missing at standby.

Manually Resolving Gaps - Oracle Data Guard 11gR2

For simplicity, Gap is a range of archived redo logs that were created at a time when the standby database was not available to receive them. In many practices it happen because the network problems.

We have 3 methods to resolving this problem. I’ll dispatch it to two main methods,

Manually resolving

Automatic resolving : Using log switched and FAL configuration

1. Start with detecting gaps in the redo logs by querying the v$archive_gap

SQL> select * from v$archive_gap;

Thread#   low_sequence#   high_sequence#
-------- ----------------  ------------------
         1                     30                      34 

   The output indicates our standby database is currently missing log files from sequence 30 to
   34.

2. Issue following statement on primary database to locate the archived redo log files. Assuming
    the local archive destination on primary is LOG_ARCHIVE_DEST_1

SQL> select name from v$archived_log where thread#=1 and dest_id=1 and sequence# between 30 and 34; 

name
----------------------------------

/u02/oraarchive/DB01/arch_t1_s30.dbf  

/u02/oraarchive/DB01/arch_t1_s31.dbf  

/u02/oraarchive/DB01/arch_t1_s32.dbf  

/u02/oraarchive/DB01/arch_t1_s33.dbf  

/u02/oraarchive/DB01/arch_t1_s34.dbf 

3. Stop the automatic recovery (MRP) of the data guard

SQL> alter database recover managed standby database cancel;

4. Transfer manually the archived log files shown on the step 2 to standby database
5. Register that archived log files on standby database

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s30.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s31.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s32.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s33.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s34.dbf'; 

6. Put the standby database into automatic recovery managed mode

 SQL> alter database recover managed standby database disconnect from session;

7. Verify that the gap gets resolved on standby database

SQL> select sequence#, applied from v$archived_log order by sequence#; 
now you figure it out, that your archived log files (ARCLs) has been synchronize with your primary database. As a DBA you must take a notice at log using this SQL statement

SQL> select message from v$dataguard_status where severity like 'Warning';

Also on your alert.log

Source version control tools for system admins

As a system admin, the chances are you collaborate with multiple people across the company, therefore you will probably know the stress of constantly transferring files and version controlling the changes. Version control tools are a great way to enable collaboration, maintain versions, and track changes across the team.

Perhaps the greatest benefit of using version control tools is that you have the capacity to deal with an unlimited number of people, working on the same code base, without having to make sure that files are delivered back and forth. Below are some of the most popular and most preferred open-source version control systems and tools available for making your setup easier.

1. CVS

CVS may very well be where version control systems started. Released initially in 1986, Google still hosts the original Usenet post that announced CVS. CVS is basically the standard here, and is used just about everywhere – however the base for codes is not as feature rich as other solutions such as SVN.
One good thing about CVS is that it is not too difficult to learn. It comes with a simple system that ensures revisions and files are kept updated. Given the other options, CVS may be regarded as an older form of technology, as it has been around for some time, it is still incredibly useful for system admins who want to backup and share files.

2. SVN

SVN, or Subversion as it is sometimes called, is generally the version control system that has the widest adoption. Most forms of open-source projects will use Subversion because many other large products such as Ruby, Python Apache, and more use it too. Google Code even uses SVN as a way of exclusively distributing code.
Because it is so popular, many different clients for Subversion are available. If you use Windows, then Tortoise SVN may be a great browser for editing, viewing and modifying Subversion code bases. If you’re using a MAC, however, then Versions could be your ideal client.

3. GIT

Git is considered to be a newer, and faster emerging star when it comes to version control systems. First developed by the creator of Linux kernel, Linus Torvalds, Git has begun to take the community for web development and system administration by storm, offering a largely different form of control. Here, there is no singular centralized code base that the code can be pulled from, and different branches are responsible for hosting different areas of the code. Other version control systems, such as CVS and SVN, use a centralized control, so that only one master copy of software is used.
As a fast and efficient system, many system administrators and open-source projects use Git to power their repositories. However it is worth noting that Git is not as easy to learn as SVN or CVS is, which means that beginners may need to steer clear if they’re not willing to invest time to learn the tool.

4. Mercurial

This is yet another form of version control system, similar to Git. It was designed initially as a source for larger development programs, often outside of the scope of most system admins, independent web developers and designers. However, this doesn’t mean that smaller teams and individuals can’t use it. Mercurial is a very fast and efficient application. The creators designed the software with performance as the core feature.
Aside from being very scalable, and incredibly fast, Mercurial is a far simpler system to use than things such as Git, which one of the reasons why certain system admins and developers use it. There aren’t quite many things to learn, and the functions are less complicated, and more comparable to other CVS systems. Mercurial also comes alongside a web-interface and various extensive documentation that can help you to understand it better.

5. Bazaar

Similar to Git and Mercurial, Bazaar is distributed version control system, which also provides a great, friendly user experience. Bazaar is unique that it can be deployed either with a central code base or as a distributed code base. It is the most versatile version control system that supports various different forms of workflow, from centralized to decentralized, and with a number of different variations acknowledged throughout. . One of the greatest features of Bazaar is that you can access a very detailed level of control in its setup. Bazaar can be used to fit in with almost any scenario and this is incredibly useful for most projects and admins because it is so easy to adapt and deal with. It can also be easily embedded into projects that already exist. At the same time, Bazaar boasts a large community that helps with the maintenance of third-party tools and plugins.

CRON TAB Command

CRONTAB Command

You need to use the crontab command to edit/create, install, deinstall or list the cron jobs in Vixie Cron. Each user can have their own crontab file, and though these are files in /var/spool/cron/crontabs, they are not intended to be edited directly. You need to use crontab command for editing or setting up your own cron jobs.

Types of cron configuration files

There are different types of configuration files:

The UNIX / Linux system crontab : Usually, used by system services and critical jobs that requires root like privileges. The sixth field (see below for field description) is the name of a user for the command to run as. This gives the system crontab the ability to run commands as any user.

The user crontabs: User can install their own cron jobs using the crontab command. The sixth field is the command to run, and all commands run as the user who created the crontab

Note: This faq features cron implementations written by Paul Vixie and included in many Linux distributions and Unix like systems such as in the popular 4th BSD edition. The syntax is compatible with various implementations of crond.

How Do I install or create or edit my own cron jobs?

To edit or create your own crontab file, type the following command at the UNIX / Linux shell prompt:
$ crontab -e

Do I have to restart cron after changing the crontable file?

No. Cron will examine the modification time on all crontabs and reload those which have changed. Thus cron need not be restarted whenever a crontab file is modified.

Syntax of crontab (field description)

The syntax is:

1 2 3 4 5 /path/to/command arg1 arg2

OR

1 2 3 4 5 /root/backup.sh

Where,

1: Minute (0-59)

2: Hours (0-23)

3: Day (0-31)

4: Month (0-12 [12 == December])

5: Day of the week(0-7 [7 or 0 == sunday])

/path/to/command – Script or command name to schedule

Easy to remember format:

* * * * * command to be executed

- - - - -

| | | | |

| | | | ----- Day of week (0 - 7) (Sunday=0 or 7)

| | | ------- Month (1 - 12)

| | --------- Day of month (1 - 31)

| ----------- Hour (0 - 23)

------------- Minute (0 - 59)

Your cron job looks as follows for system jobs:

1 2 3 4 5 USERNAME /path/to/command arg1 arg2

OR

1 2 3 4 5 USERNAME /path/to/script.sh

Example: Run backup cron job script

If you wished to have a script named /root/backup.sh run every day at 3am, your crontab entry would look like as follows. First, install your cronjob by running the following command:
# crontab -e
Append the following entry:
0 3 * * * /root/backup.sh
Save and close the file.

More examples

To run /path/to/command five minutes after midnight, every day, enter:
5 0 * * * /path/to/command
Run /path/to/script.sh at 2:15pm on the first of every month, enter:
15 14 1 * * /path/to/script.sh
Run /scripts/phpscript.php at 10 pm on weekdays, enter:
0 22 * * 1-5 /scripts/phpscript.php
Run /root/scripts/perl/perlscript.pl at 23 minutes after midnight, 2am, 4am …, everyday, enter:
23 0-23/2 * * * /root/scripts/perl/perlscript.pl
Run /path/to/unixcommand at 5 after 4 every Sunday, enter:
5 4 * * sun /path/to/unixcommand

How do I use operators?

An operator allows you to specifying multiple values in a field. There are three operators:

The asterisk (*) : This operator specifies all possible values for a field. For example, an asterisk in the hour time field would be equivalent to every hour or an asterisk in the month field would be equivalent to every month.

The comma (,) : This operator specifies a list of values, for example: “1,5,10,15,20, 25”.

The dash (-) : This operator specifies a range of values, for example: “5-15” days , which is equivalent to typing “5,6,7,8,9,….,13,14,15” using the comma operator.

The separator (/) : This operator specifies a step value, for example: “0-23/” can be used in the hours field to specify command execution every other hour. Steps are also permitted after an asterisk, so if you want to say every two hours, just use */2.

How do I disable email output?

By default the output of a command or a script (if any produced), will be email to your local email account. To stop receiving email output from crontab you need to append >/dev/null 2>&1. For example:
0 3 * * * /root/backup.sh >/dev/null 2>&1
To mail output to particular email account let us say vivek@nixcraft.in you need to define MAILTO variable as follows:
MAILTO="vivek@nixcraft.in"

0 3 * * * /root/backup.sh >/dev/null 2>&1
See “Disable The Mail Alert By Crontab Command” for more information.

Task: List all your cron jobs

Type the following command:
# crontab -l
# crontab -u username -l
To remove or erase all crontab jobs use the following command:
# Delete the current cron jobs #
crontab -r

## Delete job for specific user. Must be run as root user ##
crontab -r -u username

Use special string to save time

Instead of the first five fields, you can use any one of eight special strings. It will not just save your time but it will improve readability.

Special string	Meaning
@reboot	Run once, at startup.
@yearly	Run once a year, “0 0 1 1 *”.
@annually	(same as @yearly)
@monthly	Run once a month, “0 0 1 * *”.
@weekly	Run once a week, “0 0 * * 0”.
@daily	Run once a day, “0 0 * * *”.
@midnight	(same as @daily)
@hourly	Run once an hour, “0 * * * *”.

Examples

Run ntpdate command every hour:
@hourly /path/to/ntpdate
Make a backup everyday:
@daily /path/to/backup/script.sh

More about /etc/crontab file and /etc/cron.d/* directories

/etc/crontab is system crontabs file. Usually only used by root user or daemons to configure system wide jobs. All individual user must must use crontab command to install and edit their jobs as described above. /var/spool/cron/ or /var/cron/tabs/ is directory for personal user crontab files. It must be backup with users home directory.

Understanding Default /etc/crontab

Typical /etc/crontab file entries:

SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

MAILTO=root

HOME=/

# run-parts

01 * * * * root run-parts /etc/cron.hourly

02 4 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly

First, the environment must be defined. If the shell line is omitted, cron will use the default, which is sh. If the PATH variable is omitted, no default will be used and file locations will need to be absolute. If HOME is omitted, cron will use the invoking users home directory.

Additionally, cron reads the files in /etc/cron.d/ directory. Usually system daemon such as sa-update or sysstat places their cronjob here. As a root user or superuser you can use following directories to configure cron jobs. You can directly drop your scripts here. The run-parts command run scripts or programs in a directory via /etc/crontab file:

Directory	Description
/etc/cron.d/	Put all scripts here and call them from /etc/crontab file.
/etc/cron.daily/	Run all scripts once a day
/etc/cron.hourly/	Run all scripts once an hour
/etc/cron.monthly/	Run all scripts once a month
/etc/cron.weekly/	Run all scripts once a week

How do I use above directories to put my own scripts or jobs?

Here is a sample shell script called clean.cache. This script is created to clean up cached files every 10 days. This script is directly created at /etc/cron.daliy/ directory. In other words create a text file called /etc/cron.daily/clean.cache as follows.

#!/bin/bash # A sample shell script to clean cached file from lighttpd web server CROOT="/tmp/cachelighttpd/" # Clean files every $DAYS DAYS=10 # Web server username and group name LUSER="lighttpd" LGROUP="lighttpd" # Okay, let us start cleaning as per $DAYS /usr/bin/find ${CROOT} -type f -mtime +${DAYS} | xargs -r /bin/rm # Failsafe # if directory deleted by some other script just get it back if [ ! -d $CROOT ] then         /bin/mkdir -p $CROOT         /bin/chown ${LUSER}:${LGROUP} ${CROOT} Fi

Save and close the file. Set the permissions:
# chmod +x /etc/cron.daily/clean.cache

How do I backup installed cron jobs entries?

Simply type the following command to backup your cronjobs to a nas server mounted at /nas01/backup/cron/users.root.bakup directory:
# crontab -l > /nas01/backup/cron/users.root.bakup
# crontab -u userName -l > /nas01/backup/cron/users.userName.bakup

http://www.computerhope.com/unix/ucrontab.htm

About crontab

The crontab is a list of commands that you want to run on a regular schedule, and also the name of the command used to manage that list.

crontab stands for "cron table," because it uses the job scheduler cron to execute tasks; cron itself is named after "chronos," the Greek word for time.

Overview

cron is the system process which will automatically perform tasks for you according to a set schedule. The schedule is called the crontab, which is also the name of the program used to edit that schedule.

Let's say you have a script which backs up important files, or creates a report about system statistics, for example. Let's say the script is called/home/myname/scripts/do-every-day.sh, and you want to run it every morning at 5 A.M.

To edit the crontab, use this command:

crontab -e

This will open the crontab in a text editor (Usually this is vi or vim, but it may be something else depending on your Linux distribution).

The default crontab file looks like this:

# Edit this file to introduce tasks to be run by cron.

#·

# Each task to run has to be defined through a single line

# indicating with different fields when the task will be run

# and what command to run for the task

#·

# To define the time you can provide concrete values for

# minute (m), hour (h), day of month (dom), month (mon),

# and day of week (dow) or use '*' in these fields (for 'any').#·

# Notice that tasks will be started based on the cron's system

# daemon's notion of time and timezones.

#·

# Output of the crontab jobs (including errors) is sent through

# email to the user the crontab file belongs to (unless redirected).

#·

# For example, you can run a backup of all your user accounts

# at 5 a.m every week with:

# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/

#·

# For more information see the manual pages of crontab(5) and cron(8)

#·

# m h  dom mon dow   command

These lines all start with a # because they are comments; they are ignored by cron, and are just there for you to read.

So, now let's add our job to the crontab. Each job you add should take up a single line.

But how do we format our job entry line? Above, you can see that the last comment line is there to remind you how to format your entry. The format is very simple: six pieces of information, each separated by a space; the first five pieces of information tell cronwhen to run the job, and the last piece of information tells cron what the job is.

The information you must include is (in order of appearance):

A number (or list of numbers, or range of numbers), m, representing the minute of the hour;

A number (or list of numbers, or range of numbers), h, representing the hour of the day;

A number (or list of numbers, or range of numbers), dom, representing the day of the month;

A number (or list, or range), or name (or list of names), mon, representing the month of the year;

A number (or list, or range), or name (or list of names), dow, representing the day of the week; and

command, which is the command to be run, exactly as it would appear on the command line.

A "number" is an integer, for example 5. A "list of numbers" is a set of integers separated by commas, for example 15,30,45, which would represent just those three numbers. A "range of numbers" is a set of numbers separated by a hyphen, for example10-20, which would represent all the numbers from 10 through 20, inclusive.

We want our job to run at 5 A.M., which would be minute 0, hour 5, every day of the month, every month, every day of the week. We need to add a line to the bottom of the file which looks like this:

0 5 * * * /home/myname/scripts/do-every-day.sh

In vi or vim, you can add this line by typing G to go to the end of the file, and o to add a new line and enter insert mode.

The asterisks ("*") in our entry tell cron that for that unit of time, the job should be run "every". You can now save the file and exit the text editor. In vi, this is done by pressingESCAPE and then typing :wq (for "write and quit") and pressing ENTER. crontab will give you the following message:

crontab: installing new crontab

...and return you to the command line. Your script will now run automatically at 5 A.M., every day.

To view your crontab, you can use this command:

crontab -v

...or, to remove your crontab so that there no jobs are ever executed by cron, use this command:

crontab -r

For more examples of how to configure your crontab, see our Examples section below.

crontab syntax

crontab [-u user] file

crontab [-u user] [-l | -r | -e] [-i] [-s]

Technical Description

crontab is the program used to edit, remove or list the tables used to drive the crondaemon. Each user can have their own crontab. Although these files are located in/var/spool/, they are not intended to be edited directly, and that's where the crontabcommand comes in.

cron jobs can be allowed or disallowed for individual users, as specified in the filescron.allow and cron.deny, located in the directory /etc. If the cron.allow file exists, a user must be listed there in order to be allowed to use a given command. If thecron.allow file does not exist but the cron.deny file does, then a user must not be listed there in order to use a given command. If neither of these files exists, only thesuperuser will be allowed to use a given command. Another option is using PAM (pluggable authentication module) authentication to set up users who may or may not use crontab and system cron jobs, as configured in /etc/cron.d/.

The temporary directory for cron jobs can be set in environment variables (see below); if not, /tmp is used as the temporary directory.

Options

-u	Append the name of the user whose crontab is to be tweaked. If this option is not given,crontab examines "your" crontab, i.e., the crontab of the person executing the command. Note that su can confuse crontab and that if you are running it inside of su you should always use the -u option for safety's sake. The first form of this command is used to install a newcrontab from some named file, or from standard input if the filename is given as "-".
-l	Display the current crontab.
-r	Remove the current crontab.
-e	Edit the current crontab, using the editor specified in the VISUAL or EDITOR environment variables.
-i	Same as -r, but gives the user a "Y/n" prompt before actually removing the crontab.
-s	SELinux only: appends the current SELinux security context string as an MLS_LEVEL setting to the crontab file before editing or replacement occurs. See your SELinux documentation for details.

More About crontab Files

Blank lines and leading spaces and tabs are ignored. Lines whose first non-space character is a pound-sign (#) are interpreted as comments, and are ignored. Note that comments are not allowed on the same line as cron commands, since they will be taken to be part of the command. Similarly, comments are not allowed on the same line as environment variable settings.

An active line in a crontab will be either an environment setting or a cron command. An environment setting is of the form

name = value

where the spaces around the equal sign (=) are optional, and any subsequent non-leading spaces in value will be part of the value assigned to name. The value string may be placed in quotes (single or double, but matching) to preserve leading or trailing blanks.

Several environment variables are set up automatically by the cron daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner. HOME and SHELL may be overridden by settings in the crontab;LOGNAME may not.

Another note: the LOGNAME variable is sometimes called USER on BSD systems. On these systems, USER will be set also.

In addition to LOGNAME, HOME, and SHELL, cron will look at MAILTO if it has any reason to send mail as a result of running commands in "this" crontab. If MAILTO is defined (and non-empty), mail is sent to the named user. If MAILTO is defined but empty ('MAILTO=""'), no mail will be sent. Otherwise mail is sent to the owner of the crontab. This option is useful if you decide on /bin/mail instead of /usr/lib/sendmailas your mailer when you install cron, because /bin/mail doesn't do aliasing.

By default, cron will send mail using the 'Content-Type:' header 'text/plain' with the 'charset=' parameter set to the charmap / codeset of the locale in which crond is started up: either the default system locale (if no LC_* environment variables are set) or the locale specified by the LC_* environment variables. You can use different character encodings for mailed cron job output by setting the CONTENT_TYPE andCONTENT_TRANSFER_ENCODING variables in crontabs.

The MLS_LEVEL environment variable provides support for multiple per-job SELinux security contexts in the same crontab. By default, cron jobs execute with the default SELinux security context of the user that created the crontab file. When using multiple security levels and roles, this may not be sufficient, because the same user may be running in a different role or at a different security level. You can set MLS_LEVEL to the SELinux security context string specifying the SELinux security context in which you want the job to run, and crond will set the execution context of the or jobs to which the setting applies to the specified context. See the description of crontab -s in the options section.

cron Command Format

Each cron command in the crontab file has five time and date fields, followed by a user name if it is the system crontab file, followed by a command. Commands are executed by cron when the minute, hour, and month of year fields match the current time, and at least one of the two day fields (day of month, or day of week) match the current time. Note that this means that nonexistent times, such as "missing hours" during daylight savings conversion, will never match, causing jobs scheduled during the "missing times" not to be run. Similarly, times that occur more than once during daylight savings will cause matching jobs to be run twice.

cron examines crontab entries once every minute.

The time and date fields are:

field	allowed values
minute	0-59
hour	0-23
day of month	1-31
month	1-12 (or names; see example below)
day of week	0-7 (0 or 7 is Sunday, or use names; see below)

A field may be an asterisk (*), which always stands for "first through last".

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. The specified range is inclusive; for example, 8-11 for an "hours" entry specifies execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas. Examples: "1,2,5,9", "0-4,8-12".

Step values can be used in conjunction with ranges. For example, "0-23/2" can be used in the hours field to specify command execution every other hour. Steps are also permitted after an asterisk, so if you want to say "every two hours", you can use "*/2".

Names can also be used for the "month" and "day of week" fields. Use the first three letters of the particular day or month (case doesn't matter). Ranges or lists of names are not allowed.

The "sixth" field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by/bin/sh or by the shell specified in the SHELL variable of the cronfile. Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input.

Note that the day of a command's execution can be specified by two fields: day of month, and day of week. If both fields are restricted (in other words, they aren't *), the command will be run when either field matches the current time. For example, "30 4 1,15 * 5" would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.

Files

/etc/cron.allow
/etc/cron.deny

crontab examples

crontab -e

Edit your crontab.

crontab -l

Display ("list") the contents of your crontab.

crontab -r

Remove your crontab, effectively un-scheduling all crontab jobs.

sudo crontab -u charles -e

Edit the crontab of the user named charles. The -u option requires administrator privileges, so the command is executed using sudo.

sudo crontab -u jeff -l

View the crontab of user jeff.

sudo crontab -u sandy -r

Remove the crontab of user sandy.

Examples Of crontab Entries

15 6 2 1 * /home/melissa/backup.sh

Run the shell script /home/melissa/backup.sh on January 2 at 6:15 A.M.

15 06 02 Jan * /home/melissa/backup.sh

Same as the above entry. Zeroes can be added at the beginning of a number for legibility, without changing their value.

0 9-18 * * * /home/carl/hourly-archive.sh

Run /home/carl/hourly-archive.sh every hour, on the hour, from 9 A.M. through 6 P.M., every day.

0 9,18 * * Mon /home/wendy/script.sh

Run /home/wendy/script.sh every Monday, at 9 A.M. and 6 P.M.

30 22 * * Mon,Tue,Wed,Thu,Fri /usr/local/bin/backup

Run /usr/local/bin/backup at 10:30 P.M., every weekday.

Related commands

at — Schedule a command to be run at a certain time.