pitter patter on the keyboard

GRUB2 is highly customizable and feature-rich, however it is a bit of a nightmare if you configure bootloaders regularly. Unfortunately GRUB 0.97 doesn’t support ext4 and – if you were an idiot like me – you might have set up your new dedicated with an ext4 /boot. Now, you have neither the time nor patience to re-install and need to make Xen go.

First, copy your Dom0 .config and kernel to /boot/. /etc/grub.d/20_linux_xen picks up on the CONFIG_XEN_PRIVILEGED_GUEST=y variable.

# cp /usr/src/linux/arch/x86_64/boot/bzImage /boot/kernel-dom0
# cp /usr/src/linux/.config /boot/config-dom0

Next, remove the executable flag from /etc/grub.d/10_linux or you will end up with three or four entries that boot straight to the Dom0 kernel without the hypervisor.

# chmod -x /etc/grub.d/10_linux

To add kernel boot parameters to your grub.cfg (as generated with grub2-mkconfig and 20_linux_xen) add these lines to your /etc/default/grub file:

GRUB_CMDLINE_LINUX_XEN_REPLACE="max_loop=128"
GRUB_CMDLINE_XEN="dom0_mem=512"

The former will place your boot options on the Dom0 kernel’s module line. The latter will place boot options on the xen.gz hypervisor’s kernel line.

Now, generate your new configuration:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Once the config file has been written, determine the position of the Xen hypervisor entry and update GRUB_DEFAULT in /etc/default/grub.

Install GRUB2 to your MBR(s) as necessary:

# grub2-install /dev/sda 

In this article we covered finding the largest files on a file system. Often this doesn’t account for the whole story when you scramble to clear up a filled volume; for as long as a process exists which has opened a given file that file will – even if apparently deleted – continue to exist until that process releases it.

This strategy has numerous benefits, not the least of which is the ability to upgrade libraries and binaries in-place. The software which relies on these libraries continues to run using the version it was started up with, preventing crashes due to version mismatching and giving you time to update the binaries themselves before restarting for minimal downtime.

Unfortunately, this makes things slightly confusing. You may have deleted a 400MB log file expecting to have immediately freed 400MB but df is still reporting that your file system is full. If you know what process “owns” that file it’s usually a simple matter of restarting the corresponding software. You won’t always know this, however, and that’s where some clever use of the lsof command comes in handy.

lsof spits out the size and owner of all open files. If you already know the file you’re looking for it’s as simple as grepping the output:

# lsof | grep "/var/log/zimbra.log"
COMMAND     PID    USER   FD      TYPE             DEVICE    SIZE/OFF       NODE NAME
rsyslogd   1285    root    6w      REG             202,17    65125680    2031675 /var/log/zimbra.log

If we pipe lsof‘s output through awk and sort we can get some useful, human-readable information. This command will give us the 10 largest currently open files, the size of the files in megabytes and the name of the process(es) using them:

# lsof / | awk '{if($7 > 1048576) print $7/1048576 "MB" " " $9 " " $1}' | sort -n -u | tail

For example:

498.804MB /var/log/zimbra.log zimbra

To view more or less than 10 results add -n X where X is the number of lines you would like to see to the tail command.

I’ve been having trouble with XCache’s datastore lately and was prompted to revisit my SHM/tmpfs File-Based PHP Cache/Datastore in RAM strategy.

I mounted a 256MB tmpfs slice like this:

none                    /mnt/ram        tmpfs           defaults,noatime,size=256M      0 0

Somehow, after the storage was exhausted the number of files kept increasing.

$ watch "ls | wc -l"

To my surprise new, empty files were being created with a random string attached to their name.

36588.posts.object.ychanKJYGF
36588.posts.ychanPIUGN

Interestingly, while these non-files continued to accumulate the reported amount of storage used by tmpfs never changed. One might expect these file entries to be taking up some amount of space, somewhere.

I’ve done as much research as time will permit but haven’t found the purpose of this behaviour. Since the altered file name and lack of content makes these files void as far as my fcache implementation is concerned it highlights the importance of thorough garbage collection.