How to Move /var/log to Another Partition Without Rebooting in Linux


2 views

Many Linux administrators face this common issue - the root partition (/) is small, while /var/log keeps growing with system logs. When /var/log fills up, critical services may fail. Rebooting isn't always an option on production servers.

Simply moving files isn't enough because:

  • Running processes may hold open file descriptors to the old location
  • System services like rsyslog need proper restarting
  • Permissions and SELinux contexts must be preserved

Here's a step-by-step method that works without rebooting:

# Create new log directory with proper permissions
sudo mkdir /home/log
sudo chown root:syslog /home/log
sudo chmod 775 /home/log

# Copy logs preserving all attributes
sudo rsync -avX /var/log/ /home/log/

# Bind mount the new location
sudo mount --bind /home/log /var/log

# Make the change persistent
echo "/home/log /var/log none bind 0 0" | sudo tee -a /etc/fstab

# Restart logging services
sudo systemctl restart rsyslog
sudo systemctl restart auditd  # if using audit logs

For services that might still reference old inodes:

# Find processes using old log files
sudo lsof +D /var/log

# Restart affected services
for service in $(ls /etc/init.d/); do
  sudo service $service restart
done

While bind mounts are preferred, you could also use symlinks after stopping services:

sudo systemctl stop rsyslog
sudo mv /var/log /home/log
sudo ln -s /home/log /var/log
sudo systemctl start rsyslog

After moving, verify everything works:

# Check mount points
mount | grep /var/log

# Test logging
logger "Test message"
tail -n 1 /var/log/syslog

# Check disk space
df -h /var/log

When dealing with production servers, we often encounter situations where the root partition (/) fills up due to growing log files in /var/log. Hard reboots aren't an option for mission-critical systems, requiring careful migration techniques that maintain service continuity.

The main obstacles when moving active log directories include:

  • Open file descriptors from running processes
  • Active syslog daemon connections
  • Potential permission issues
  • Application-specific log handling
# Create new log destination
sudo mkdir -p /home/log
sudo chown root:syslog /home/log
sudo chmod 775 /home/log

# Copy existing logs while preserving attributes
sudo rsync -avzX /var/log/ /home/log/

# Mount the new location without disrupting services
sudo mount --bind /home/log /var/log

# Verify the bind mount succeeded
mount | grep /var/log

# Restart logging services
sudo systemctl restart rsyslog

For services maintaining open file descriptors, consider these additional steps:

# Identify processes with open log files
sudo lsof +D /var/log

# Gracefully restart affected services
for service in $(ls /etc/init.d/); do
  sudo /etc/init.d/$service reload 2>/dev/null || continue
done

To persist the change across reboots, edit /etc/fstab:

/home/log    /var/log    none    bind    0    0

For simpler cases where applications follow symlinks:

sudo mv /var/log /home/log
sudo ln -s /home/log /var/log
sudo systemctl restart rsyslog

Note this may cause issues with security-conscious applications.

After migration, verify functionality:

# Check disk usage
df -h /var/log /home/log

# Generate test log entries
logger "Test message after log migration"

# Verify log rotation
sudo logrotate -f /etc/logrotate.conf