Crontab – Quick Reference

from http://adminschoice.com/crontab-quick-reference

Crontab – Quick Reference

Setting up cron jobs in Unix and Solaris

cron is a unix, solaris utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are often termed as cron jobs in unix , solaris.  Crontab (CRON TABle) is a file which contains the schedule of cron entries to be run and at specified times.

This document covers following aspects of Unix cron jobs
1. Crontab Restrictions
2. Crontab Commands
3. Crontab file – syntax
4. Crontab Example
5. Crontab Environment
6. Disable Email
7. Generate log file for crontab activity

1. Crontab Restrictions
You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow. If that file does not exist, you can use
crontab if your name does not appear in the file /usr/lib/cron/cron.deny.
If only cron.deny exists and is empty, all users can use crontab. If neither file exists, only the root user can use crontab. The allow/deny files consist of one user name per line.

2. Crontab Commands

export EDITOR=vi ;to specify a editor to open crontab file.

crontab -e    Edit your crontab file, or create one if it doesn’t already exist.
crontab -l      Display your crontab file.
crontab -r      Remove your crontab file.
crontab -v      Display the last time you edited your crontab file. (This option is only available on a few systems.)

3. Crontab file
Crontab syntax :
A crontab file has five fields for specifying day , date and time followed by the command to be run at that interval.

*     *     *   *    *        command to be executed
-     -     -   -    -
|     |     |   |    |
|     |     |   |    +----- day of week (0 - 6) (Sunday=0)
|     |     |   +------- month (1 - 12)
|     |     +--------- day of        month (1 - 31)
|     +----------- hour (0 - 23)
+------------- min (0 - 59)

* in the value field above means all legal values as in braces for that column.
The value column can have a * or a list of elements separated by commas. An element is either a number in the ranges shown above or two numbers in the range separated by a hyphen (meaning an inclusive range).
Notes
A. ) Repeat pattern like /2 for every 2 minutes or /10 for every 10 minutes is not supported by all operating systems. If you try to use it and crontab complains it is probably not supported.

B.) The specification of days can be made in two fields: month day and weekday. If both are specified in an entry, they are cumulative meaning both of the entries will get executed .

4. Crontab Example
A line in crontab file like below removes the tmp files from /home/someuser/tmp each day at 6:30 PM.

30     18     *     *     *         rm /home/someuser/tmp/*

Changing the parameter values as below will cause this command to run at different time schedule below :
min     hour     day/month     month     day/week     Execution time
30     0     1     1,6,12     *     – 00:30 Hrs  on 1st of Jan, June & Dec.
0     20     *     10     1-5     –8.00 PM every weekday (Mon-Fri) only in Oct.
0     0     1,10,15     *     *     – midnight on 1st ,10th & 15th of month
5,10     0     10     *     1     – At 12.05,12.10 every Monday & on 10th of every month
:

Note : If you inadvertently enter the crontab command with no argument(s), do not attempt to get out with Control-d. This removes all entries in your crontab file. Instead, exit with Control-c.

5. Crontab Environment
cron invokes the command from the user’s HOME directory with the shell, (/usr/bin/sh).
cron supplies a default environment for every shell, defining:
HOME=user’s-home-directory
LOGNAME=user’s-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh

Users who desire to have their .profile executed must explicitly do so in the crontab entry or in a script called by the entry.

6. Disable Email
By default cron jobs sends a email to the user account executing the cronjob. If this is not needed put the following command At the end of the cron job line .

>/dev/null 2>&1

7. Generate log file
To collect the cron execution execution log in a file :

30 18 * * * rm /home/someuser/tmp/* > /home/someuser/cronlogs/clean_tmp_dir.log

Issues with TSM server not able to talk to client...

We ran into this today:

ANR2716E Schedule prompter was not able to contact client using type 1

After some Google searching:

If you use a firewall, your clients must use the option

SCHEDMODE POLLING

The clients will then start their backup when the scheduled time has come.

Various useful TSM links:

Tivoli Support - http://www-947.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager?S_CMP=rnav

Software FTP Site - ftp://ftp.software.ibm.com/storage/tivoli-storage-management/

Device Driver Downloads - http://www-933.ibm.com/support/fixcentral/options?productGroup0=ibm/StorageSystems&productGroup1=ibm/Storage_Tape&productGroup2=ibm/ST/Tapedevicedriversandsoftware&productGroup3=ibm/Storage_Tape/Tape+device+drivers

6.2 Documentation Center - http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/index.jsp

Documentation Centers - http://www.ibm.com/developerworks/wikis/display/tivolidoccentral/Tivoli+Storage+Manager

TSM Client cluster password deleted when generic resource brought online

Problem

TSM Client cluster password deleted when generic resource brought online

Solution

Manually updating the cluster node password while the MSCS generic resource is offline causes the checkpoint file held on the quorum disk to become out of sync with the password entry for the cluster node in the registry. When bringing the generic resource online, the password entry for the cluster node is deleted and the ANS2050E error is observed in the error log. Assumptions: Resetting the password on the TSM client on each machine has not resolved the issue. The encrypted values match for the password key in the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\NODENAME\SERVERNAME When the generic service resource is brought online, the password value is deleted from the registry. In a cluster environment, the generic service resource used by TSM is used to control the stopping and starting of the scheduler service. It is also used to start the TSM scheduler service on the failover machine when a failover occurs. When the generic service resource is initialized, it compares the registry value of: HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\NODENAME\SERVERNAME With a checkpoint file located on the quorum drive (.cpt file). If the password for the client node is changed while the generic service resource was offline, this checkpoint file and the registry may become out of sync. When this occurs, the generic service resource will overwrite the value in the registry with the value in the checkpoint file, or it will remove the password value in the registry. One way to verify if the checkpoint file and registry have become out of sync, is to take the generic service resource offline, reset the password for the client node (using DSMC Q SE -OPTFILE=XXXX from the client command line), and try to start the TSM scheduler service without the generic service resource. If the scheduler service starts and maintains a "started" state, this confirms the out of sync state between the checkpoint file and the registry. There are two possible solutions; one is to contact Microsoft support to recreate the checkpoint file. The other is to follow the steps below which should also create the checkpoint file Reset the clusternode password on the TSM server. On the active node, open a command line and start up dsmc with the appropriate dsm.opt specified for the clusternode. TSM will prompt for the new password, and load this into the registry when it is supplied. The clusternode scheduler can then be started manually, as a local service. Once the clusternode scheduler is started as a local service, the cluster Generic Resource which manages it can be manually brought online through the Cluster Administrator. If it is started after the scheduler is started as a local service, and neither it nor the cluster are bounced, it should stay online. *While the Generic Service is running* reset the clusternode password at the TSM server *again*. Again, open up a command line, start up dsmc with the appropriate dsm.opt file, and fill in the password when requested. Fail the nodes over, so that the active node is now passive and vice versa. The cluster Generic Service, with its newly-filled-in password, should successfully fail over as well, and stay online. Start up a command-line dsmc session with the appropriate dsm.opt file, to fill in the new password if necessary and to check that the session is connecting properly. The new checkpoint file has been written, matches the registry key, and the clusternode TSM scheduler can once again run under the control of the cluster Generic Resource. Without that second password reset, the Generic Resource fails as soon as the cluster fails over. With the second password reset, done while the Generic Resource is running, it rewrites the checkpoint file.

TSM NDMP Restore Setup

Many thanks to my TSM co-worker Bill, you are the man!

http://www-01.ibm.com/support/docview.wss?uid=swg21254984