Scheduling Scripts and Logs

Introduction

Imagine you have a robot that cleans your house while you are asleep. Since you are sleeping, you can't see the robot working. When you wake up, how do you know if it actually cleaned, or if it got stuck under the sofa?

The answer is: You ask the robot to keep a Diary.

In Linux, automated scripts often run in the background or from schedulers where nobody is watching the terminal. That means screen output is not enough. To keep track of what happened, we write output to a log file instead.

This is one of the simplest but most valuable automation habits. A script without logs can fail silently. A script with logs leaves evidence.

In this lab, you will:

Divert Output: Teach a script to write to a file instead of the screen.
Add Integrity: Use the Append operator to add new entries without deleting old ones.
Add Timestamps: Ensure every diary entry has a date and time.

Append Output to a Log File

Standard scripts chirp their output to the screen immediately. This is like talking to someone face-to-face. But if no one is listening (which is the case for automated scripts), the words are lost forever.

We need to capture these words into a file. We will use the redirect operators.

This connects directly to an earlier shell idea: commands normally write to standard output, and redirection changes where that output goes. Logging is just a practical use of that same mechanism in automation.

> (Overwrite): "Erase the diary and start a new page." (Bad for history)
>> (Append): "Go to the next blank line and write there." (Good for history!)

Let's look at the simple script we have prepared:

cat myscript.sh

It just says "The script is running". If you run it now (./myscript.sh), it prints to the screen.

Let's change it to write to a diary called script.log.

Open the script:

nano myscript.sh

Change the line to use the >> operator. Pro Tip: When writing logs, always use the Absolute Path (full address), like /home/labex/project/script.log. This ensures the diary doesn't get lost in random folders if the script runs from a different location.

That absolute-path habit matters because scheduled jobs often run with a different working directory than the one you expect in an interactive shell. A script that writes to script.log with no path may create the file in the wrong place.

Your file should look like this:

#!/bin/bash
echo "The script is running" >> /home/labex/project/script.log

Save and Exit.

Now, run the script:

./myscript.sh

Silence.

The script ran, but it didn't say anything to you. It whispered into the diary instead.

Check the diary:

cat script.log

You should see the message safely stored inside.

Add Timestamps

A diary entry describing "What happened" is useless if it doesn't say "When it happened". If your script runs every day for a year, your log file will just have 365 identical lines saying "The script is running".

We need to add a timestamp. Linux has a command called date that prints the current time. We will redirect that into the log file too.

This is the beginning of observability: leaving enough evidence behind that a human can reconstruct what happened later. Even very simple timestamps dramatically improve your ability to troubleshoot automated jobs.

Open myscript.sh:

nano myscript.sh

Add the date command before the message. This way, the log will show the Time first, then the Action.

#!/bin/bash
date >> /home/labex/project/script.log
echo "The script is running" >> /home/labex/project/script.log

Save and Exit.

Run the script again:

./myscript.sh

Check the log:

cat script.log

Now you should see something like:

The script is running
Fri Oct 27 10:00:00 UTC 2023
The script is running

(The first line is from your previous test).

Now every action is stamped with a precise time. This is how you prove to your boss that the automated backup really did run at 3 AM!

In larger systems, logs also help answer harder questions such as whether a script ran twice, whether it stopped halfway, or how long it took between runs. Good logs turn invisible automation into something you can inspect.

Verify Log History

Let's test the "Append" theory. If we used > (overwrite) instead of >> (append), our log file would never grow; it would just effectively show the last run.

This distinction matters whenever a script runs repeatedly. Overwriting is useful for status snapshots, but appending is usually better for historical records because it preserves the sequence of events.

Let's simulate a busy day where the script runs multiple times.

Run it three times in a row:

./myscript.sh
./myscript.sh
./myscript.sh

Now, read the diary:

cat script.log

You should see a growing list of entries, each with its own timestamp. This history is invaluable when troubleshooting. If a server crashed yesterday, you can scroll back in the log to yesterday's timestamp and see exactly what the script was doing at that moment.

Summary

You have successfully taught your script to keep a diary.

In this lab, you learned:

Redirection (>>): Sending "speech" to a file so it isn't lost.
Appending: Adding to the history instead of erasing it.
Timestamping: Adding the date so you know when things happened.

This is the standard way all professional services work in Linux. Whether it's a web server or a database, they all write to log files exactly like you just did.