The sys admin's daily grind: iWatch

In a Minute

Article from Issue 165/2014

Recently, sys admin Charly was faced with the task of synchronizing a directory on a server with two NFS-mounted clients. He wanted the whole thing to happen quickly and to be easily manageable, which ruled out DRBD and GlusterFS.

My sync setup looks roughly like this: An application server cyclically reads values from a database, generates HTML files and some images, and dumps everything in the /source directory. I use NFS 4 to mount the /dest1 and /dest2 directories. When any new data arrives in /source, I want it to reach the two target directories /dest1 and /dest2.

Simple and Been Here for Years

Because complex solutions are out of the question, actually the only option left is to dump the task on inotify subsystem's plate. Inotify has been part of the kernel since 2.6.13 and provides an interface to filesystem events for userspace programs.

Apart from incron [1], I've hardly found a use for it so far, but it should be ideal for quick syncing of directories – or at least, these were my ideas on the matter. What was missing was the right tool for the task. Some quick research brought to light two candidates: lsyncd [2] and iWatch [3], but I'll focus on iWatch here.

The monitor is suitable for operation in the foreground or as a daemon. In the simplest case, I just monitor a single directory without triggering an action:

iwatch -r /var

iWatch then reports:

[ 6/May/2014 20:49:30] IN_CREATE/var/tmp/etilqs_SqorfaOvdiBaBI7
[ 6/May/2014 20:49:30] IN_DELETE/var/tmp/etilqs_SqorfaOvdiBaBI7

The -c <action> parameter tells iWatch to respond to events. To avoid all these parameters from hell, a configuration file, as shown in Figure 1, seemed to be a better option. The exciting part of the configuration is in the <path> tag. Here type = recursive tells iWatch to include directories below /source as well.

Figure 1: iWatch can be controlled better by a configuration file than at the command line. The directories to be monitored must be added to the <path> tags.

In case of a filesystem event, the mechanism starts the /home/charly/bash/ shell script. iWatch passes in the %f variable to the script. The variable resolves to the full path of the file that has changed. The script, in turn, is a lean two-liner:

rsync -a --delete $1 /dest1/$1 &
rsync -a --delete $1 /dest2/$1 &

This method works quite well as long as the number of events to be processed does not increase exorbitantly. If it does  – such as when syncing a six-digit number of very small files that the server writes to disk at maximum speed on the plate – you could experience a considerable number of queued rsync processes. Not that this would ever happen to me <cough>!

Charly Kühnast

Charly Kühnast is a Unix operating system administrator at the Data Center in Moers, Germany. His tasks include firewall and DMZ security and availability. He divides his leisure time into hot, wet, and eastern sectors, where he enjoys cooking, freshwater aquariums, and learning Japanese, respectively.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • iWatch

    Why wait for cron? iWatch monitors critical files and directories in realtime. This handy Perl script then notifies the user or runs a configurable command when change occurs.

  • Charly's Column: Pulse

    Equal treatment, as sys admin Charly so boldly proposes, should be the norm. What he really wants is a free tool to sync user data across multiple computers.

  • Charly's Column

    While cron doggedly keeps to a fixed schedule, Incron monitors directories and runs commands when changes occur.

  • Detecting Intruders Intro

    If you think your systems are too obscure for an attacker to worry about, think again. Today’s intruders are happy for any victim.

  • Live Sync with lsyncd
comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More