#ifdef linux

Procenv 0.27 has been released. This release introduces a raft of new features... IPC  It is now possible to display details of the following IPC mechanisms: message queues semaphores shared memory Alas, this feature is not available on BSD's as yet partly since there appears to be no documented way to query these mechanisms. Output Categories The introduction of the IPC categories brings the total number of output categories to 32: meta arguments capabilities cgroups clocks compiler confstr environment file descriptors libraries limits locale misc message queues mounts network oom platform process ranges rusage semaphores shared memory signals sizeof stat sysconf threads time timezone tty uname Highly-Structured Output The code that handles procenv has been completely rewritten so that all output is highly structured. So, rather than displaying file descriptors like this: $ procenv --fds fds: fd 0: terminal=yes ('/dev...

What changed? Sometimes, when using VCS systems such as bazaar, there is a tendency to forget to perform the necessary 'book-keeping' for those not using it because you get so focused on the tooling itself. Most VCS systems expect the author to provide a brief explanatory message per commit. This log is invaluable since it (hopefully!) provides insightful context into the programmers intentions. However, that meta-data is only available to those with a copy of the branch/checkout/stream/view or whatever your VCS calls it. But what about those who only come into contact with the project via release tarballs for example? I'm thinking specifically of changelogs. Debian and Ubuntu provide the incredibly useful ' dch ' (aka debchange ) tool which synchronises the VCS commit message with the latest ' debian/changelog ' file entry. But what if you're not working on a Debian project? When you're working on a fast-paced project, or just working at a...

Changes: expanded man page, more sizeof types shown and resource usage details added. Code is available here: https://launchpad.net/procenv If anyone is interested in contributing patches for the following, let me know: code to show network details. support for other platforms (I'd like to add AIX, HP-UX, Solaris, i5O/S, MVS/zO/S, VMS) but no longer have access to such systems).

Quiz How many attributes of a processes "environment" can you think of besides its environment variables? I'm using the term "environment" in a very loose sense here to mean "any system or process level attribute that can be queried via system calls or library calls (or " /proc -picking ") that affects a running process". I'm also including details of the process itself and details of the program that came to be a running process. We're not talking about installed packages or application configuration files in /etc here, but purely low-level program, process and system meta-data. I've got over 20 items in my list excluding environment variables. Whilst you're pondering on that... Compare and Contrast If you've been involved with computers for any appreciable length of time, chances are you have come across the scenario where some program fails to run in a particular environment, but works "perfectly...

Have you ever wanted to download a Debian  package from an Ubuntu system? Well you are not alone: hidden away in the wonderful " ubuntu-dev-tools " package is the tool for you - the excellent pull-debian-source , written by  tumbleweed . This is a really useful tool which is also fast ! $ sudo apt-get install -y ubuntu-dev-tools $ pull-debian-source hello pull-debian-source: Downloading hello version 2.8-1 pull-debian-source: Downloading hello_2.8.orig.tar.gz from ftp.debian.org (0.665 MiB) pull-debian-source: Downloading hello_2.8-1.debian.tar.gz from ftp.debian.org (0.006 MiB) dpkg-source: info: extracting hello in hello-2.8 dpkg-source: info: unpacking hello_2.8.orig.tar.gz dpkg-source: info: unpacking hello_2.8-1.debian.tar.gz Or, to download the at package from the sid release: $ pull-debian-source at sid pull-debian-source: Downloading at version 3.1.13-1 pull-debian-source: Downloading at_3.1.13.orig.tar.gz from ftp.debian.org (0.117 MiB...

Job Logging in Upstart The big Upstart feature in Ubuntu Precise is "job logging" (in fact, it turned out to be a significantly bigger feature than we'd originally envisaged :-). This had been a wishlist item for some time and a lot of folk were very keen to see this implemented. All system jobs now have their stdout and stderr logged automatically  by default to a text file in directory  /var/log/upstart/ . Why did we make this the default? Surely daemons and services don't generally write any output? True, but when they do produce output, it is worth capturing since it has a very high chance of being an error message. And errors should not be ignored. For jobs that do not produce any output, there is minimal overhead and of course no log is written. The logger actually uses pseudo-ptys just like  script(1) , xterm(1) , expect(1) ,  screen(1)  et al . This is advantageous for a number of reasons, but from the logging perspective the biggie i...

Introduction The NIH Utility Library ( libnih ) is a small, efficient and most importantly safe library of general purpose routines. It was written by Keybuk so you can be assured that it is extremely elegant, well-designed, well-tested (includes 2863 tests currently!) and well-written. NIH is used by Upstart, the event-based init daemon which is used by: Ubuntu Desktop Ubuntu Server Ubuntu Cloud RedHats RHEL 6 Chromium OS  (and Chrome OS) That's a lot of deployments of Upstart and NIH around the world!! (And we're not even including mobile device operating systems in that list). But why not just use glib I hear you ask? Well, glib is a very large library whereas NIH is small and designed for low-level daemons and systems which may be resource-constrained. Also, lets not forget that NIH, like Upstart , comes with a very comprehensive test suite so bugs are rare. Other reasons to use NIH: It handles garbage collection for you That's rig...

Linux provides a plethora of useful trace tools. Two of the most command and the most useful being strace , for tracing system calls and ltrace that traces library calls (it can also trace system calls). There a quite a few other exotic and experimental tools available but there seemed to me there was a gap in the coverage... Recently, I had cause to need an application-level trace. For the problem at hand, I didn't care a hoot about system calls or indeed library calls -  I wanted a trace log file that showed a call to " main ", and then entries for all the other functions I had written in the application . A quick search around didn't reveal much, but some lateral thinking saved the day. What tool can display application-level function names? gdb of course! The question was how to coerce it into working as a trace tool. It's actually very simple. What you do is this: Set breakpoints on every function in your application. Make GDB display the frame wheneve...

I use the mighty vim editor for most of my coding. I have a heavily customized setup which has evolved over quite a few years. However, it is by no means a static setup as I keep finding new scripts and tricks (and of course Bram keeps on adding extra goodness with each release). Recently, I was hacking through a lot of C code containing lots of debug cruft (log function calls, commented out bits and pieces, etc). The problem was I couldn't get a feel for the code as all the debug was too distracting. The question popped into my head, "can I hide all this stuff?" A number of folk have come up with ways to "hide" the data you don't want to see in Vim using folds (" :help fold " in Vim). However, that wasn't what I wanted as folds also introduce their own "visual noise". I just wanted this stuff gone . What I came up with is a complete hack, but it suited my purpose rather well: I changed the colour of the regex's matching the ...

One particularly useful piece of information I've been wanting to add to the Upstart Cookbook for a while now is the upstart-events(7) manual page. This page shows a summary of the "well-known" Upstart events that are provided on an Ubuntu system.  However, as show in the link, formatting this data is tricky due to the number and complexity of the tables. I wondered about converting the troff source to some other format (maybe DocBook) and using that source to generate both the man page and the same data in a format suitable for inclusion in the Upstart Cookbook. However, DocBook seemed a bit heavy weight and I'm not convinced it could handle it (tell me if I'm wrong!) My preference actually is to keep the source as troff since: troff+tbl is a very rich language which provides a lot of control. I want full control over the width of the tables The man page may look a little "cramped". I could have padded it out and made it a little easier ...

Occasionally, after committing some changes on a bzr branch, I'll come back to it and want to make further changes. So, I'll have done something like this: $ bzr commit $ # Oops! Forgot to update foo.c. Let's do that now... $ vim src/foo.c $ bzr status modified: src/foo.c But rather than creating a second commit for the newest changes, I'll want to combine those new changes and the changes in the latest commit into a single new commit. How do we do this? With bzr its easy: $ bzr log -l1 > /tmp/commit.log # save the latest commit log entry $ bzr shelve --all -m "latest changes" # save the latest uncommitted changes $ bzr uncommit --dry-run # check its going to work $ bzr uncommit # undo the last commit $ bzr unshelve --dry-run # check if its going to work $ bzr unshelve # apply the latest changes to the working directory $ bzr commit ...

Yesterday, whilst hacking on a particularly large Upstart C file in the awesome vim editor, I inadvertently 'put' a huge amount of data, caused by my mis-specifying the marks when I had originally yanked the text. Still unaware of the problem, I then compounded the problem nicely by continuing to make further changes to the file and dug myself an even bigger hole by saving the file and exiting vim. Attempting to compile the now totally invalid code resulted in a seething mass of mocking gcc warnings until it eventually gave up in disgust. Thankfully, I was taking regular backups with rsnapshot and I had the bzr branch history to fall back on. But it still took some time to perform the 3-way diff and get back to my latest changes. Later on, we had our weekly IRC meeting in #ubuntu-meeting . I use irssi and as I pasted my weekly status update, since I was pasting more than a single line, irssi gave me a helpful warning and the option to either proceed, or abort the mult...

If you run any chroot environments such as schroot, they will generally set your prompt as a reminder that you are actually running within a chroot. For example with schroot, I have: $ schroot -c oneiric (oneiric):~$ echo hello hello (oneiric):~$ exit $ When you're in the chroot, you get the chroot name prepended to the prompt (here " (oneiric) "). But if you play tricks with your prompt variables ( PS1 , PS2 , etc) using maybe the magic bash PROMPT_COMMAND variable, you need to take care. I use screen , tmux , or byobu so need to take twice the amount of care since: I modify my prompt quite extensively I only have 1 window which multiplexes all my terminals (it's easier to make a mistake :) The problem is that if you forget which window you're in, you may end up modifying the wrong environment - installing packages in a minimal chroot rather than in your main (non-chroot) environment, or maybe trashing your live system rather than a throw-away chroot...

In my spare time, I like to play guitar. I also enjoy learning guitar solos the "hard way" - by working out the notes, slurs, slides, bends, taps, mutes and harmonics by ear. However, some solos -- no matter how many times you listen to them -- are just too fast to "reverse engineer" as your brain just isn't able to distinguish between individual notes. If you simply slow down the solo, you'll be able to hear the individual notes, but you'll be changing the pitch of the notes such that a C 4 or " middle C " might sound like a B 4 . That's not much help as the music will sound different. What we need is a way to slow down the notes, but retain their original pitch. Since I run Ubuntu Linux , I have access to a true "Embarrassment of Riches" when it comes to free and high quality music software. This post outlines some of the methods I've found to slow down guitar solos using different tools. So, if you're wanting t...