5

To avoid useless write to my SSD I've moved /var/log (and /tmp) to RAM via /etc/fstab:

cat >> /etc/fstab <<'EOT'
tmpfs    /tmp        tmpfs    defaults,size=1g                                0    0
tmpfs    /var/log    tmpfs    defaults,nosuid,nodev,noatime,mode=0755,size=5% 0    0
EOT

But since then I have no /var/log/syslog file.

I thought it was because /var/log is not yet mounted when rsyslogd starts but it still doesn't work when manually restarting the service (when I'm sure /var/log is mounted).

I'm using:

  • Ubuntu 14.04.2
  • Kernel 3.13.0-45
  • rsyslog 7.4.4-1ubuntu2.5

2 Answers 2

3

Moving anything in /var to a tmpfs is a bad idea at this point, because neither Ubuntu nor any other major Linux distribution support it at the moment. It also has the disadvantage to occupy main memory and to lose all previous log files, which hampers problem diagnosis. SSD drives really aren't that delicate when it comes to write cycles and a few log files don't result in enough data and write operations to reduce the life span of an SSD significantly. Very few SSDs fail because of write cycle exhaustion.

I suspect that /var/log/syslog still exists, but only on the root file system, because rsyslog starts before /var/log is mounted. When you mount another file system at /var/log, its previous content is hidden underneath.

As a workaround you can bind your root file system somewhere else, which would allow you to inspect its content unshadowed by other mountpoints:

sudo mkdir -p /mnt/root
sudo mount --bind / /mnt/root

You should now see other content in /mnt/root/var/log.

P.S.: If you have an internal hard disk drive in your machine in addition to an SSD, you can mount /var from there. That's what I and many other people do and not mainly because of concerns about write cycles. The main reason was always, that a faulty program may accidentally write heaps of (log) data to /var and nobody would notice until the file system was full, at which point it would be difficult to alleviate the situation, if /var was part of /.

2
  • Good idea to check disk's /var/log, but no luck : it's empty. I didn't know OS didn't supported mounting any /var to a tmpfs (NB: I'm OK with the loose of log files). I guess the other way of relieving the SSD is to use a dedicated FS with low frequency commit (once every hour)?
    – CDuv
    Mar 4, 2015 at 14:05
  • This would kind of defeat the purpose of a syslog. You want it to write out log messages as early as possible in case the system crashes in the mean time. Otherwise you might loose the log message about the event that caused the crash. Mar 4, 2015 at 14:18
1

You should create those files in /etc/rc.local file like that:

# Restore tmpfs directories for logs. 
# Extend the following directories to your needs according to installed packages
for dir in apparmor apt cups dist-upgrade fsck gdm installer samba unattended-upgrades upstart ;
do
  if [ ! -e /var/log/$dir ] ; then
    mkdir /var/log/$dir
  fi
done

# Restore syslog files
for file in debug mail.err mail.log mail.warn syslog ;
  if [ ! -f /var/log/$file ] ; then
    touch /var/log/$file
    chown syslog:adm /var/log/#file
  fi
done

# Set owners for the newly created log directories
chown root:adm /var/log/samba

Above script goes before the line:

exit 0

This script creates those necessary directories and files on system start. You can also optionally sync those directories using rsync on shutdown, if you need them to be persistent between system restarts.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .