Chapter 2

SCHEDULING FUTURE TASKS

Scheduling

At command

You have a meeting in four days at noon and need to send a reminder email to the participants.

echo "echo 'Meeting Reminder' | mail -s 'Meeting Alert' [e-mail]" | at noon +4 days

For monitoring purposes, you decide to append the current system time to a log file named myjob.txt in 3 minutes.

echo "date >> /home/student/myjob.txt" | at now +3min

You have a script that needs to run at 4 PM (teatime) tomorrow, but you want it to be in a separate queue (g) for organization.

echo "/usr/bin/myscript.sh" | at -q g teatime tomorrow

You need to check for system updates every day at 4:05 PM. You decide to use a different queue (b) for this task.

echo "sudo apt-get update" | at -q b 16:05

cronjobs

# List the jobs for the current user.
crontab -l

# Remove all jobs for the current user.
crontab -r 

# Edit jobs for the current user.
crontab -e

# Remove all jobs, and replace with the jobs read from filename.
# If no file is specified, stdin is used.
crontab filename

The cronjob expression 1 2,3 3/4 6-7 5 /etc/script.sh is used to schedule a task in Unix-like operating systems. It specifies when the script /etc/script.sh should be executed. Let's break down the cron expression:

1. Minute: 1 - The task will run when the minute is 1.

2. Hour: 2,3 - The task will run at 2 AM and again at 3 AM. This means it is scheduled to run twice in the early morning.

3. Day of the Month: 3/4 - This is a step value syntax starting from the 3rd day of the month. The task will run every 4 days, beginning from the 3rd day. So, it will run on the 3rd, 7th, 11th, 15th, 19th, 23rd, 27th, and 31st of the month.

4. Month: 6-7 - The task will run in June and July. The range 6-7 includes both months 6 (June) and 7 (July).

5. Day of the Week: 5 - The task will run on Friday, which is denoted by the number 5 (with Sunday being 0, Monday is 1, and so on).

Putting it all together, the cronjob 1 2,3 3/4 6-7 5 /etc/script.sh means that the script located at /etc/script.sh will be executed at 2:01 AM and 3:01 AM on the 3rd, 7th, 11th, 15th, 19th, 23rd, 27th, and 31st of June and July, but only if those days are a Friday.

The /etc/crontab file has a useful syntax diagram in the included comments.

# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue ... #| | | | |
# * * * * * user-name command to be executed

We can put our script in folders below to run them hourly, daily, weekly and monthly:

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

run-parts

• What It Is: run-parts is a command used in Unix and Linux systems to run all the executable scripts or programs in a directory.

• Usage: It's often used in cron jobs to execute all scripts in certain directories on a schedule. For example, a cron job might use run-parts /etc/cron.daily to run all scripts in the /etc/cron.daily directory.

• Benefits: It simplifies management of cron tasks. Instead of editing cron tables for each new script, you can simply place the script in an appropriate directory.

/etc/cron.d/0hourly

• What It Is: This is a specific cron configuration file, typically found on systems that use cron for scheduling.

• Purpose: It's often used to define hourly tasks. The name 0hourly suggests it's a template or trigger for jobs that should run every hour.

• Content: Inside, you might find a cron job that uses run-parts to execute all scripts in a particular directory (like /etc/cron.hourly).

anacron

• What It Is: Anacron is a program that runs scheduled tasks, but unlike cron, it does not assume the system is running continuously. It's useful for machines that aren’t running 24/7 like laptops or desktops.

• Functionality: Anacron checks whether certain tasks scheduled for daily, weekly, or monthly execution have been completed. If the system was off at the scheduled time, Anacron runs those tasks as soon as possible after the system starts.

anacrontab file

• What It Is: Similar to a crontab file for cron, anacrontab is the configuration file for Anacron.

• Content: It contains scheduled tasks, including the frequency of the task (in days), the delay in minutes after starting Anacron before running the task, a unique job identifier, and the command or script to be executed.

• Example: An entry in anacrontab might look like 7 15 test.daily /bin/sh /path/to/script.sh, meaning the task runs every 7 days, with a 15-minute delay after Anacron starts, and executes the specified script.

/var/spool/anacron/

• What It Is: This directory is used by Anacron to store timestamps.

• Purpose: When Anacron runs a job, it records the date in a file in this directory. This information is used to determine when a job was last run.

• Function: Helps Anacron decide whether it needs to run a particular job based on the schedule defined in the anacrontab file and the last run date.

systat

The sysstat package is a collection of utilities provided for performance monitoring in Unix-like operating systems, particularly Linux. This package is widely used for monitoring system performance and is known for being lightweight and powerful. It provides tools to gather and report system activity information. The key components and functionalities of the sysstat package include:

1. sar (System Activity Reporter):

   • sar is perhaps the most well-known tool in the sysstat package.

   • It collects, reports, or saves system activity information (like CPU usage, memory/paging statistics, process creation activity, disk I/O, network, among others).

   • It helps in diagnosing performance issues and keeping track of system health over time.

   • sar can display real-time data or retrieve historical data collected at other times.

2. iostat (Input/Output Statistics):

   • This tool reports CPU statistics and input/output statistics for devices, partitions, and network filesystems (NFS).

   • It's useful for identifying bottlenecks in the system's I/O and for understanding how effectively the CPU is being utilized.

   • It can display both current and historical data, offering insights into how the system's I/O is being used over time.

3. mpstat (Multiprocessor Statistics):

   • mpstat is used to show processor statistics.

   • It's particularly useful on systems with multiple processors or cores, as it can display the usage of each processor or core, helping to identify imbalances or overuse.

4. pidstat (Process Statistics):

   • This tool reports statistics for Linux tasks (processes), such as CPU, memory, I/O, context switch, and more.

   • It's valuable for monitoring individual processes and understanding their impact on system performance.

5. nfsiostat-sysstat (NFS I/O Statistics):

   • It reports input/output statistics for network filesystems (NFS).

   • This is particularly useful in environments where remote filesystems are mounted and used regularly.

6. cifsiostat (CIFS I/O Statistics):

   • This tool reports I/O statistics for CIFS (Common Internet File System) filesystems.

   • It's useful for analyzing performance of CIFS (SMB) network file system which is widely used for providing shared access to files between nodes on a network.

Scenario: A Company's IT Department Monitors Server Performance

Background: You are a system administrator in the IT department of a medium-sized company. Your company relies heavily on its servers for various operations, including hosting the company's internal applications, databases, and websites. Ensuring these servers perform optimally is crucial for the business.

Task: To effectively monitor the performance of these servers, you decide to use the sysstat package to collect and analyze system activity data.

Setting Up sysstat:

1. Installation: You install the sysstat package on the servers using yum install sysstat.

2. Configuration of Data Collection:

   • You notice that sysstat is configured to collect data every 10 minutes by default, but you need more frequent data for detailed analysis.

   • You copy the sysstat-collect.timer from /usr/lib/systemd/system/ to /etc/systemd/system/ to customize the timer.

   • You edit the sysstat-collect.timer file and set OnCalendar=*:00/02 to trigger data collection every two minutes.

   • You enable the timer with systemctl enable --now sysstat-collect.timer.

Data Collection and Analysis:

• Data Storage: The sysstat tool, specifically the sa1 command part of the sadc system, starts collecting data every two minutes and stores it in binary format in the /var/log/sa directory. Each file represents a day's data, named as saDD where DD is the day of the month.

• Analysis:

  • As the system administrator, you regularly use the sar command to analyze this data.

  • You can view CPU usage, memory utilization, I/O activity, and network statistics.

  • This data helps you identify any performance bottlenecks. For example, if you notice a high CPU load at specific times, you might investigate further to see if certain processes or applications are consuming excessive resources.

MANAGING TEMPORARY FILES

systemd-tmpfiles --create --remove
# Aşağıdakı konfiqurasiya fayllarını oxuyaraq faylları silir, yaradır və ya səlahiyyət verir
/usr/lib/tmpfiles.d/*.conf
/run/tmpfiles.d/*.conf
/etc/tmpfiles.d/*.conf

systemd timer unit called systemd-tmpfiles-clean.timer triggers systemd-tmpfiles-clean.service on a regular interval, which executes the systemd-tmpfiles --clean command.

Scenario: Managing Temporary Files in a Hospital's Server System

Background: Imagine you are the IT administrator at a large hospital. The hospital's server system runs on Red Hat Enterprise Linux 7. This system hosts various critical applications, including patient records management, appointment scheduling, and internal communications. These applications, along with regular user activities, generate a significant amount of temporary data.

Challenge: One key challenge is managing this temporary data effectively. Temporary files, if not handled properly, can accumulate, taking up valuable disk space and potentially slowing down the system. Moreover, some temporary files might contain sensitive data that should not persist on the system for security reasons.

Solution: To address this, you decide to implement systemd-tmpfiles for structured and automated management of temporary files.

Implementing systemd-tmpfiles:

1. Initial Setup:

   • The server already includes systemd-tmpfiles as part of its Red Hat Enterprise Linux 7 setup.

   • The systemd-tmpfiles-setup service is one of the first units launched by systemd, ensuring that necessary temporary directories and files are created and that old files are removed at boot.

2. Configuring Automatic Cleanup:

   • You inspect the systemd-tmpfiles-clean.timer and find that it's set to trigger the cleanup service 15 minutes after boot and then every 24 hours.

   • For the hospital’s needs, you decide that cleaning up every 12 hours is more appropriate. You modify the OnUnitActiveSec parameter to 12h.

   • After changing the timer configuration, you reload the systemd daemon configuration with systemctl daemon-reload and enable the timer with systemctl enable --now systemd-tmpfiles-clean.timer.

3. Manual Cleanup and Configuration:

   • Sometimes, you need to perform manual cleanups, especially when dealing with unexpected spikes in temporary file generation (like during mass data migrations or system updates).

   • You use systemd-tmpfiles --clean to manually purge files that haven't been accessed or modified within the duration specified in the configuration files.