Friday Superboss: Architecting Event-Driven Automation (No Cron!)

[TudorRaduta]

Make Linux react the instant a file appears

Happy Friday! Last week we built a secure directory. Today, we are going one level deeper - we are going to make that directory react on its own.

This is a "Superboss" challenge because it pushes you beyond basic RHCSA tasks and into modern systems engineering. We are still in the objective "Deploy, configure, and maintain systems", but this time with a real-world twist.

Most people use cron for automation. But cron has one big flaw: it waits. If your job runs every minute, a user might wait 59 seconds before anything happens.

Today you will design an event-driven system that reacts the instant a file appears.

The Scenario: The "Hot Folder"

You manage a shared directory: /srv/uploads. Users from Windows (Samba) and Linux (SCP/SFTP) drop raw image files in it constantly.

Your architecture must support:

1. Instant reaction: As soon as a file appears, the system detects it.
2. Immediate action: It triggers a script at /usr/local/bin/process_images.sh.
3. No Cron allowed: You must use systemd.path units - the kernel-level event watcher.

️ The Map:

You will be using deeper systemd features today. Your guides:

• man systemd.path - your secret weapon
• man systemd.service
• man systemd.unit

Your Architect Challenge:

To build this, you must create two linked units. Share your configuration in the comments.

Step 1: The Worker (Service)

The service file hotfolder.service runs your script.

1. What does the [Service] section look like?
2. Why does this service not need an [Install] section?

Step 2: The Watcher (Path Unit)

The path file hotfolder.path detects file changes.

1. Which option will you use in the [Path] section to watch for new or changed files in /srv/uploads - PathChanged= or PathModified=?
2. How does this Path unit know which Service unit to trigger when it sees a file?

Step 3: Activation

1. Which unit do you run with systemctl enable --now to start the monitoring?

Let’s see your unit files.

[Trevor]

Aw Tudor, by your providing the ingredients, all that was left for us to do was 
to add water and stir   Well, here goes.

Step 1: The Worker (Service)

The service file hotfolder.service runs your script.  I know the assignment is making
reference to the .service unit file running a script, but I'm going to deviate from that, and
have my actual alerts executed from within the .service unit file itself.  Due to the 
of my submission, I want to do something to make up for the point deductions

1. What does the [Service] section look like?

[Service]
Type=oneshot
ExecStart=/usr/bin/bash -c 'mail -s "Hot Folder Alert" trev1 < /tmp/alert_message'
ExecStart=/usr/bin/bash -c 'echo "A change happened in the /srv/uploads directory" > /var/log/uploads'
ExecStart=/usr/bin/bash -c 'echo "The change occured at $(date) - Check it out\n\n" >> /var/log/uploads'

Notes:
1) I'm using "oneshot" as my value for the Type= directive because I have multiple
ExecStart= directives in the [Service] section
2) The user account "trev1" is one of the admin accounts on my system, and so when
any changes occur in the /usr/uploads directory, or any modifications occur to any files
in that same directory, an email will be sent to that user account.  Also, I'm go to have
a couple of messages sent (logged) to a file named /var/log/uploads.  The messages
will simple reflect that something has occured in the /srv/uploads directory, along with
the date and time that it occured, and that "trev1" shouid stop what he's doing, and 
have a look at exactly what has caused this alert.

     2. Why does this service not need an [Install] section?

The hotfolder.service unit file does NOT need an [Install] section because it is 

expected to be launched by the holder.path unit file.  This can be seen using 2 different

commands.  The first command I used to see this is the following:

                $ sudo systemctl show hotfolder.service

The output of the above command displays many ( > 50) lines.  One of the lines that you will see in this output is the following:   

                  TriggeredBy=hotfolder.path

A second command that I used to show that the hotfolder.service unit file is triggered

by the holder.path unit file is the following:

                 $  sudo systemctl status hotfolder.path

If you will execute the above command, before you start the holder.path unit file, you

will see the following output:

○ hotfolder.path - This unit file will monitor changes in the /srv/uploads directory

     Loaded: loaded (/etc/systemd/system/hotfolder.path; enabled; preset: disabled)

     Active: inactive (dead)

   Triggers: ● hotfolder.service

Note: I've highlighted the line that indicates the hotfolder.service unit file is triggered by the hotfolder.path unit file.

Any unit file that does not contain an [Install] section, has an implied dependency on 

another unit file that is enabled. That other unit file will have the same prefix name

as the unit file without the  [Install] section.  So, for this exercise, the hotfolder.service

unit file, will be triggered/activated by a .path unit file named hotfolder.path.

 

Step 2: The Watcher (Path Unit)

The path file hotfolder.path detects file changes.

1. Which option will you use in the [Path] section to watch for new or changed files in /srv/uploads - PathChanged= or PathModified=?

The directive that I will use, in the [Path] section, to watch for new or changed files in
the /srv/uploads directory, is the PathModified= directive. My reason for using this
directive is because it performs everything that the PathChanged= directive does, and additionally, activates its dependent .service unit file - in this case hotfolder.service -  on
simple writes to content in the directory that's being monitored.

      2.  How does this Path unit know which Service unit to trigger when it sees a file?

The .path unit file will know which .service unit to trigger, based on the configuration of
the Unit=argument directive.  The argument in the directive is a unit name, whose suffix not ".path". 

Note. If the argument to the Unit= directive is not specified, the value defaults to a
service that has the same name as the .path unit file (e.g. path-unit-file-prefix.service).
My research involving the Unit= directive, recommends that the argument of the Unit=
directive be explicitly named (i.e. the same prefix as the .path unit file, with a suffix of
.service).

Step 3: Activation

1. Which unit do you run with systemctl enable --now to start the monitoring?

Of all the steps this was the most challenging to respond to

The unit file that should be run, with the systemctl enable --now command, is the .path unit file - for this exercise, hotfolder.path:

          $  sudo systemctl  enable  --now  hotfolder.path

Here are my unit files:

hotfolder.service

[Unit]
Description=Sends an email to the admin of this system when a change is made to
Description=/srv/uploads directory

[Service]
Type=oneshot
ExecStart=/usr/bin/bash -c 'mail -s "Hot Folder Alert" trev1 < /tmp/alert_message'
ExecStart=/usr/bin/bash -c 'echo "A change happened in the /srv/uploads directory" > /var/log/uploads'
ExecStart=/usr/bin/bash -c 'echo "The change occured at $(date) - Check it out\n\n" >> /var/log/uploads'

hotfolder.path

[Unit]
Description=This unit file will monitor changes in the /srv/uploads directory

[Path]
PathModified=/srv/uploads
Unit=hotfolder.service

[Install]
WantedBy=multi-user.target

Note:  In my holder.path unit file, the argument (value) that I'm using for the 
            PathModified= directive is the directory name:

Okay, this will conclude my response.  I've already penalized myself with a  -10 points
late submission.  Am I still be too lenient

Thanks Tudor for the exercise!!!