How to automate tasks on a Linux system

Discussion in 'Intermediate Tutorials' started by Rob, Jul 9, 2013.

  1. Rob

    Rob Administrator Staff Member

    Messages:
    573
    Likes Received:
    198
    Trophy Points:
    43
    You don't have to do that yourself!One of the main tasks of a system administrator is carrying out maintenance work on the server. Most of these tasks can be automated or programmed to be carried out at certain times without user intervention. In this section we'll talk about the two most widely used programs to carry out tasks in this way.

    Use of 'at'

    'at' is a program to carry out commands that you intend to do only once. It's mostly used for scheduling specific jobs under specific circumstances. If you had to rotate your company's webserver logs every Saturday, 'at' is not the appropriate tool for the job. That would be done best with 'cron', about which we will talk about shortly. Let say your boss, the CTO, called for a meeting with you at 1:00. He wants to know how frequently your external consultants are logging into the network. This is a prime candidate for 'at'.

    First, you'd type:

    Code:
    at 12:45
    which would give you plenty of time to get that information before the meeting. You will see the 'at' prompt:

    warning: commands will be executed using /bin/sh
    Code:
    at >
    Now you'd write the commands you want carried out. Here we'll get the output of the command last, which tells us who's logged in to our servers lately, and write it to a file called 'log-ins'. The second command, separated by a semi-colon (;) will then print that file using lp.

    Code:
    last > $HOME/log-ins; lp $HOME/log-ins
    press 'Enter' and then 'Ctl + d' and you will see the following:

    job 15 at 2003-02-16 12:45
    Of course, your job number will vary with the number of times you've used 'at'.

    There are various ways to indicate at what time you want 'at' to carry out commands. at now + 5 minutes will carry out a command five minutes from when you type it. There's even a provision for at teatime which will carry out commands at 4:00 PM/16:00 hrs. (If you don't believe me, consult 'man at'!). You can cancel these jobs as well. If you type:

    Code:
    atrm 15
    you will remove job 15 from the 'at' queue. To see what is in the 'at' queue, type:

    Code:
    atq
    You can control which users are allowed to use 'at'. By default /etc/at.deny controls who cannot use 'at'. That is to say, the users listed in at.deny cannot use it. You can also create an /etc/at.allow file. Creating at.allow makes the at daemon ignore the /etc/at.deny

    Therefore, anyone who is not in at.allow cannot use 'at'. The question of using one file or another comes down to a question of your management style. If you prefer to let people use things until the abuse the privilege, then use the default at.deny. When the user 'barney' programs an 'at' job to set off an infernal sounding noise when he's gone to get coffee, scaring the bejeebers out of everybody in the office, then you can add him to the at.deny file. If you're of the opinion that nobody needs to use it, then create an at.allow file with only your personal user account listed. Remember that the root user can always use at.

    Use of 'cron'

    From a system administrator's point of view, the cron daemon is probably the best thing since sliced bread. You can schedule practically any program (provided that they don't have a graphic user interface since cron is not really designed to run GUI applications) at any time, for any date and at any interval. That is to say, if you want a text dump of the number of times a person with the IP address 64.09.200.12 has logged into your computer and you only want it on February 4th, cron will do this for you.

    The jobs that you want to run with cron can be scheduled in various ways. The most common way is to edit a file which is known as your crontab. Normally, each user has his/her own and is able to schedule jobs by editing it. You can add to and delete entries from you crontab by typing:


    Code:
    crontab -e
    But before we go jumping right into scheduling jobs, it's important to point out that cron looks for a particular syntax in your crontab file. You just can't just write:

    get my mail from mail.mydomain.com
    and expect it to work. The syntax in your crontab is not easy to master, but it is not excessively difficult to comprehend either. First, there are 5 time periods that cron looks for. You start your crontab entry with these. Here is the order and some examples:

    Table 1. Guide to Cron times
    cron-article.png

    You will not be able to use all of them at the same time. If you have used the first four, you do not need the last one. This last one, the weekday, is particularly useful because it lets you run jobs once a week. There is also another way of doing that and we'll talk about it shortly. If you don't wish to specify a particular time period, you must substitute an asterisk (*).

    Once you have decided when you want a particular command to be run, you add the command itself at the end. Thus, a typical crontab entry will end up looking like this:

    Code:
    30 3 * * 0 $HOME/bkup_script
    which runs a script in your home directory to back up your files at 3:30 AM on Sunday. If you entered this into your crontab, you would simply save the file by pressing ESC + :wq which is a vi command. Vi is normally the editor that crontab uses by default, but you may use a text editor other than vi, by typing export VISUAL=pico, for example, which would allow you to use the pico editor. Every time you want to alter, add or delete an entry, you would first type

    Code:
    crontab -e
    Enter whatever it is that you want to get done and then type

    ESC + :wq
    (or the combination of keys used to save a file in your particular text editor of choice). If you're curious about what's in your crontab file and want to list the jobs you have programmed, type:

    Code:
    crontab -l
    If you want to delete your crontab file, type

    Code:
    crontab  -r
    Variations on a theme

    Crontab entries don't have to necessarily have just numbers in them. We can combine the numbers with other characters to modify how commands get carried out. For example, I have a USB webcam that doesn't really do what it's supposed to, which is to take a picture every minute and then shut off. It takes the picture all right, but it doesn't shut off. So I wrote a script to shut it off and then I added a crontab entry to call this script every minute. This is what I added:

    Code:
    0-59/1 * * * *  $HOME/shutoff_cam >/dev/null 2>&1
    Let's look at this one part at a time

    0-59/1
    basically means that between the 0-59 minutes of every hour, at every 1 minute interval, the camera is to shut off. To show you how useful cron is, I remember seeing a James Bond movie where the perpetual bad-guy, Blofeld, was brainwashing girls to carry out biological attacks from a base in the Swiss Alps. He would play these hypnotic tapes to the girls every evening. There is one scene where you see Blofeld and one of his minions switching the tapes manually. If only they had had a Linux computer! They could have done this:

    Code:
    30-45/3 22 * * *  mpg123 /home/esblofeld/brainwash_girls.mp3 >/dev/null 2>&1
    which would play the brain-washing instructions at 3 minute intervals between 10:30 and 10:45 PM.

    Disclaimer: PLEASE DO NOT TRY BRAINWASHING TECHNIQUES AT HOME! ALSO, LINUX ONLINE DOES NOT ENDORSE THE WORLD DOMINATION SCHEMES OF SPECTRE. THIS IS ONLY USED AS AN EXAMPLE. THE ONLY WORLD DOMINATION SCHEME WE ENDORSE IS THAT OF LINUS TORVALDS.

    We should also point out something that you've probably already noticed in the two examples above; that they end with

    command >/dev/null 2>&1
    We tacked this on the end because cron, by default, mails a "report" to you of the command you carried out. This is so you can either get the output directly in the mail, and/or to see if the command was successful. You may have made a mistake when you added an entry to your crontab (like typing the wrong path or the name of a command wrong). That way, you're notified and even if your job was important and you missed the first one, you can correct it and then you won't miss any others. Again, in the examples above, if we got a mail every time the command was carried out (every minute or couple of minutes), your in-box would quickly fill up with useless mail. Therefore, we tack that on so that cron will send notification of those jobs to /dev/null (ie. the trash).

    Here are some other examples of variations:

    Code:
    0 0 15,30 * * cat /var/log/mysql.log > $HOME/mysql_use
    30 8 * * 1-5 /usr/bin/who

    The first one makes use of the comma, which means 'and'. In the first example, we see that we will get a report of MySQL use on the 15th and 30th of every month (except February, of course!). The second one will run 'who' which tell us who is logged in, every weekday (1-5) at 8:30 AM. This would be a particularly good one for systems administrators who want to see who's working (or at least who's logged-in) at the time they also start work.

    Permissions for cronThe ability to use cron is regulated in the same way as 'at'. Those in /etc/cron.deny are not allowed to use cron and all other users are allowed. If you have a /etc/cron.allow file, this supersedes cron.deny (ie, cron.deny is ignored) and allows only those listed in it to use cron.

    cron.hourly, cron.daily and cron.monthly

    Most Linux distributions have three directories in /etc called cron.hourly, cron.daily andcron.monthly, which, as you may have already guessed, lets the systems administrator run jobs on an hourly, daily or monthly basis. Simply by placing a shell script here, jobs can be carried out at those intervals. There is no need to have a crontab entry for these jobs.

    As you can see, the sky is the limit with the things that you can do with cron. It won't get you to the point where you've programmed absolutely everything, letting you pass your working hours at the beach, but it will make your life a whole lot simpler.
  2. mikemazz

    mikemazz New Member

    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Rob,

    Very well written piece on cron. I'm a longtime sysadmin and systems programmer. However, I now own my own company that makes cross-platform IT automation software, which can virtually automation any business critical process. We even import cron tabs for those people who need to move from cron to a more sophisticated system.
    Cron is nice tool out of the box. Again, you did great job of demonstrating its usefulness here.

    Thanks
    Mike
  3. JohnSerrano

    JohnSerrano New Member

    Messages:
    10
    Likes Received:
    3
    Trophy Points:
    3
    very much informative it has been to me to go throguh such a well organised read .. am getting the help and appreciate sharing it with us
  4. cnnx

    cnnx New Member

    Messages:
    8
    Likes Received:
    3
    Trophy Points:
    3
    Are all cron schedulers the same? For example on gentoo I use the vixie-cron package, was wondering if other packages have differences or if its pretty much standard.
  5. ZHANG/ZHIKUN

    ZHANG/ZHIKUN New Member

    Messages:
    14
    Likes Received:
    2
    Trophy Points:
    3
    at and cron have bothered me long.I know the problem after reading this post. THANK.
  6. mikemazz

    mikemazz New Member

    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Yes, for the most part all cron packages are based on Paul Vixie's implementation. There are a few revision with the last one adding a 6th field to the crontab entry.

Share This Page