Anacron Not Working as Expected on Lubuntu: A Daily Scheduled Job Issue

Anacron in Lubuntu often appears to fail because it is designed for systems that are not always running, executing jobs only after a specified delay following boot. If your daily scheduled tasks do not trigger, the issue usually stems from incorrect configuration syntax, missing executable permissions on scripts, or the system being powered on for longer than Anacron's minimum interval threshold.

Understanding Anacron vs Cron

It is crucial to distinguish between cron and anacron before troubleshooting. Standard cron assumes the computer is running continuously at specific times of the day. If the machine is off when a job is scheduled, cron misses it entirely. Anacron, however, is built for desktops and laptops that may be suspended or shut down. It checks if a job has run within a certain period (usually 24 hours) and executes it shortly after the system boots if it was missed.

In Lubuntu, Anacron handles standard system maintenance tasks like log rotation and package updates. User-defined tasks should generally remain in cron unless they specifically need to catch up after downtime. Misunderstanding this distinction is the most common reason users believe Anacron is "not working."

Verifying Configuration Syntax

The most frequent cause of failure is a syntax error in the /etc/anacrontab file or user-specific Anacron configurations. The format requires four specific fields: period, delay, identifier, and command. A missing space or an incorrect time unit will cause the daemon to ignore the line silently.

• Period: Must be a number representing days (e.g., 1 for daily, 7 for weekly).
• Delay: The number of minutes to wait after boot before starting the job. Use 5 or 10 for testing.
• Identifier: A unique string used for tracking state (e.g., my-script).
• Command: The full path to the script or command to execute.

Ensure you are editing the correct file. System-wide tasks go in /etc/anacrontab, while user-specific tasks typically require a different approach since Anacron traditionally runs as root. If you are trying to run a user script via Anacron, you must ensure the environment variables are set correctly, which can be tricky.

Checking Script Permissions and Paths

Even with perfect syntax, Anacron will fail if it cannot execute the target script. Linux security models require explicit permission to run files as executables. Verify that your script has the execute bit set using the chmod +x /path/to/script.sh command. Without this, Anacron will attempt to run the file and receive a "Permission denied" error, which is often logged but not immediately visible to the user.

Additionally, always use absolute paths for both the script and any internal commands within the script. When Anacron runs, it does not inherit your interactive shell's $PATH variable fully. Using relative paths like ./script.sh will almost certainly fail. For example, instead of just backup.sh, use /home/user/scripts/backup.sh.

If your script relies on specific environment variables, such as those defining database connections or API keys, these must be exported within the script itself or sourced explicitly. Anacron provides a minimal environment, so relying on your graphical session's settings is a recipe for failure.

This related guide helps diagnose broader scheduling issues that might overlap with Anacron problems, particularly regarding service status and logging.

Debugging and Logs

To see what Anacron is actually doing, you must check the system logs. On Lubuntu, you can use journalctl to filter messages from the Anacron service. Run the following command to view recent entries:

journalctl -u anacron.service --no-pager

Look for lines indicating "Running job..." or errors stating "Failed to run job." If the logs show no activity at all, Anacron may not have detected that a job is due. You can force Anacron to check for overdue jobs by running:

sudo anacron -d

The -d flag enables debug mode, providing verbose output about why jobs are skipped or started. This is invaluable for identifying timing issues. For instance, if your delay is set to 60 minutes but your job runs every hour, Anacron might skip it if it thinks it ran recently enough.

Common Pitfalls in Lubuntu

Lubuntu uses LXQt, which sometimes interacts with power management daemons in ways that affect background services. Ensure that your power settings are not suspending the system too aggressively, which can interrupt Anacron's startup sequence. Additionally, verify that the anacron package is installed and enabled:

systemctl is-enabled anacron

If it returns disabled, enable it with sudo systemctl enable anacron. Note that on some modern systemd-based distributions, Anacron is triggered by timers rather than traditional init scripts, so ensuring the timer is active is critical.

Alternative Approaches

If Anacron continues to cause issues, consider moving your task to standard cron if your machine is mostly always on. Alternatively, use systemd timers, which offer more precise control and better integration with modern Linux systems. Systemd timers can also handle missed executions gracefully, similar to Anacron, but with more robust logging and dependency management.

Frequently Asked Questions

Why does my Anacron job run every time I boot, even if it ran yesterday?

This happens if the delay parameter is too short or the period is set incorrectly. Ensure your period is set to 1 for daily tasks and that the delay allows enough time for the system to stabilize. Also, check that the timestamp file in /var/spool/anacron is being updated correctly.

Can I run Anacron jobs as a non-root user?

Anacron is traditionally designed to run as root. To run user-specific tasks, it is better to use cron with the -u flag or configure a systemd user timer. Attempting to run complex user scripts via root Anacron can lead to permission and environment variable conflicts.

How do I clear the Anacron spool to force a job to run?

You can manually remove the timestamp file associated with the job in /var/spool/anacron. The filename corresponds to the identifier in your anacrontab. Deleting this file tells Anacron that the job has never been executed, forcing it to run upon the next check.

Is Anacron necessary if I rarely turn off my computer?

If your computer is always on, standard cron is sufficient and more precise. Anacron adds overhead by checking timestamps and managing delays. Use Anacron only if you frequently suspend or shut down your device and need to ensure maintenance tasks eventually complete.

What logs should I check if Anacron fails silently?

Check /var/log/syslog or use journalctl -u anacron for detailed service logs. Additionally, redirect output from your script to a custom log file using >> /tmp/myjob.log 2>&1 in the Anacron command line to capture stdout and stderr directly.