#ifdef linux

Lots of goodness in this release (explanatory posts to follow): upstart-local-bridge : New bridge for starting jobs on local socket connections. upstart-dconf-bridge : New bridge for Session Inits to react to dconf/gsettings changes. upstart-dbus-bridge : New ' --bus-name ' option to allow bus name variable to be included in dbus-event(7) . New " reload signal " stanza to allow jobs to specify a custom signal that will be sent to the main process (rather than the default SIGHUP ). Inclusion of Session Init sample jobs. Re-exec fixes for handling chroot sessions. Shutdown fix for Session Inits. New python3 module and accompanying integration test suite for testing Upstart running as PID 1 and as a Session Init (privileged and non-privileged). The Upstart cookbook has been updated for this release.

I've started a long-overdue update to the Upstart Cookbook for Upstart on Debian. Look out for the Debian swirl! :-) http://upstart.ubuntu.com/cookbook

A while back I though, "wouldn't it be great if the Ubuntu release schedule could be accessed as some form of web service?" That would allow all sorts of fun scripts to be written. Yes, you could write code to parse the wiki page, but I think the technical term for that is "gross". However, there is now a much simpler alternative in the form of distro-info . If you've never used this awesome tool written by Benjamin Drung you've been missing out! It can tell you all sorts of interesting information. A few examples... Examples of how to use distro-info What is the current development release on the system I am running on? $ distro-info --devel saucy What is the current Debian development release? $ debian-distro-info --devel sid What are the currently supported Ubuntu releases? $ ubuntu-distro-info --supported lucid precise quantal raring saucy What's the latest Ubuntu LTS release? $ ubuntu-distro-info --lts precise What's the c...

Vorlon and I will be giving a talk on Upstart ( 'Upstart in Debian' ). So if you'd like to learn more about the awesome next-gen event-based init system, please drop by!

As of  Upstart 1.6 , restarting PID 1 is supported without losing state. So as soon as you get an update to either Upstart itself or one of its dependent libraries in Ubuntu, you'll be running the new version automatically, without the need for a reboot. But what about User Sessions ? Are they "second-class citizens"? Of course not! When PID 1 restarts, all the running Session Inits will automatically restart too . You won't notice this of course as your desktop session will continue to run and be fully functional but you too will be running the latest version of Upstart. How does this work? When an instance of Upstart has restarted, it signals this fact over D-Bus. From the user perspective, the upstart-event-bridge , listening to the system instance of Upstart running as PID 1, will generate a " :sys:restarted " event when it detects the restart. This in turn will cause the session job  /usr/share/upstart/sessions/re-exec.conf  to run. And that job re...

Overview Ubuntu Raring now includes Upstart 1.8 . Upstart 1.7 and 1.8 combined mark a major milestone since they bring the proven power of Upstart to the user as never before: not only is Upstart now managing the system, but it is also capable of managing the default Ubuntu user's desktop sessions too. Why? Question:  Why reuse a system facility at the user level in this way? The modern Linux desktop environment is a very dynamic one: users start and stop applications, switch workspaces, search the dash, adjust personal settings in the panel, connect to different networks, hot-plug USB devices and so on. All of these activities can be represented by "events". Stepping back a second, recall that Upstart was written  from the outset  to take advantage of  the dynamic nature of a modern Linux system . Long gone are the days when a system booted serially. A modern Linux system abounds with "events" from all sorts of different sources: The user plugs or ...

It's a well known principle of software engineering that the earlier bugs can be caught, the lower the overall cost. As such, testing needs to happen at every level. Once your project is at the coding stage, the earliest form of testing is on the code itself , not on the binaries the compiler produces. We run a variety of tools over critical codebases such as Upstart and Whoopsie regularly to identify issues well before they "escape into the wild". These tools include Coverity Scan  (see the list of projects already using it ). If you really care about your code and you are involved with a C, C++ or Java project, I'd strongly encourage you to take a look at this awesome tool. If you aren't directly involved in such projects, try contacting those running them and suggesting they use Coverity. The Coverity Scan service is entirely free for OSS projects. You will need to register to obtain an account and then download the client analysis tool. Once setup, a...

Hot on the heels of Upstart 1.7  comes Upstart 1.8 which includes two interesting new features: The File Bridge Upstart now provides the upstart-file-bridge , a bridge that allows jobs to react to file events. Here are a few examples: Start a job when file is created, modified or deleted: start on file FILE=/run/app.pid Start job when file is created (only): start on file FILE=/run/app.pid EVENT=created Start job when any files within a directory are created, modified or deleted: start on file FILE=/var/log/ Start job when files that match a glob pattern are created in the indicated directory: start on file FILE=/var/crash/*.crash EVENT=created Even better, this bridge is available to both system jobs and users session jobs. See upstart-file-bridge(8) and file-event(7) for further details. The GUI The upstart-monitor tool covered in a previous post has also been added to the release. This allows you to see what events Upstart is emitting and ho...

The Upstart Cookbook has now been updated to take into account all the goodness that landed in Upstart 1.7. There are quite a few changes so if you'd like to review the diff, it's here .

It didn't quite make it into the release, but we now have a very basic Upstart GUI that should appear in Ubuntu along with the Upstart 1.7 release soon. What is it? upstart-monitor is a simple application that shows Upstart events as they are emitted. It can be used to view both system-level events and also session-level events when Upstart is running as a Session Init. It requires Upstart 1.7. What can I use it for? The tool allows you to see events as they occur which is an aid to understanding. It also helps with writing new jobs since, if you are not sure which event to use, provoke the scenario you want, then just copy the appropriate event that appears in upstart-monitor to your .conf file (more details on this in a future post...). How do I use it? Just start it to see events being emitted: If you'd prefer a command-line version, run it with the ' -n ' option: Where can I get it? If you can't wait for it to land in Ubuntu, you ca...

After a lot of testing, we have today landed Upstart 1.6.1 in Ubuntu Raring with " stateful re-exec " goodness. What this means is that for all future Upstart upgrades, no reboot is required to make use of the newly-installed version: Upstart will restart itself with no interruption to service such that existing jobs will continue to run. Additionally, it means that an upgrade to any of Upstarts dependent libraries (such as libc and libnih ) can also trigger Upstart to restart itself so that it will automatically start using those new library versions whilst maintaining continuity of service. For those of us who dislike downtime and want to remain current, this is known as a "win" ;-)

New Upstart Release Today we released Upstart 1.6, which includes the " stateful re-exec " feature, allowing Upstart to continue to supervise jobs after an upgrade of either itself, or any of its dependent libraries: https://launchpad.net/upstart/1.x/1.6 This will be available in Ubuntu Raring very soon. Thanks to all the contributors: A.Costa Colin Watson Eric S. Raymond Jason Conti Loïc Minier Steve Langasek   Like to get involved? If you'd like to get involved with Upstart Development... Take a look at the ideas page Study the Hacking Upstart Together presentation Read the Upstart Cookbook Read the code Subscribe to the mailing list Join us on #upstart on freenode Here's an early draft of what's planned for the next cycle: https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions If you're interested in contributing, let me know! Update on Upstart in Debian ... But wait - there's m...

The Upstart Cookbook now contains most of the UDS workshop " Hacking Upstart Together " in the form of a vastly-expanded development section: http://upstart.ubuntu.com/cookbook/#development-and-testing Also covered is the "friendly menu" for Upstart Developers: http://upstart.ubuntu.com/cookbook/#upstart-menu-sh

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

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.

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.

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