Aborting Execution of jobs in Linux / Unix

To terminate a program from a character-based display, press the interrupt key (CONTROL-C or sometimes DELETE or DEL). When you press this key, the Linux operating system sends a terminal interrupt signal both to the program you are running and to the shell. Exactly what effect this signal has depends on the program. Some programs stop execution immediately; others ignore the signal. Some programs take other actions. When it receives a terminal interrupt signal, the shell displays a prompt and waits for another command.

If these methods do not terminate the program, try stopping the program with the suspend key (typically CONTROL-Z), giving the jobs command to verify the job number of the program, and using kill to abort the program. The job number is the number within the brackets at the left end of the line that jobs displays ([1]). The kill command sends a signal to the job specified as its argument. You must precede the job number with a percent sign (%1):

$ bigjob
^Z
[1]+  Stopped                 bigjob

$ jobs
[1]+  Stopped                 bigjob

$ kill %1
[1]+  Stopped                 bigjob

$ RETURN
[1]+  Killed                  bigjob

By default kill sends a software termination signal (–TERM). When this signal does not work, try using a kill (–KILL) signal:

$ kill -KILL %1

A running program cannot ignore a kill signal—it is sure to abort the program. The kill command returns a prompt; press RETURN again to see the confirmation message.

What are emulators for Linux?

Linux supports programs, called emulators, that run code intended for other operating systems. By using emulators you can run some DOS, Windows, and Macintosh programs under Linux. Wine (www.winehq.com) is an open-source implementation of the Windows API on top of X and UNIX/Linux; QEMU (fabrice.bellard.free.fr/qemu) is a CPU-only emulator that executes x86 Linux binaries on non-x86 Linux systems.

What do GNU stands for?

GNU, which stands for Gnu's Not UNIX, is the name for the complete UNIX-compatible software system which I am writing so that I can give it away free to everyone who can use it.

List of Environment variables in Linux

Variable name	Stored information
DISPLAY	used by the X Window system to identify the display server
DOMAIN	domain name
EDITOR	stores your favorite line editor
HISTSIZE	size of the shell history file in number of lines
HOME	path to your home directory
HOSTNAME	local host name
INPUTRC	location of definition file for input devices such as keyboard
LANG	preferred language
LD_LIBRARY_PATH	paths to search for libraries
LOGNAME	login name
MAIL	location of your incoming mail folder
MANPATH	paths to search for man pages
OS	string describing the operating system
OSTYPE	more information about version etc.
PAGER	used by programs like man which need to know what to do in case output is more than one terminal window.
PATH	search paths for commands
PS1	primary prompt
PS2	secondary prompt
PWD	present working directory
SHELL	current shell
TERM	terminal type
UID	user ID
USER(NAME)	user name
VISUAL	your favorite full-screen editor
XENVIRONMENT	location of your personal settings for X behavior
XFILESEARCHPATH	paths to search for graphical libraries

Which shell am I using?

 

To find out which shell you are currently using, type the following command:

echo $SHELL

The result of that command will tell you what your current shell is and may look something like:

/bin/bash

That would mean that you are using the bash shell. On a side note, you would also realise that this shell resides in the bin directory.

Preserve permissions and ownership when copying files using cp

We use the -p flag to tell cp to preserve the permissions and ownership of the files involved. So if we wanted to copy a folder recursively preserving permissions and ownership of the folder and the files contained in it, we would use the following command (preferably as root):

cp -R -p /source/folder/ /destination/folder/

All the files in the source folder would be copied to the destination folder and the permissions and owners would be preserved.

If we had a single file it would be similar:

cp -p /path/to/file-a /path/to/file-b

To check that the owner and permissions have been preserved, we can simply use:

ls -altp /destination/folder/

The result of the above command would show us the permissions that the files in the destination folder have.

AutoSys Scheduler: Create & Manage Jobs using AutoSys Job Scheduler

AutoSys is used for defining, scheduling and monitoring jobs. These jobs can be a UNIX script, java program or any other program which can be invoked from shell. Before starting we assume that user has already setup an AutoSys environment. This environment consists of autosys server and autosys client.

AutoSys System components

1. Event server (AutoSys database)
2. Event processor
3. Remote agent

Event Server

The event server is a AutoSys database which stores all system information and events as well as all job, monitor, and report definitions. Sometimes this database is also called as a data server, which actually describes a server instance. That is, it is either a UNIX or Windows process, and it is associated data space (or raw disk storage), that can include multiple databases or tablespaces.

Event Processor

This is main component of the autosys system. This processes all the events it reads from dataserver. The event processor is the program, running either as a UNIX process or as a Windows service that actually runs AutoSys. It schedules and starts jobs. When you start the event processor it continually scans the database for events to be processed. When it finds one, it checks whether the event satisfies the starting conditions for any job in the database.

Remote Agent

On a UNIX machine, the remote agent is a temporary process started by the event processor to perform a specific task on a remote (client) machine. On a Windows machine, the remote agent is a Windows service running on a remote (client) machine that is directed by the event processor to perform specific tasks.
The remote agent starts the command specified for a given job, sends running and completion information about a task to the event server, then exits. If the remote agent is unable to transfer the information, it waits and tries again until it can successfully communicate with the database.

Basic functionality of AutoSys

Below is the diagram which explains the basic functionality, please check the explanation.

Explanation

1. The event processor scans the event server for the next event to process. If no event is ready, the event processor scans again in five seconds.
2. The event processor reads from the event server that an event is ready. If the event is a STARTJOB event, the job definition and attributes are retrieved from the Event Server, including the command and the pointer (full path name on the client machine) to the profile file to be used for the job. In addition, for jobs running on Windows machines, the event processor retrieves from the database the user IDs and passwords required to run the job on the client machine.
3. The event processor processes the event. If the event is a STARTJOB, the event processor attempts to establish a connection with the remote agent on the client machine, and passes the job attributes to the client machine.
The event processor sends a CHANGE_STATUS event marking in the event server that the job is in STARTING state.
4. On a UNIX machine, the inetd invokes the remote agent. On a Windows machine, the remote agent logs onto the machine as the user defined as the job’s owner, using the user IDs and passwords passed to it from the event processor.
5. The remote agent sends an acknowledgment back to the event processor indicating that it has received the job parameters. The socket connection is terminated. At this point, the event processor resumes scanning the event server database, looking for events to process.
6. The remote agent starts a process and executes the command in the job definition.
7. The remote agent issues a CHANGE_STATUS event marking in the event server that the job is in RUNNING state.
8. The client job process runs to completion, then returns an exit code to the remote agent and quits.

Defining autosys job

There are various parameters to define autosys job. Starting from profile, timezone, start time, starting condition and so on. There are the two methods you can use to create job definitions:
1. Using the AutoSys Graphical User Interface (GUI).
2. Using the AutoSys Job Information Language (JIL) through a command-line interface.
In this tutorial we will use JIL language to create autosys jobs.
JIL stands for Job Information Language. Using this you can instruct autosys to save job definitions. This information saved in autosys database. You can also create a jil file which contains job definition. You can then pass this jil file to autosys.
Essential attributes for defining job
1. Job Name
JIL Keyword : insert_job. Name used to identify the job.
2. Job Type
a. JIL Keyword : job_type. The job type is one of job types: command (c), file watcher (f) or box (b).
3. Owner
a. JIL Keyword : owner
The job owner specifies whose user ID the command will be run under on the client machine. This attribute is automatically set to the user who invoked jil or the GUI to define the job, and cannot be changed except by the edit superuser.
Other job attributes:
1. command: The command attribute can be the name of any command, executable, UNIX shell script or batch file, and its arguments.
2. machine: This attribute specifies the client machine on which the command should be run.
3. date_condition: The start date/time dependencies attribute is a toggle, which specifies whether or not there are date, time, or both, conditions required for starting the job.
4. days_of_week: The days of the week attribute specifies the days on which the job should be run.
Sample jil file for command job echoJob.jil

insert_job:echoJob

machine:unixMachine

owner:username

command:echo “Hello this is command job”

 

To add this job in atosys db. Run following command from unix:

jil < echoJob.jil

 

Commands to control the job

Start job command

sendevent –E FORCE_STARTJOB -J <job_name>

 

sendevent -E STARTJOB -J <job_name>

 

To put jobs on OFF ICE or ON ICE

sendevent -E OFF_ICE -J <job_name>

 

sendevent -E ON_ICE -J <job_name>

 

sendevent -E KILLJOB –J "Job Name Here"