6 Reasons Your cron Job is Not Running

cron can be a real S.O.B. to setup if you’ve never scheduled a job before. The utility is downright nitpicky at times. Not to fear. If your cron job is not running, here are the top 6 most common hang ups you might be snagging on.

1.) Wrong environment

Your user account operates under a specific environment where you have a direct path to the programs and utilities you need. cron operates under a limited path and does not always have access to the same programs. Your PATH is one such environment variable that tells the shell where to look for executable programs. If you’re trying to use a program that isn’t in your path, the shell will return error. In the case of cron, your job will simply not run.

You can see if this is the case by comparing the cron environment to your user environment. Plug this small line of text into your crontab and take note of cron’s output in /tmp/path.txt

* * * * * env > /tmp/path.txt

Compare the contents of path.txt with your current environment and you will see a big difference in where cron searches for executables. Run the following command to see your current path.

echo $PATH

Solution – There are two things you can do in this case. The first involves using absolute paths in your script. This ensures cron has a complete path to the program you’re running:

/usr/app/command -x take-over-the-world-pinky

Alternatively, you can set your path at the top of your script like so:

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

This will give cron direct access to your program. Either way, you should be good to go.

2.) Your scripts aren’t owned by root

From the man page:

cron-man-page

If you’re placing scripts inside one of the /etc/cron.* directories, the scripts must be owned by root. If root does not own the script then cron will simply skip over it entirely. Many users choose to place scripts inside of these folders to bypass the finicky requirements of their own crontab. Rightly so, but even here you will find cron to be relentless with it’s requirements. Make sure your scripts are owned by root so things go smoothly.

3.) Your script names aren’t formatted properly

From the man page:

Once again, we see cron putting his foot down until the people around him fall in line with his unique perspective on reality. Your script cannot contain any special characters when placed into one of the /etc/cron.* directories. A common practice is appending your script with the .sh file extension. This is a no-no for cron. As you know, Linux does not require a file extension and your script will run just fine without one. Do what cron says and you will be a happy admin.

4.) Your cron script is not executable

An obvious one to some. Not so obvious to others. Your cron script must have executable permissions in order for cron to run it. Use the following command to make your script executable if it isn’t.

chmod +x /path/to/script

Executable scripts make cron very happy.

5.) Incorrect permissions

Permissions are a very common problem especially for commands placed in crontab. crontab runs under the permissions of the crontab user. If you don’t have proper permissions under your user, cron is not going to have the proper permissions either. Always run your script or command prior to scheduling them with cron. If your commands don’t run or error out with access denied errors, you know you need to make adjustments. If your script or command absolutely requires root permissions, then create a crontab as the root user of your system.

6.) cron daemon not running

The last and most insidious reason why cron is not working. I’ve racked my brain for hours trying to figure out why a cron script wasn’t working only to find out the daemon itself wasn’t even running. You can verify whether or not cron is running in a number of ways.

pgrep cron

cron is running if you see a number. cron is not running if you don’t.

cron-pgrep

service cron status

Easy way on Debian systems to check the status of cron.

check-cron-status

Conclusion

These are 6 of the most common reasons why your cron jobs are not running. Run through this list next time cron refuses to do what you tell him to. Eventually, cron will start to see things your way and will do as he’s told.

 

 

Linux cron job Tutorial

Cron is a Linux utility that lets you automate tasks on a schedule of your choosing. A Linux cron job is the perfect way to automate backups or other repetitive tasks. Cron comes with all versions of Linux and functions mostly the same across different distributions.

How cron works

Cron works by reading through a number of configurable text files and then reading commands into memory. Every minute the cron daemon crawls a special spool folder on the file system that contains a crontab for each user on the system. When cron runs across a crontab with a scheduled job it loads the job into memory.

Types of Linux cron jobs

There are 2 types of cron jobs. System wide jobs are cron jobs configured through /etc/cron and the directories /etc/cron.hourly /etc/cron.daily /etc/cron.weekly and /etc/cron.monthly These jobs are ran under the root account and have full access to the system. User jobs are cron jobs scheduled by standard user accounts and configured through crontabs. For security reasons it is recommended to schedule your jobs through your own crontab unless the task must be executed as root.

How to schedule a cron job

There are 2 ways to schedule a Linux cron job. The first is to simply drop a shell script into any of the directories mentioned below:

/etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

Shell scripts in these directories must be executable, owned by root, and adhere to a specific set of filename restrictions. From the man page:

As described above, the files under these directories have to be pass
some sanity checks including the following: be executable, be owned by
root, not be writable by group or other and, if symlinks, point to
files owned by root. Additionally, the file names must conform to the
filename requirements of run-parts: they must be entirely made up of
letters, digits and can only contain the special signs underscores
(‘_’) and hyphens (‘-‘).

The second way to schedule a cron job (and the preferred way) is to edit your users crontab:

crontab -e

This opens up the crontab for the currently logged in user. Here, all cron jobs scheduled will be executed under the user who created it. You will see a number of lines with the proper crontab format at the bottom. This is where you schedule your job. You can drop in a direct command to run or give the path of an executable shell script. Here are a few examples:

Note: cron uses a 24 hour clock ie military time.

Schedule a job to run once a day at 2:00am:

00 2 * * * /path/to/command

Schedule a job to run at the 1st of the month:

* * 1 * * /path/to/script

Schedule a job to wish the system a merry christmas:

* * 25 12 * echo “Merry Christmas Tux”

Clear the temp files once a week on Friday after everyone has left work:

01 17 * * 5 rm /temp/*

Make the appropriate edits and then save the file. Don’t worry about reloading or restarting cron. The daemon automatically checks for changes every minute.

Troubleshooting

Cron is drop dead simple once you understand the format. However, there are a few things that can hang up a cron job if you aren’t careful. Here are a few:

1.) Your scripts aren’t executable

All of your scripts must be executable in order for cron to run them. Go back and make sure all of your cron scripts have the +x permission configured.

2.) Your scripts aren’t owned by root

If you’re dropping your scripts into /etc/cron.hourly or any other cron folder, they must be owned by root or cron won’t run them. Make sure your scripts are owned by root and the proper permissions are set.

3.) Your scripts contain characters that aren’t allowed by cron

Similar to point number 2, your cron scripts won’t run in the /etc/cron.* folders unless they conform to a specific format. It’s usually a period that trips people up. Remove the period and your scripts will magically start running. Refer to the quoted man page above for more information.

4.) Wrong format

It’s easy to make a mistake in your crontab. You might think you’re running a script at one time but the format you gave cron doesn’t match up. Go back and make sure you have a clear grasp of the cron format and understand how to implement it into your crontab.

Conclusion

cron is a picky S.O.B but performs well once you can get him running. The nice thing is, once you have cron configured it will run like a well oiled machine for the rest of your days. Let me know what you think about cron in the comments below.

 

 

 

Crontab Format Explained

Cron is a built in Linux utility that allows you to schedule jobs called cron jobs. You can schedule cron jobs to run hourly, daily, weekly, monthly, yearly or any sort of variation in between. Cron is configured through a specialized text interface called the crontab. The problem is that the Crontab format is a little confusing until you become acclimated to scheduling out jobs. Let’s take a look:

* * * * * /path/to command

Each * represents a time slot. Using the table below you can see that each * represents varying measurements of time:

*****
MinuteHourDay of the month (1-31)Month (1-12)Day of the week (0 - 6 where 0 = Sunday)

crontab format examples

Note: cron uses a 24 hour clock ie military time.

Schedule a job to run once a day at 2:00am:

00 2 * * * /path/to/command

Schedule a job to run at the 1st of the month:

* * 1 * * /path/to/command

Schedule a job to wish the system a merry christmas:

* * 25 12 * echo “Merry Christmas Tux”

Clear the temp files once a week on Friday after everyone has left work:

01 17 * * 5 rm /temp/*

Conclusion

Is it all coming together now? Practice some examples of your own to really get the hang of it. Pretty soon you will be using anything as an excuse to bust out your crontab for a quick scheduling. Let me know in the comments if you need help.

 

Samba File Sharing Configuration and Tutorial

Samba file sharing allows a competent system administrator to configure a Windows-like network share on a Linux system. These shares are accessible by Windows computers and other SMB clients. Samba is software that makes it easy to exchange data with Windows operating systems.

What is Samba?

Samba is free software for Linux that implements SMB like functionality into the system. SMB is the dominant file sharing protocol used on Windows systems. By recreating this functionality, Linux systems can integrate into a Windows environment and function as both a client and/or a server. The software includes a dozen core services to make this possible.

Samba file sharing HOWTO

In this samba file sharing tutorial I will show you how to setup a Samba share with basic user access controls. You will learn to share a folder with read/write access and grant permissions to select users on the network. A mapped network drive on the Windows machine will serve as easy access to the Samba share.

This is a basic process that involves installing the Samba file sharing software and making a few configuration changes to the configuration file.

Installing Samba

Samba may or may not be installed on your system. Here are a few ways to install the software on various Linux distributions.

Debian/Ubuntu

apt-get install samba

CentOS

yum install samba samba-client samba-common

Arch

pacman -S samba

By default, the Samba configuration file is located at /etc/samba/smb.conf and comes extremely bloated. I always delete the contents and start fresh with only the configuration directives I require. If this scares you, make a backup of smb.conf first:

cp /etc/samba/smb.conf /etc/samba/smb.bak

The following configuration file will grant your username full access to your home directory on your Linux box. Copy and paste the contents below straight into the smb.conf configuration file. Be sure to substitute your own parameters on each line.

[global]

# Copy this into your /etc/samba/smb.conf configuration file

workgroup = WORKGROUP
netbios name = SAMBA
security = User

[data]
path = /home/user/
valid users = username
read only = no
create mask = 0777

There are a few parameters here worth mentioning.

workgroup should be the same name as the workgroup your Windows machine is on. The default Windows workgroup is called WORKGROUP, conveniently enough. You can verify this by going into your system properties.

netbios name is the name your Linux box will present to the network. Essentially, this is the name that will show up when you browse the network for connected hosts.

security is a setting used to determine how a particular share is accessed. In this case, we only want to grant permission to users that exist on the Linux system.

[data] is the name we are specifying for the share.

path is the absolute path of the folder we want to share to the network

valid users specifies what users should have access to this share. All other users not on this list will be denied access.

read only = no makes this share writeable by the users.

create mask sets the default permissions for this share. In this case, we grant full permissions to the owner of the files while completely denying permission to everyone else.

That’s all there is to it. Save the configuration file and then reload the Samba configuration:

service samba reload

The last thing we need to do is create a special Samba password for your user:

smbpasswd -a user

Your share should now be accessible from any Windows machine on the network. You can access the share by specifying the UNC or by browsing the network via Windows Explorer. Double clicking the share will prompt for a username and password. Plug in the credentials of your Linux user and click OK.

samba-file-sharing

Once logged in you will see the share you set up in the Samba configuration:

samba-configuration

Nice!

Troubleshooting

Problems with Samba are usually caused by incorrect configuration settings, permissions, or service related issues. A good starting point if you’re having problems connecting to your server is to check the Samba service status:

service samba status

Is the service running? If not, you’ll have to find out why.

Next, make sure there are no typos in your Samba configuration file. A single typo can throw off the whole server. Comb through your /etc/samba/smb.conf and make sure all your directives are correct.

Access denied problems can crop up if your permissions aren’t set correctly or you failed to set an smbpasswd for your Linux user account. Make sure the account you specify in the Samba configuration is active on the system and that you created an SMB password for the user. Re read the sections above for instructions.

Conclusion

Samba file sharing makes it easy to exchange data in a Windows dominant environment. You can see how easy this was to quickly get a file server up and running. Once again, Linux proves itself to be a very capable server operating system. Best of all, the software is free! This tutorial covered a very small aspect of Samba. If you’d like to learn more about Samba and its full capabilities, check out the official documentation or run through the man page.

 

Ultimate List of Beginner Linux Commands With Examples

New to Linux? Maybe you’re looking to switch to Linux full time or learning how to operate a VPS. Below I have compiled a list of beginner Linux commands with examples to get you started. These commands will lay the foundation required to use the Linux system in more advanced ways. Let’s get started.

pwd

Print working directory. This command lists where you are in the file system. The top of the Linux file system starts with / and then branches out like a tree from there. The pwd command is useful when you have no idea where you are on the system.

linux commands with examples

cd

Change directories. The same as clicking through your folders on a Mac or Windows machine. This command works with both relative and absolute paths.

cd-linux-command

ls

Lists files in a directory. Exactly the same as opening up a folder on Mac or Windows and seeing all the files. By itself, the command will list all the files in the current directory. You can also list the contents of a relative or absolute path.

ls-linux-command

Notable Parameters Description
-aLists all files including hidden ones
-lLong listing. Includes additional info like permissions and timestamps

cp

You are familiar with the traditional way of copying files on a GUI (graphical user interface.) This typically involves dragging files from one window to another or executing a right click copy/paste. Using the cp command you can execute the same process a lot faster. Here we copy the “file1” file from the current directory into the /home/2cf/documents directory.

cd-linux-command

Notable Parameters Description
-rCopy in recursive mode (copy both files AND directories)

mkdir

Creates a folder in the current or supplied directory

mkdir-linux-command

Notable Parameters Description
-pCreate the parent directories if they don't exist

rm 

Removes a file when used by itself and deletes directories when used with the -r switch. Be careful with this one. You don’t want to accidentally delete any important files!

rm-linux-command

Notable Parameters Description
-rRemove directory

mv

Move or rename files. In the example below, we rename “documents” to “mydocuments”

mv-linux-command

file

determines the file type of a file. Very useful for identifying cryptic files on a Linux system. As you explore Linux you will come across files of mysterious types. Use the file command to expand your knowledge of these files.

file-linux-command

cat

concatenates files and displays their output. In other words, the cat command reads the contents of a file right onto your terminal. This is a quick way to read a file without actually opening it in an editor.

cat-linux-command

clear

Clears the terminal screen. All the output on the terminal can become overwhelming and confusing. Use the clear command to wipe the slate clean! Note that clear doesn’t actually delete anything. It simply clears the output generated by any commands you have ran.

clear

whoami

Prints the user currently logged in to the system. Not sure who’s account you are using? You can always verify the current operator with the whoami command.

whoami-linux-command

man

man is an interface to the Linux manual. The manual contains complete information on every command and utility available on the Linux system. If you are wondering what a certain command does you can read the manual. In the old days when n00bs asked the veterans about a particular command, they were instructed to RTFM – Read the F’n manual! They were, of course, speaking of the man command.

man-linux-command

reboot

Reboots the system.

reboot

shutdown

Brings the system down. When used without any parameters, the default action is to bring the system down into single user mode (run-level 1) immediately.  This mode logs off any users currently logged into the system and prevents them from logging in. To execute a full system power down, you must use the -h option and specify a time:

shutdown -h now

Time can also be specified with a +n where “n” is the minutes before you want the system to shutdown. Here we tell the system to execute a full power down in 5 minutes.

shutdown -h +5

Conclusion

Becoming familiar with these commands is a great start to learning how to use the Linux system. You now have everything you need to manipulate files, navigate the file system, and do some basic system administration tasks. Best of all, you have the man command. All of these commands have advanced options that I did not cover in this beginners guide. Using man, you can dive deep into the commands that interest you and learn more.

 

rsync over SSH: backup your data securely

Using rsync over ssh is a secure method to backup your system. SSH encrypts your data over the internet and secures the transmission from hackers and other threats. The good news is that rsync uses the SSH protocol by default. In this tutorial I will show you how to use rsync over SSH and how to conifgure SSH keys for passwordless backups.

rsync over SSH requirements

  • SSH access to server
  • rsync client installed locally

Installing rsync

In most cases rsync will already be installed on your system. If it’s not, it can be easily installed.

Debian/Ubuntu

sudo apt-get install rsync

CentOS

sudo yum install rsync

Testing the connection

Test the connection to your server by connecting with SSH:

ssh user@remotehost.com

If all goes well you should be greeted by a password prompt:

Testing rsync

If you can connect with SSH you can connect with rsync over ssh. Test rsync by initiating a dry run backup of your home directory:

rsync -nav user@remotehost:~/ /path/to/local/backup/folder/

With any luck you will see your files and folders fly by the screen. Note that we did not have to use the -e switch. Since rsync uses SSH by default this is not necessary unless you need to specifiy additional connection parameters (non-standard port or SSH key locations.)

Setting up SSH keys

We can setup SSH keys so rsync doesn’t need a password to connect. This is useful for automating your backups with chron while staying completely secure. SSH keys are generated on your local computer and then copied to the remote host. Generate a key pair with the following command:

ssh-keygen -t rsa

Save the keys in the default location or specify another directory:

Enter file in which to save the key (/home/demo/.ssh/id_rsa):


Leave the passphrase blank by hitting enter through the following prompt:

Enter passphrase (empty for no passphrase):

Here is what you should see:

Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 user@a
The key's randomart image is:
+--[ RSA 2048]----+
|          .oo.   |
|         .  o.E  |
|        + .  o   |
|     . = = .     |
|      = S = .    |
|     o + = +     |
|      . o + o .  |
|           . o   |
|                 |
+-----------------+

While it would be more secure to enter a passphrase, rsync can’t be automated in this way. However, this method is still secure because a hacker would need to obtain your private key to gain access to the server.

Next we copy the public key to the server. Security tip: Never grant your keys to the root account. Always copy your keys to a standard user account. This way if a hacker jacks your private key he would only have limited access to your box.

ssh-copy-id user@remotehost.com

If prompted, type yes to connect and then enter your password to complete the transfer:

The authenticity of host '12.34.56.78 (12.34.56.78)' can't be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '12.34.56.78' (RSA) to the list of known hosts.
user@12.34.56.78's password: 
Now try logging into the machine, with "ssh 'user@12.34.56.78'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Boom goes the dynamite. You should now be able to run rsync over ssh without a password.

Resources

http://linux.die.net/man/1/rsync