Posts

Showing posts from April, 2013

Observing the initial LXC environment using procenv

If you're interested in seeing the initial environment inside an LXC container, here's how: Install procenv inside the container: $ sudo apt-get install -y procenv Shutdown the container: $ sudo shutdown -h now Boot the container (mine is called " raring " in this example) like this: $ sudo lxc-start -n raring --console-log /tmp/lxc-console.log \ -- /usr/bin/procenv --file=/dev/console --exec \ -- /sbin/init --debug View the /tmp/lxc-console.log logfile in the host environment. Note that those two sets of non-option double-dashes are required; the first tells LXC to treat what follows as a command to run after the container starts (in this case procenv ), and the second set tells procenv to treat what follows as a command to run after it has finished running (in this case Upstart ( /sbin/init :-))!

Byobu Bling with Unicode Custom Indicators

Image
Introduction In these heady times of almost daily advances in UI pizzazz, you could be forgiven for thinking the terminal is somewhat of a dead-zone when it comes to excitement. Oh how wrong you would be though...! If you've never used  Byobu ,  Dustin's  awesome text-based window manage, sudo apt-get install it without delay to be bathed in pure terminal goodness. As shown below, byobu comes with a whole host of standard indicators, allowing the display of useful snippets of information. The indicators are minimal out of terminal-width real estate necessity, but that's also their strength - they provide just the details you really care about in a tight ASCII format. And they're cute of course :-) However, byobu has a well-kept secret: when running with the tmux backend, it supports Unicode indicators. So with the proviso that you are running " byobu-tmux " rather than " byobu-screen ", you can squeeze down those indicators even further

Stateful re-exec for Upstart Sessions? You bet!

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

Upstart User Sessions in Ubuntu Raring

Image
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

Coverity static analysis for C, C++ and Java code

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