Posts Tagged ‘logging’


Sunday, December 18th, 2011


tmux is a terminal multiplexer, resembling screen and seemingly straight-forward to configure.

Now, those of you paying attention will know that I use wmii, a tiling window manager, and you may ask what the difference is between creating one big tmux window and laying out a couple of terminals in that, or letting wmii place those terminals beside each other itself.

The answer is that for most instances, wmii will be enough, but just a little while ago I discovered a killer feature (one which makes me wish that tmux was available at work), namely the abililty to perform:

C^b:setw synchronize-panes

(demonstrated here) which simply outputs whatever you type into one of the terminals, into all the other terminals in this tmux instance as well.

How is this useful? If you have a couple of servers, on which you need to execute the exact same command, you simply start tmux, create a terminal for each server (and log in to that server) and then ask tmux to synchronize the panes, and then you type in your commands.

(Yes, this could probably be easily solved with a bash for-loop as well, depending on the amount of commands and their complexity)

Stupid Shell Tricks

I’ve known about ^foo^bar for a while (i.e. you type
$ some-command wif a typo
and you then do
$ ^wif^with
to have the shell replace the first instance of that typo with the correct spelling (hopefully ;D)

But, this is really only good for typos or when there is ONE instance to replace. ^foo^bar won’t replace EVERY foo with bar, only the first occurrance. Which is sometimes now what you wanted.

Enter !!:gs/foo/bar which replaces ALL instances of foo in the previous command, with bar, and re-executes it. Thanks to for that.


I think I have touched upon this before, but here we go anyway: it is possible to export an environment variable called “LESS” and less will read this and determine any runtime special behaviour based on the contents of the variable.

I am currently trying out export LESS='FiX' where F makes less exit if the contents are short enough to all fit on the screen, i is for case-insensitive search and X for stopping less from sending the termcap initialization and deinitialization strings.

This means that when less exits, it won’t clear the screen (which would be a bummer if using F and less:ing short files…)


A pretty interesting read about how one could “work in the cloud.” I would have chosen other hardware/software (except for vim of course) but to all his/her own, right?

This sounds as if it could be useful for making sure that your logs are really your real logs. Makes sense, right? ;)

From the reptyr readme: reptyr is a utility for taking an existing running program and attaching it to a new terminal. Started a long-running process over ssh, but have to leave and don’t want to interrupt it? Just start a screen, use reptyr to grab it, and then kill the ssh session and head on home.

I am apparantly not the only one to get the idea of describing their software stack.

A pretty cool more-utils command, ifne, which continues execution of the rest of the command, iff data was coming into ifne’s stdin.


Strange things you find out about your system half past six on a Thursday morning

Thursday, May 28th, 2009

Woke up somewhere around 0500 hours, heartburn… couldn’t go back to sleep so landed in front of the computer. Read an article (in Swedish) at about EU and the Telecoms-package nonsense. Apparently cookies are still unsafe… uh-huh.

There was a comment to that article about Local_Shared_Objects which caught my eye, and after having examined my ~/.macromedia-directory I could conclude that Flash stores its “cookies” there. To my surprise they took up quite some space, so I removed those domain-directories which lay inside the “random-id” directory.

For some reason, while Googling in order to ascertain whether it would be safe to remove the directories (I found nothing that indicated it would be safe, nor that it wouldn’t be safe), I found a post about an Ubuntu user who needed help cleaning up his “filled-to-the-brim” partition, and asking what he could remove.

Some responses told him to set his eye on /var/log among other places, and realizing that it was quite some time since I did that myself, I too headed for /var/log

And I started chopping away at the gzipped archive files there (to be honest, it was on fell “sudo rm *.gz” swoop, but who is counting?)

du -sh . indicated there was still someĀ  309 Mb of “stuff” in /var/log (down from 312 Mb or something) so I was not impressed. What was taking up all that space?

Digging a little further I finally zeroed in on the guilty party. /var/log/acpid occupying 297 Mb of my harddrive. Running tail on that file a couple of times made me realize that it made entries into that log more than once every second…

So just to ensure that this wasn’t all just some stupid me poking around the system, spur of activity logging, I told grep to find all lines containing the string “May 27″ (which now in retrospect would match previous years May 27 as well, which means I could have been greping lines as far back as May 2007, this is a Feisty-box, although I am pretty sure that it took me a while after Feisty was released for me to give up Edgy, all in all, I don’t think I had Feisty installed by May 27th 2007, so two years worth of logs) and counted the lines of that outputĀ  grep ‘May 27′ .acpid | wc -l, which returned around 1.2 million hits.

I assume an equal distribution of entries per year, so 600.000 entries made yesterday. 600000 (log entries) / 86400 (seconds in a day) is almost 7 writes a second!

This was clearly not acceptable. I hit Google again, what would be the best way to kill all acpi logging? The launchpad bug report I found indicates that the bug is closed, having been fixed, which is good, once I upgrade when my harddrive goes to… whatever place harddrives go when they have served their time, this will not come back to haunt me.

But Feisty isn’t being bug fixed anymore, so how would I do it?

By adding the arguments “-l /dev/null” to whatever script that start the acpi daemon (acpid). I.e. /etc/init.d/acpid

Again, solutions offered in the forums seemed to target a different version (probably older) than Feisty, as I could not find a line containing $ACPID_BIN = /sbin/acpid

I did however find out that my version used start-stop-daemon to umm… start the daemon. Which takes the flags –exec [arg] and -c [args] (arg being the path to a daemon to start, and args being the arguments to pass to the daemon)

Very nice!

start-stop-daemon –start –quiet –exec /usr/sbin/acpid — -c /etc/acpi/events $OPTIONS


start-stop-daemon –start –quiet –exec /usr/sbin/acpid — -c /etc/acpi/events $OPTIONS -l /dev/null

I stopped and restarted the the acpid (since the restart sequence looked a little different and I didn’t want to muck with that, I know my own illiteracy and incompetence ;)), killed off the acpid log, and my /var/log is now down to 12 Mb in size all in all.

Reading further in the bug report it would seem that this little acpid “I’m gonna log the shit out of you” behaviour is, to some extent, connected to the laptop harddrive-killing bug. Thankfully my harddrive seem to have survived that bug quite well (probably due to my early hacking of /etc/hdparm.conf as per this page).