Keywords: Linux | CRON | Scheduled Tasks | Second-level Scheduling | sleep Command
Abstract: This technical paper provides an in-depth analysis of configuring CRON jobs to execute every 10 seconds in Linux environments. By examining CRON's minimum time granularity limitations, the paper details solutions using multiple parallel tasks with sleep commands and compares different implementation approaches. Complete code examples and configuration guidelines are included for developers requiring high-frequency scheduled tasks.
Analysis of CRON Time Granularity Limitations
The standard CRON scheduler in Linux systems has a minimum time resolution of one minute, making direct second-level task scheduling through CRON expressions impossible. When users attempt to use the */10 * * * * expression, they are actually configuring execution every 10 minutes, not every 10 seconds.
Parallel Multi-Task Solution
To achieve task scheduling that executes every 10 seconds, it is necessary to create six independent CRON tasks, each starting at different time points within each minute and achieving precise time intervals through sleep commands. The specific configuration is as follows:
* * * * * ( /usr/bin/wget http://api.us/application/ )
* * * * * ( sleep 10 ; /usr/bin/wget http://api.us/application/ )
* * * * * ( sleep 20 ; /usr/bin/wget http://api.us/application/ )
* * * * * ( sleep 30 ; /usr/bin/wget http://api.us/application/ )
* * * * * ( sleep 40 ; /usr/bin/wget http://api.us/application/ )
* * * * * ( sleep 50 ; /usr/bin/wget http://api.us/application/ )Implementation Principle Details
The core concept of this solution is to utilize CRON's minute-level triggering mechanism, starting six tasks simultaneously at the beginning of each minute. Each task achieves time offset through different sleep delays:
- First task executes immediately (0-second delay)
- Second task executes after 10-second delay
- Third task executes after 20-second delay
- Continuing this pattern, the sixth task executes after 50-second delay
Through this configuration, six execution time points are formed within each minute at 0, 10, 20, 30, 40, and 50 seconds, thereby achieving execution every 10 seconds.
Alternative Approach Comparison
Another implementation method uses a single-line loop command:
* * * * * for i in {1..6}; do /usr/bin/wget http://api.us/application/ & sleep 10; doneThis approach executes the task six times consecutively within each minute through a for loop, with 10-second intervals between each execution. While the code is more concise, it carries the risk of task execution time potentially exceeding 10 seconds, leading to time drift.
Configuration Considerations
The following factors should be considered during actual deployment:
- System resource consumption: Multiple parallel tasks may increase system load
- Task execution time: Ensure single task execution time does not exceed 10 seconds to avoid time overlap
- Error handling: Recommend adding appropriate error handling mechanisms
- Logging: Configure detailed log output for monitoring and debugging
Performance Optimization Recommendations
For high-frequency tasks, it is recommended to:
- Use lightweight HTTP clients instead of
wget - Consider specialized scheduling tools like
systemd timers - Implement task queue mechanisms to avoid resource contention
- Monitor system performance metrics to ensure stability