#ifdef linux

If you missed the Hacking Upstart Together session at UDS-R in Copenhagen, here are the slides: http://people.canonical.com/~jhunt/presentations/uds-r/2012-10-31/upstart-development.pdf This gives a very gentle introduction to Upstart development and covers NIH, common gotchas and more. ... and if you'd like the LaTeX source.... http://people.canonical.com/~jhunt/presentations/uds-r/2012-10-31   We are always looking for new contributors and have some very interesting work lined up this cycle. So, if you're interested in contributing even a small patch or feature, please feel free to contact me or ask on the mailing list .

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...

My output utility (originally called ' out ' - see previous post ) is now available in debian sid as ' utfout ': http://packages.debian.org/sid/utfout

It didn't quite make quantal, but if you'd like to help test Upstart " stateful re-exec " support, there's a new build (Upstart version 1.5-0ubuntu10~jh20121015 ) in my PPA: https://launchpad.net/~jamesodhunt/+archive/upstart-testing/ We have so far added 60 new tests specifically for stateful re-exec support. The plan is to add this new feature to Ubuntu early in the "R" cycle, so please give it a test by installing the new test version (on a non-critical system! ;-) and running " sudo telinit u " to force Upstart to restart.

Intro Whilst writing the tests for the Job Logging feature in Upstart, I discovered that I needed some very specific job behaviour that was not easy to produce using any simple existing utility I could find. The Problem What I wanted was a utility that would produce specified amounts of data to either standard output, standard error or direct to the terminal without using shell redirection. The reason for eschewing the shell being that Upstart is clever and intelligently determines whether a shell should be involved. From a user perspective, that's fantastic, but for testing purposes, I needed to force Upstart down particular code paths where it would not for example automatically pass the job through a shell. In fact the constraint was even more restrictive; what I really wanted to do was this: Produce output (including null bytes) to stdout, stderr or the terminal without using any shell meta characters. Unless I used some extremely esoteric shell, that effective...

If you'd like to help out testing the new "stateful re-exec" feature of Upstart which we hope to land for Ubuntu Quantal, see the details here: https://lists.ubuntu.com/archives/upstart-devel/2012-September/001948.html In brief (more posts will follow), "stateful re-exec" allows Upstart to be restarted (or upgraded!) without rebooting your system. A basic restart or re-exec isn't difficult, but what stateful re-exec does is maintain Upstarts internal state over the re-exec such that it continues to track jobs and log job output. This is an early cut of the code so don't install it on any critical systems . Additionally, there are some caveats... https://wiki.ubuntu.com/FoundationsTeam/Specs/QuantalUpstartStatefulReexec#Phase_1_Limitations ... but we plan for that list to dwindle quickly over the coming days and weeks.

strace is an extremely powerful tool. But have you ever attempted to compare strace log files? That can get tricky. How about diffing multiple strace logs of multi-process applications? That can be a world of pain. So, I wrote a simple shell script to make a life easier. Then I decided to rewrite it in Python and life got even better :-) My reason for diffing multi-process strace logs was not to see where an application was failing (that's what debuggers are for) but more to understand the flow of program execution. So what follows may have a fairly niche audience. The script is pretty simple: it's just simplifies the log files to allow easier diffing. Specifically it: replaces all addresses with 0xADDR (or 0xNULL ). replaces all timestamps with HH:MM:SS . replaces all datestamps with YYYY/MM/DD . tracks PIDs and replaces each PID seen with a 1-based value (so the first PID seen will be assigned PID1 , the second PID2  et cetera). These simple changes turn out...