Automated Server Updates: Why I Use This Cron Setup on All My Servers

Managing multiple Linux servers means keeping them updated. If you're manually running updates, you're either doing it too often (wasting time) or too rarely (leaving security holes). That's why I set up automated daily updates and reboots on every server I manage.

This cron configuration handles security patches, package updates, and reboots automatically, so your servers stay current without constant manual intervention. Here's exactly what I use and why.

The Cron Configuration

Here's the cron setup I use on all my Debian/Ubuntu-based servers:

0 2 * * * apt-get update && apt-get upgrade -y
0 3 * * * [ -f /var/run/reboot-required ] && reboot

Let me break down what each line does and why I run them at 2 AM and 3 AM.

Line 1: Automated Package Updates (2 AM)

0 2 * * * apt-get update && apt-get upgrade -y

This cron job runs every day at 2:00 AM and does two things:

• apt-get update: Refreshes the package list from repositories
• apt-get upgrade -y: Installs all available updates automatically (the -y flag answers "yes" to prompts)

Why 2 AM?

I schedule updates at 2 AM because:

• Low traffic hours (most applications have minimal usage)
• Plenty of time for updates to complete before the reboot check
• Reduces impact on users and services
• Follows a predictable schedule for monitoring

Why Automated Updates?

Security patches are released frequently, and manually updating multiple servers is time-consuming and error-prone. Automated updates ensure:

• Timely security patches: Critical vulnerabilities get patched quickly
• Consistency: All servers stay updated, not just the ones you remember to check
• Reduced maintenance overhead: Less time spent on routine updates
• Better security posture: Systems aren't left vulnerable because updates were delayed

Line 2: Automated Reboots (3 AM)

0 3 * * * [ -f /var/run/reboot-required ] && reboot

This cron job runs every day at 3:00 AM and checks if a reboot is required. If the file /var/run/reboot-required exists, it reboots the server.

Why the Conditional Check?

The [ -f /var/run/reboot-required ] condition ensures the server only reboots when necessary. Linux creates this file when kernel updates or certain system-level changes require a reboot to take effect.

This means:

• Servers don't reboot unnecessarily (saves downtime)
• Reboots only happen when updates require them
• Kernel updates take effect properly
• System-level changes are applied correctly

Why 3 AM?

I schedule the reboot check at 3 AM because:

• It runs after the 2 AM update job completes
• Still during low-traffic hours
• Gives updates time to finish before checking for reboot
• Minimizes user impact if a reboot is needed

Why I Set This Up on All My Servers

Here's why I use this configuration on every server I manage:

1. Security First

The biggest reason is security. Unpatched vulnerabilities are a primary attack vector. Automated daily updates mean critical security patches get applied within 24 hours of release, dramatically reducing your attack surface.

2. Consistency Across Infrastructure

When you manage multiple servers, consistency is crucial. This cron setup ensures all servers follow the same update schedule and get the same patches at the same time. You don't have to remember which servers you've updated and which ones you haven't.

3. Reduced Operational Overhead

Manual updates on multiple servers take significant time. Even with just a few servers, checking for updates, reviewing what's being installed, and applying them can consume hours each week. Automation frees that time for more important tasks.

4. Kernel Updates Apply Properly

Many critical security updates require kernel changes, which need a reboot. Without automated reboots, these updates don't actually take effect, leaving you vulnerable even though you "applied" the patch. The conditional reboot ensures kernel updates are applied correctly.

5. Predictable Maintenance Windows

Having a consistent 2-3 AM maintenance window makes it easier to plan around. You know when updates happen and when reboots might occur, which helps with monitoring, alerting, and informing users if needed.

How to Set It Up

Setting this up is straightforward:

Step 1: Edit Your Crontab

crontab -e

This opens your user's crontab in the default editor (usually nano or vi). If you haven't used crontab before, select your preferred editor when prompted.

Step 2: Add the Cron Jobs

Add these two lines to your crontab:

0 2 * * * apt-get update && apt-get upgrade -y
0 3 * * * [ -f /var/run/reboot-required ] && reboot

Step 3: Save and Exit

Save the file and exit. In nano, press Ctrl+X, then Y to confirm, then Enter. In vi, press Esc, type :wq, and press Enter.

Step 4: Verify It's Set

Verify your crontab is set correctly:

crontab -l

This displays your current crontab entries. You should see the two lines you just added.

Important Considerations

Root Privileges

These commands require root privileges. You have a few options:

• Run as root: Use sudo crontab -e to edit root's crontab directly
• Use sudo in cron: Add sudo before each command (requires passwordless sudo or NOPASSWD configuration)
• Run as a user with sudo access: Configure passwordless sudo for these specific commands

I typically use root's crontab (sudo crontab -e) because these are system-level operations that need full privileges anyway.

Logging and Monitoring

By default, cron sends output to the user's email. For automated updates, you might want to add logging:

0 2 * * * apt-get update && apt-get upgrade -y >> /var/log/auto-update.log 2>&1
0 3 * * * [ -f /var/run/reboot-required ] && reboot

This redirects output to /var/log/auto-update.log so you can review what was updated. The 2>&1 redirects both standard output and error output.

Production Servers

For critical production servers, consider:

• Testing updates in a staging environment first
• Using apt-get upgrade instead of apt-get dist-upgrade to avoid removing packages
• Setting up monitoring to alert you when updates are applied
• Having a rollback plan if updates cause issues
• Coordinating reboots with your team during maintenance windows

Email Notifications

If you want email notifications when updates are applied, you can pipe the output to mail:

0 2 * * * apt-get update && apt-get upgrade -y 2>&1 | mail -s "Server Update: $(hostname)" [email protected]

Potential Issues and Solutions

Package Conflicts

Sometimes updates can cause package conflicts. Using apt-get upgrade (not dist-upgrade) is safer because it won't remove packages to resolve conflicts. If conflicts occur, the update will fail, and you'll need to resolve them manually.

Unattended Reboots

Automated reboots can be problematic if:

• Services don't start automatically after reboot
• You have long-running processes that can't be interrupted
• You need to coordinate reboots with other systems

For these situations, you might want to remove the automated reboot line and handle reboots manually during planned maintenance windows.

Disk Space

Updates require disk space. Make sure you have adequate free space (at least a few GB) and consider running apt-get autoremove periodically to clean up old packages.

Locked Packages

If packages are locked or held, updates will fail. Use apt-mark hold to intentionally hold packages, and check for locked packages if updates aren't applying.

Alternative: Using Unattended-Upgrades

Debian and Ubuntu have an unattended-upgrades package that provides more sophisticated automated update management. It includes:

• Configurable update sources (security updates only, or all updates)
• Automatic reboots with configurable delays
• Better logging and notification options
• Blacklist for packages you don't want to auto-update

For basic needs, the cron approach works fine. For more control and features, unattended-upgrades is worth considering.

Best Practices

Here are some best practices I follow:

• Start with non-critical servers: Test the setup on development or less critical systems first
• Monitor the first few runs: Check logs to ensure updates are working correctly
• Set up alerts: Configure monitoring to notify you of failed updates or unexpected reboots
• Document the schedule: Make sure your team knows when automated maintenance happens
• Review logs periodically: Check update logs to stay aware of what's being updated
• Have a rollback plan: Know how to revert updates if something goes wrong

When Not to Use This Setup

Automated updates aren't right for every situation. Consider alternatives if:

• You need strict change control and approval processes
• Updates require extensive testing before deployment
• You have complex dependencies that break with updates
• Reboots must be coordinated across multiple systems
• You're running custom packages or repositories

Conclusion

Automated daily updates and conditional reboots keep my servers secure and current without constant manual intervention. This simple cron configuration ensures security patches get applied quickly, kernel updates take effect properly, and all servers stay consistent.

For most use cases, especially when managing multiple servers, automation beats manual updates every time. Set it up once, monitor it occasionally, and spend your time on more important tasks.

Just remember to start on non-critical systems, monitor the first few runs, and adjust the schedule or configuration based on your specific needs.