Understanding Deep Processes in Linux
Deep Processes in Linux
Let us study and understand some of the deep processs in linux .
Using text editors
The first step to independence on your system is learning how to use a text editor. Text editors are especially useful to the advanced user who wants to write scripts, new programs, and websites. A text editor is a productivity tool that will help you greatly. The text editors are usable both in graphical environment and in a terminal window. Additionally, mastering the text editor will allow you to use it on remote machines, which improves network speeds tremendously. Below are the most common editors.
Emacs is very popular on almost all UNIX based systems. It is extensible, self-documenting, customizable and the best real time display editor. It automatically updates the text edited on the screen as you type the command. What makes it real time is the fact that the display is in a constant state of update, in often case, at the stroke of each character. Most users refer to it as an advanced editor because it goes beyond providing the facilities of simple deletion and insertion. It can express comments in several programming languages, automate indentation of programs, control sub processes, edit formatted text, view multiple files at the same time etc. It is self-documenting, meaning that once you type any special character for example Ctrl+H, you can use it to find out the actions of the command or all topics pertaining to that topic.
Vim is an acronym for “Vi Improved”. It was previously “VIimitation”. The text editor contains almost all the commands in the UNIX command line and even a bit more. To enter commands in the Vim editor, you have to use a keyboard. Learning to use this text editor will be an advantage because it is the most common editor on all UNIX systems. It is also ideal for the beginner user because of the in-built menu help.
To generate, convert, manage, and generate Ssh keys, you can use the sshkeygen command. An Ssh key is a way of identifying trusted computers without using passwords. The ssh-keygen can create RSA usable on the Ssh protocol, version 1 and more.
Using Cron to schedule jobs
The most standard way to run tasks in the background is to use crone jobs. The program is valuable in automating tasks related to the machine such as maintenance. Cron is a background daemon program. The tasks scheduled run in a configuration file called cron tab.
Most of the distros have one form of cron preinstalled at default. However, in those instances where your distro does not have the cron installed, here is how you do it.
sudo apt-get update sudo apt-get install cron
For Cent OS/Red Hat Linux:
sudo yum update sudo yum install vixie-cron crontabs
Here is how to activate its background functions.
sudo/sbin/chkconfig crond on sudo/sbin/service crond start
For example, here is a task we want to run
5 * * * * curl http://www.google.com
While the syntax for the jobs we place on the crontab may at first glance look intimidating, but they are actually an easy-to-parse, succinct way of reading it if you know how to. Most of the commands (each command) are broken into two:
The command is any task, or otherwise, you would execute on the command line. On the other hand, the schedule part of the syntax is in five different options that you can use to schedule. They are in the following order:
MIN HOUR DOM MON DOW CMD
Here are a few examples to give you a clear picture of what we mean; you will encounter some of them as you work to configure cron.
To run a per minute command
Here is how to run a command for every 12th minute of each hour
12 * * * *
If you want to run a command every 15 minutes, you can use placeholders for different options.
0,15,30,45 * * * *
For running a command at 4 am every day, you would need to use
0 4 * * *
On the other hand, to run a command at 4 am every Tuesday, this is what you use
0 4 * * 2
You can also use division in the schedule. For instance, instead of using /listing 0, 15, 30, 45, you can substitute it with this
*/4 2-6 * * *
In the above range, the syntax will execute a command between 2-6 am.
Think of the scheduling syntax as your all-powerful magic wand that you can use for expression at any time you can imagine.
After you have decided what to run at a specific time (schedule), you have to place it in a place that makes it easier for your daemon to discover for reading. Even though there are a few places to place it, the user crontab is the most common. The crontab is the file that holds a schedule of jobs on cron. Each user has their own file located at var/spool/cron/crontab; the file should not be edited directly. To edit, use the crontab command. Here is the command that you require:
The above command calls up the text editor. You can use the text editor to input your job schedule. Each job should be in a new line. If you would like to view your crontab without editing it, use the command below:
Below is the command to erase the crontab
If you are a user with all the privileges of an admin, here is how you edit another user
crontab -u <user> -e
Unless you direct the output for every job executed into a log file, the output is sent via email to the user email attached to the cron job executed. Fortunately, you can specify which email to send the log file to by providing a “mail to” in the setting option at the top of the crontab. Additionally, you can specify which shell to run, home directory, and the cron binary search path by following the examples below.
Let us start by editing the crontab
This is how we shall edit it.
According to everything we have learnt so far, we know that this job will have the output of “execute (run) this command every minute”. Because we have specified the email “email@example.com”, the log file will be sent every minute to the email we have specified. This does not sound like an ideal situation (unless you want thousands of log files in your mail inbox). The better option would be to pipe the output file into an empty location.
Here is how you append a log file
* * * * * echo ‘Run this command every minute’ >> file.log
Another important factor to note here is that “ >> ” appends the file.
To pipe the file into an empty location, you can use /dev/null.
For example, this PHP script is executed and runs in the background
* * * * * /usr/bin/php/var/www/domain.com/backup.php > /dev/null 2>&1
You can also restrict access with cron in an easy way by using /etc/cron.alow and /etc/cron.deny.
To restrict or allow a user, you simply need to place their username in the user file, which is dependent on the access granted. The default settings in cron daemon assumes that all users can access cron i.e. unless the access files exist. For example, to give access to the user john and to deny access to all other users, this is the command you would use.
echo ALL >>/etc/cron.deny
echo john >>/etc/cron.allow
By using the appendix “ ALL ” , we lock out and deny all users to the file. On the other hand, we give the user access to execute jobs by appending the username.
If all the cron commands that we have looked at so far seem very hard, there are shorthand commands you can use to make your administration easier. Think of them as shortcuts.
Additionally, you can use @reboot, to run a command once at startup.
It is important to note that not all the cron daemons can construct this syntax and you should check for that before you rely on their operation.
In addition to what we have looked at, you can also have a job run at startup by editing your crontab file crontab –e and placing a line similar to the one below:
@reboot echo “System start up”