Cron Jobs

Take routine maintenance or other repetitive tasks off your plate by automating them as cron jobs. Cron jobs run on a schedule that you set with one command. You use SSH access to set jobs on a per container basis.

How to Schedule and Manage Cron Jobs

To begin, you’ll need to have an SSH/SFTP user linked to the container that you want to work with. Once that’s done, the process is very straightforward.

1. SSH into the relevant container.
2. Change into the containers/crontabs/ directory.
3. Edit the crontab file to add or change jobs. Note that the operating system timezone is UTC (0).
4. Leave an empty line at the end of the file.
5. Save the file.

You might need to wait a minute or so for the file to be processed.

To edit the file through an SSH session you can use this command: nano /container/crontabs/crontab

Cron Job Format

Each line of your crontab file represents a job. The first five fields define the timing or scheduling rules, followed by the shell command to be executed.

If you’re new to this, or need a refresher, Wikipedia’s cron article is a good place to start. Another handy resource, Crontab Guru, lets you quickly check that your scheduling will work the way you want it to.

User www-data

Cron jobs are executed as the user www-data (uid: 33). This user should have access to all files and directories within the /container directory, except the /container/backup/containers directory.

Using Environment Variables in Cron Jobs

You can modify the crom command to use environment variables in your scheduled jobs. The modified command exports environment variables, pushing them to a place where the cron command can use it.

There are multiple ways to pass environment variables to cron jobs. We’ll start with the simplest.

Caution

The configuration changes below will provide all of your environment variables, including any sensitive information, to cron jobs.

To edit the necessary config file, use this command:

nano /container/config/supervisord.conf

Find the section that looks like this:

[program:cron]
command=/bin/bash -c "touch /etc/crontab && cron -f"

Change it to look like this:

[program:cron]
command=/bin/bash -c "touch /etc/crontab && printenv >> /etc/environment && cron -f"

As with any changes to config files, you’ll need to restart the container for them to take effect.

This will push all the environment variables into the /etc/environment file, which will allow the cronjobs to use the environment variables.

Special Characters or Specific Environment Variables

Use the below line if you require special characters, or only want a certain cron jobs to use these environment variables:

* * * * * export $(cat [/path/to/environment/variables] | xargs) && [your cronjob here]

Or for cron specific environment variables, add them directly to file /container/crontabs/crontab.

MYVAR=VALUE

Troubleshooting

When cron jobs aren’t working properly, there are a few quick checks that can help.

Three things to double-check in the crontab file itself:

• Ensure your crontab file is in the UNIX text file format. This is especially important for Windows users. We would recommend editing the crontab file via SSH using nano or vim text editors.
• Make sure that you have an empty new line at the end of the file.
• Add a MAILTO variable to the first line. When tasks are processed, you’ll be emailed the outputs of the commands that have been run. If there’s no output, there will be no email.

Or, elsewhere:

• SSH into the container and run the task manually through the command line. This lets you see whether the job is working like it should.
• Check the /container/logs/rsyslog/syslog log file. If your crontab file is being processed, you will see: CRON[XX]: (root) CMD (/bin/cat /cron/crontab | /usr/bin/crontab -u www-data -)

Mapping From Your SSH Connection to the Container

To make Webslice Containers as generic as possible, we made some choices that mean the mapping of the directory differs from what you can see in your SSH session.

If you want to execute files under the /application directory, or to write to a log file, consider using /container/ instead of the paths you can see when connected via SSH.

Path to use (SSH)	Equivalent path
/container/application	/data/docker_app
/container/logs	/var/log/docker_app
/container/config	/etc/docker_app