How to Watch a Directory for New File Creation in Linux

To run a command when a new file is created in a folder on a Linux system, you can use a combination of tools and scripting. One common approach is to use inotify-tools, a utility that allows you to monitor file system events, in conjunction with a shell script. Here’s a basic outline of how you can set this up:

Step 1: Install inotify-tools

First, you need to install inotify-tools. You can usually install it using your package manager. For example, on Ubuntu or Debian-based systems, you can install it by running:

sudo apt update 
sudo apt install inotify-tools 

Step 2: Create a Shell Script

Next, create a shell script that uses inotifywait (part of inotify-tools) to monitor the directory for new files and then calls an API when a new file is detected. Below is a simple example of what this script might look like:

#!/bin/bash

# Directory to monitor
MONITOR_DIR="/path/to/your/directory"

# Your custom command
# CUSTOM_COMMAND="curl -X POST -d @newfile http://your.api.endpoint"

# Monitor for new files and call the API
inotifywait -m -e create --format '%w%f' "$MONITOR_DIR" | while read NEWFILE
do
    echo "New file detected: $NEWFILE"
    # Uncomment to execute custom command
    #eval $CUSTOM_COMMAND
done

In this script, replace /path/to/your/directory with the path to the folder you want to monitor and http://your.api.endpoint with the API endpoint you want to call. You can also modify the CALL_API_COMMAND to include any necessary headers, data, or options for your specific API call.

Step 3: Run the Script

Make the script executable and run it. You can do this by:

1. Saving the script to a file, for example, monitor.sh.
2. Making it executable: chmod +x monitor.sh
3. Running the script: ./monitor.sh

Step 4: Running the Script in the Background

If you want this script to run continuously in the background, you can use nohup or run it within a screen or tmux session.

For example:

nohup ./monitor.sh & 

This will keep the script running even if you log out of the session.

Step 5: Running Script as Systemd Service

To run the script as a systemd service on a Linux system, follow these steps:

1. Ensure your script is properly written and tested. Place it in a suitable directory, such as /usr/local/bin/. For this example, let’s assume your script is named monitor.sh.

   sudo mv monitor.sh /usr/local/bin/ 
   

   Make sure it is executable:

   sudo chmod +x /usr/local/bin/monitor.sh 
   

2. Create a new systemd service file using your preferred text editor. For example, using nano:

   sudo nano /etc/systemd/system/monitor.service 
   

   Add the following content to the file:

   
   [Unit]
   Description=File Monitor Service
   
   [Service]
   ExecStart=/usr/local/bin/monitor.sh
   Restart=always
   User=nobody
   Group=nogroup
   
   [Install]
   WantedBy=multi-user.target
   
   

   • Description: A brief description of your service.
   • ExecStart: The full path to your script.
   • Restart: Configures whether the service should restart after exiting. always means the service will restart regardless of the exit code.
   • User and Group: The user and group under which the service will run. You might want to create a specific user for security purposes.

   Save and close the file.

3. Reload the systemd manager configuration:

   sudo systemctl daemon-reload 
   

4. Enable the service so it starts on boot:

   sudo systemctl enable monitor.service 
   

5. Start the service:

   sudo systemctl start monitor.service 
   

6. Check the status of your service to ensure it’s running properly:

   sudo systemctl status monitor.service 
   

Additional Notes:

• This script is a basic example. Depending on the specific requirements, you might need to modify it.
• If you need more complex monitoring or processing, consider using a more robust solution or programming language.
• Make sure your script is self-contained and doesn’t require interactive input. Systemd services are not designed for interactive use.
• If your script writes logs, make sure it writes to a location that it has permission to access. Alternatively, you can handle logging through systemd’s logging capabilities.