The default configuration of the X server in Debian keeps a log of all the console output of the programs a user runs from their X session. It also keeps this log indefinitely. This is quite clearly a design mistake, because even ignoring badly behaved programs (those which are needlessly noisy are indisputably buggy), enough legitimate errors will eventually eat your disk. Plus the unjustifiable assumption that all programs out in the wild will be well-behaved, which is a nice hope but contrary to reality.

Sadly, this behaviour is also an ancient bug that has been, it would seem, forgotten about.

Anyway, here's a relatively simple method to fix that. As root, edit /etc/X11/Xsession. Just below the ERRFILE=$HOME/.xsession-errors line, add this:

ERRFILEOLD="$ERRFILE".old

if [ -f "$ERRFILE" ]; then
set +e
mv -f "$ERRFILE" "$ERRFILEOLD" 2> /dev/null
set -e
fi

Each time the user logs in, the old .xsession-errors log file will be moved to .xsession-errors.old (overwriting anything already with that name), and a new one created. Thus it ensures that the file doesn't grow indefinitely, so long as the user logs out and back in at some point.

Read this post

For some time, I've been happily using Unison in conjunction with my Android phone's USB mass storage function to synchronize files between my phone and my desktop. It was simple: I'd plug in my phone with USB and enable the SD card to be used as a mass storage device, then mount it in Linux and run Unison as if the phone was a local folder (with appropriate tweaks to support the FAT filesystem).

Alas, my phone was getting on in years (or months, as it is in tech), and with support long dropped and capacity nigh exhausted, I had to upgrade. With my new phone I've been promoted to the “new hotness” that is Android 6 Marshmallow, but one of the functions that was dropped along the way was the ability to expose the SD card as mass storage over USB. Admittedly it wasn't a perfect solution, requiring unmounting the SD card within Android itself while using it over USB, but the current approaches introduce their own deficiencies. In any case, my previous workflow wasn't going to work anymore.

Of course I didn't want to stop using Unison, or have Unison re-copy everything, or even merely re-scan everything. I [...]

Read this post

Recent events gave me cause to consider my personal data backup and redundancy strategy for my Debian installs. Or, more accurately, it caused me to amend my half-baked and semi-implemented existing approach so that I won't lose data or have to reconfigure things from memory/scratch in the event of a hard disk failure.

My present “backup” approach is really somewhere between a time-limited backup and redundant storage. Essentially, I use Unison to synchronize my home folder (with certain sub-folders ignored, e.g. certain git repositories, config and thumbnail cache folders) between my desktop and my netbook. I have to run Unison manually, so I end up synchronizing my data every week, give or take. This effectively kills two birds with one stone: I get to have local copies of my important data as up-to-date as my last sync for when I'm on the road and using my netbook, and the delayed redundancy gives me some protection should anything go wrong with either hard drive.

I'll be clear: what I'm doing here is something not-quite a backup (safe storage of historical editions of files) and not quite proper redundancy (up-to-date duplication of data). The frequency of synchronization is the key [...]

Read this post

I recently upgraded my home desktop's hard drive, because the old one was getting a bit full. Googling for instructions about how to transfer an existing system onto a new drive, many posts suggest using the cpio command, and that's what I tried. While this command does the job for the most part, there is one caveat which I encountered that makes cpio not the ideal tool to use.

Don't use cpio to clone filesystems. Why? Because GNU cpio doesn't support access control lists (ACLs) or extended attributes (xattrs).

Using cpio will end up a little screwy in some edge cases because of this. The particular case I ran into involved folders in /media that are managed by udisks2. udisks2 creates personal mount folders under /media with tailored ACLs to help properly manage permissions for permission-capable filesystems mounted by regular users. If you already have one of these personal mount folders, cpio will break it, and you'll lose permission to view any filesystems that you mount under it henceforth.

A better solution than cpio: rsync -caHAX src/ dest/

(Edit: Add -v to also see progress.)

As a side-note: if applicable, don't forget to run sudo dpkg-reconfigure grub-pc and set the [...]

Read this post