About Crontab .........

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 :

					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

Cron permissions

The following two files play an important role:

• /etc/cron.allow - If this file exists, then you must be listed therein (your username must be listed) in order to be allowed to use cron jobs.
• /etc/cron.deny - If the 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 cron jobs.

Please note that if neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use cron jobs, or all users will be able to use cron jobs.

Solaris Booting process

Solaris Boot Process

***********************

The boot process loads the binary kernel from a bootable system disk into physical memory, initializes the kernel structure, sets system tunable parameters, starts system processes and brings the system to a known, usable state.

the basic steps of booting are :

1. The 'boot' command reads and loads the bootblock into memory.
2. The bootblock locates and loads the secondary boot program, ufsboot, into memory and passes control to it.
3. Ufsboot locates and loads the core kernel images and the required kernel runtime linker into memory and passes control to the loaded kernel.
4. The core kernel locates and loads mandatory kernel modules from the root-disk directory tree and executes the main startup code.
5. The kernel startup code executes, creating and initializing kernel structures, resources and software components.
6. The system executes shell scripts from the system directories, bringing that system upto the init state specified in /etc/inittab.


The initial stage of the boot process requires support from system firmware, typically loaded into a PROM,
such that a bootable device can be addressed and that some minimal I/O functionality exists for reading of a promary bootblock.

For SPARC, the firmware is known as OpenBoot PROM or OBP and is written in forth programming language.

Immediately after system is powered on, OBP does the following :
1. Provide a Power-On Self Test or POST.
2. Test and initialize the system hardware.
3. Determine the hardware configuration.
4. Boot the operating system.
5. Provide interactive debugging facilities for testing hardware and software.

The OBP (Open Boot PROM) program loads the bootblk(located on physical disk sectors 1 through 15) primary boot program from the boot-device. A copy of the bootblk is available at /usr/platform/`arch -k`/lib/fs/ufs/bootblk. The utility dd(1) is used to copy the bootblock to the specified disk partition. If the bootblk is not present or needs to be regenerated, it can be installed by running the installboot command after booting from a CDROM or the network.

Then the secondary boot program, /platform/`arch -k`/ufsboot is run. This program loads the kernel core image files. If this file is corrupted or missing, a bootblk: can't find the boot program or similar error message will be returned.

The kernel is loaded and run. For 32-bit Solaris systems, the relevant files are:

* /platform/`arch -k`/kernel/unix
* /kernel/genunix

For 64-bit Solaris systems, the files are:

* /platform/`arch -k`/kernel/sparcV9/unix
* /kernel/genunix

As part of the kernel loading process, the kernel banner is displayed to the screen. This includes the kernel version number (including patch level, if appropriate) and the copyright notice.

The kernel initializes itself and begins loading modules, reading the files with the ufsboot program until it has loaded enough modules to mount the root filesystem itself. At that point, ufsboot is unmapped and the kernel uses its own drivers. If the system complains about not being able to write to the root filesystem, it is stuck in this part of the boot process.

The boot -a command singlesteps through this portion of the boot process. This can be a useful diagnostic procedure if the kernel is not loading properly.
/etc/system: The /etc/system file is read by the kernel, and the system parameters are set.

Then the kernel is initialized. The kernel creates PID 0 ( sched) and starts PID 1 (init).The sched process is sometimes called the "swapper".

The init process reads the /etc/inittab and /etc/default/init and follows the instructions in those files.

Then the rc scripts execute the files in the /etc/rc#.d directories. They are run by the /sbin/rc# scripts, each of which corresponds to a run level.
A system's run level defines what services and resources ae available to users. A system can be in only one run level at a time.
Presently, Solaris environment has eight run levels.

Run level Init State Description
0 Power-down state Shut down the operating system to safely power off the system
1 Administrative state Allows accessing all available file systems with user login allowed.
2 Multiuser state For normal operations. Multiusers can access the system. All daemons are running except the NFS
server daemons.
3 Multiuser For normal operations with NFS resource sharing available
4 Alternative Multiuser state Currently unavailable
5 Power-down state To shut down the operating system to safely power it off
6 Reboot state To shutdown the system to run level 0 and to reboot
s or S Single-user state To run as a single user with all file systems mounted and accessible.

So thats is how Solaris boots after getting powered on. Please leave a comment if you want.