We've all run into problems like this:

$ echo 12000 > /proc/sys/vm/dirty_writeback_centisecs
-bash: /proc/sys/vm/dirty_writeback_centisecs: Permission denied

The command fails because the target file is only writeable by root. The fix seems obvious and easy:

$ sudo echo 12000 > /proc/sys/vm/dirty_writeback_centisecs -bash: /proc/sys/vm/dirty_writeback_centisecs: Permission denied

Huh? It still fails. What gives? The reason it fails is that it is the shell that sets up the re-direction before running the command under sudo. The solution is to run the whole pipeline under sudo. There are several ways to do this:

echo 'echo 12000 > /proc/sys/vm/dirty_writeback_centisecs' | sudo sh
sudo sh -c 'echo 12000 > /proc/sys/vm/dirty_writeback_centisecs'
echo 12000 | sudo tee /proc/sys/vm/dirty_writeback_centisecs

This is fine for simple commands, but what if you have a complex command that already includes quotes and shell meta-characters?

Here's what I use for that:

sudo su <<\EOF
echo 12000 > /proc/sys/vm/dirty_writeback_centisecs
EOF

Note that the backslash before EOF is important to ensure meta-characters are not expanded.

Finally, here's an example of a command for which I needed to use this technique:

sudo sh  << \EOF
perl -n -e '
use strict;
use warnings;
if (/^([^=]*=)([^\$]*)(.*)/) {
  my $pre = $1;
  my $path = $2;
  my $post = $3;
  (my $newpath = $path) =~ s/usr/usr\/local/;
  $newpath =~ s/://g;
  print "$pre$newpath:$path$post\n"
}
else {
  print
}
' < /opt/rh/ruby193/enable > /opt/rh/ruby193/enable.new
EOF

We have app servers with smallish local file systems and application data mounted over NFS.

Sometimes I want to find all files matching a particular set of criteria but don't want to traverse the NFS mounts.

Here's how to do it:

find / -group sophosav -print -o -fstype nfs -prune

Ordering is important, as is the explict inclusion of -print. If you omit this, it will print the name(s) of the NFS mounts as well.

Change start location (/) and criteria (-group sophosav) to suit your own purposes.

Since my recent post about converting between unix time and date, it has come to my attention that Unix epochs are in seconds while Java epochs are in milliseconds. That means that you need to scale the epoch values by a factor of 1000 to convert between Unix and Java format.

So, date -u -d '2011-04-26 15:00:00' +%s gives 1303830000 (Unix epoch) which becomes 1303830000000 (Java epoch)

Converting the other way, the Java epoch 1306934061475 is 1306934061.475 in Unix format. date -u -d @1306934061.475 gives Wed Jun 1 13:14:21 UTC 2011 (assuming a UTC epoch).

I've recently been looking at reporting in OpenNMS and it seems that some of the reports require date ranges to be specified in unix time. Now, I don't know about you, but my mental ability to translate "April 26, 2011 15:00 UTC" to 1303830000 is sadly lacking. So, here are some useful commands to convert from unix time to date and vice versa:

Date to Unix time:

# current timestamp
date +%s

# specific timestamp
date -d '2011-04-26 15:00:00' +%s

# same thing but UTC
date -u +%s
date -u -d '2011-04-26 15:00:00' +%s

Unix time to date:

date -d @1303826400

# same thing but UTC
date -u -d @1303826400