This is original tips/tricks post. As you can see, the code get very simplified. You don't even need any undo script, because now /etc/init.d/vartmp stop undo itself.

----------

Hello all,

The thread in Using tmpfs for /tmp prompted me to experiment with using tmpfs for some /var directories that has frequent disk read/write, such as /var/log. I imagine doing so will have certain advantages:

- Speed: it speeds up the logging process
- I/O: it reduces disk I/O

The following are the scripts I have conjured, to see if anyone brave enough to try them. I have been using them for a while, no problems so far.

/etc/init.d/vartmp - This is the startup script:

Code:

#!/sbin/runscript
#
# This init script mounts various /var sub-directories into RAM-based filesystem
# (i.e. tmpfs). There are two main advantages in doing so:
# - speed: its speeds up logging processes
# - disk-sync: it reduces the need for constant disk syncs
#
# Pre-requisite: you need to have the following entry in your /etc/fstab
# none ${VARTMP_MOUNT} tmpfs defaults,size=256m 0 0
#
# and make sure the ${VARTMP_MOUNT} directory is created and mounted before executing
# this script

# VARTMP_MOUNT defines where the tmpfs base directory for /var is
VARTMP_MOUNT="/mnt/vartmp"

# VARTMP_DIRS defines which of the /var sub-directories resides on the tmpfs
VARTMP_DIRS="log lock run"

Steps - Here is what I did:

First, edit /etc/fstab to contain the line:

Code:

none ${VARTMP_MOUNT} tmpfs defaults,size=256m 0 0

The size I chose is 256M, its up to you to vary. You can use a higher size since tmpfs has the nice feature of not actually using any memory until it is populated.

Next, mount the tmpfs

Code:

mkdir /mnt/vartmp
mount /mnt/vartmp

Then, edit /etc/conf.d/vartmp to your liking (particularly the VARTMP_DIRS="" variable that specify which of the subdirectories to move to tmpfs. You definitely don't want to move all of them, unless you have obscene amount of RAM, like 32G ) and run the init script:

Just as a side-note - putting /var/log on a ramdisk is not a good idea. If something crashes, your logs won't be available on next reboot._________________Config - caught by a chronic disease called tuxmania....

Just as a side-note - putting /var/log on a ramdisk is not a good idea. If something crashes, your logs won't be available on next reboot.

This is VERY true, but what I do is separate logs by message level:
warn and worse go to /var/log/messages (or similar), which is on HD.
but info or debug and worse and go /tmp/log/debug, which is tmpfs. This way, I can sift through all the extra info if I want, but nothing important is lost on hard reboot.

I also broadcast logs between machines on the lan, so each machine is watching the other machines' (info and worse) logs on /tmp/log/remote (tmpfs). Hence, if one machine goes down (but not all of them), I can quickly see what happened by just going to another workstation.

Hi. I didn't know about this tip and I created a my own initscript to to do the same things.
This script generates a tar of /var/log, /var/run and /var/lock at shutdown and populate them at reboot. You have to add it to boot runlevel.
It also does some rotating of logs so you don't have to use logrotate. You can set a maximum file size for the log tar archive and the script will create a backup (and will delete the old logs) when the size is reached.

You have to have lines like these in fstab to mount those directories in tmpfs

Hi. I didn't know about this tip and I created a my own initscript to to do the same things.

Is there a particular reason for these chown and chrgrp commands? Aren't they automatically executed by tar?
Moreover, why is it necessary to touch utmp? (Does something go crazy if utmp has "old" timestamp?)

Hi. I didn't know about this tip and I created a my own initscript to to do the same things.

Is there a particular reason for these chown and chrgrp commands? Aren't they automatically executed by tar?
Moreover, why is it necessary to touch utmp? (Does something go crazy if utmp has "old" timestamp?)

Just to make sure those files are there... They must exists for linux to behave correctly. The rest of the tar archive could become corrupted and all other files get lost, but at least you want to boot and get a working console._________________Any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee
-John Donne

Hi all. I stumbled on this old script of mine and I gave it an update. Now it's divided into an init script and a log daemon. The name of the files is important, so if you want to change it you have to change also something in the two scripts.
It does a backup of the directory structure of /var/log, /var/run, /var/lock and /var/spool, restoring necessary files and subdirectories each reboot and providing a rotation of logs in case the tar file becomes too big (it preserves emerge.log).

It is compatible with baselayout-2 and openrc, at least up to version 0.7.0. It should behave also with parallel boot, but don't take it for granted...

#Directory for backups of /var/log, /var/run and /var/lock
DATA_DIR_BACKUP=/var
#Maximum size of logs in the tar archive before rotating
MAX_LOG_SIZE=50
#If you want the script to act like a daemon and rotate logs before the system restart, then set this variable to 1
DEMONIZED=0
#If DEMONIZED=1, then select the time interval between checks (s,m,h,d are the suffixes for seconds, minutes, hours, days)
CHECK_TIME=2h
#The daemon is the script located in /usr/local/sbin/log_daemon.sh

I found some apps they create its own directory in /var/log or /var/run (during install?) . If mount /var/log or /var/run with tmpfs this apps will not start because missing directories. Can anybody reproduce this? This will avoid to mount this directories empty with tmpfs in /etc/fstab, without backup and restore the structure?

#!/sbin/runscript
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /etc/init.d/vartmp rev.3 $
#
# This init script mounts various /var sub-directories into RAM-based filesystem
# (i.e. tmpfs). There are two main advantages in doing so:
# - speed: its speeds up logging processes
# - disk-sync: it reduces the need for constant disk syncs
#
# Now this line, or somothing like that, with the desired size value:
# vartmp $VTMP_MNT tmpfs defaults,size=128m 0 0
# is not a mandatory anymore. vartmp will check if the required tmpfs is mounted, and if not, mount it.
# This was necessary as I runned this script for the first time and noticed nothing in the output of mount.

Oh, new to this... is it ok to thank people for their help, as now, or does this clutter the forums? will refrain in the future based on your advice

I generally think its good form, if it solves the issue then its some clue that the provided information worked, though tagging the thread [SOLVED] is also fine. I most often refrain from replying with a "you're welcome" unless there is something further to add :)