Scott James Remnant

Yesterday’s celebratory blog post demonstrated that Upstart is now able to supervise processes that fork into the background, as most daemons do. Now that the code has undergone a little more testing, and been pushed into the archive, it’s worth explaining a little bit more of the background as to the how, and why, we do this.

The why is easiest to answer first. Daemons are normally written to fork, usually twice; this detaches them from the terminal, process group and session that they were spawned from so that they remain running after the user logs out. The fork isn’t just mechanism though, over time a convention has occurred that means daemons don’t go into the background until their initialisation is complete and they’re ready to receive connections — if that’s their bag.

Simply adding an option to remain in the foreground might appear to eliminate the need to deal with the problem, but this also takes away the notification that the daemon is ready for use. Over time this signal can be replaced with other notifications: registering a known D-Bus name, or simply raising SIGSTOP; but these require code changes that need to be agreed with upstream first. Making code changes also assumes that we have the code. Whether we like it or not, sysadmins will often have the need to run proprietary daemons — or even simply older versions of software where the patch is too invasive.

So that’s why we have to do it, now how do we?

This is one of the reasons that building the service supervisor into init, rather than having it as a seperate process, makes sense. Init has a few special kernel-provided buffs, one of which is that orphaned processes are reparented to it. When you run a daemon from the command-line, the process is initially your child; it forks once and the parent dies, the new child is now orphaned, and thus reparented to init. (Most daemons now run setsid and fork a second time. This is to ensure that if they open a tty device, they don’t unexpectedly become its owner.) Init, like any other process, receives notification about its children through wait so will know when daemons terminate; the “must have” of supervision.

So if all daemons are our children we are notified when they terminate and why; we can compare their exit status or signal against a list of known good ones, and choose whether we need to respawn the dead job or mark it as stopped normally.

This isn’t enough though, all we get is the process id of the dead child. We still need to relate that back to a job somehow. One way to do that is to use waitid with the WNOWAIT flag, leaving the process on the table so we can examine /proc to find out more about it. This seems like quite a reasonable approach, we can then match a process to a job by details such as what binary it was actually running. Unfortunately this only works for singleton processes where we’re guaranteed that only one of them exists, both at the job level and at the process-level itself; should the process fork, even to run another child, we could accidentally consider it to have died. Daemons need to be able to run their own children, or even have pools of them to use; and we also need to be able to run multiple copies of daemons where we can support it.

So we really do need to know the process id of the actual daemon process we should be supervising. Unfortunately any method of passing this back to init, even relatively common ones like writing it to a pid file, aren’t sufficiently standard or reliable to do this kind of work.

Ideally the kernel would just tell init when a process was reparented to it, provided both the child process id and that of its previous parent. Such a notification doesn’t exist today, though would be a nice project to try and get it into the kernel mainline; difficult if there’s only one implementation using it.

If we can’t have that, a syscall that would allow us to watch a process and find out when it forks would be the second-best thing. We’d have the previous process id since we were watching it, and we’d hopefully be able to obtain the new child process id from this.

Happily that syscall exists, and I suspect you use it all the time if you’re a developer; it’s a bit of a mad leap to using it inside init, but as you can see, it works rather nicely. All we need do is watch the process, and follow it each time it spawns a new child. We stop watching as soon as we have followed twice (once if a different option is used), or if the process runs a different binary by itself. And thus we can know the process id of daemons we spawned, even if they attempt to detach from their parent process which they’ll just be reparented to anyway.

What’s the syscall? Oh, hmm, is that the time? Got to go! Alright, it’s ptrace.

quest /tmp# cat test.c
#include <sys/types.h>

#include <stdlib.h>
#include <unistd.h>

int
main (int   argc,
      char *argv[])
{
        pid_t pid;

        pid = fork ();
        if (pid > 0)
                exit (0);

        pid = fork ();
        if (pid > 0)
                exit (0);

        pause ();
        exit (0);
}
quest /tmp# gcc -Wall -g -O0 -o test test.c

quest /tmp# cat /etc/event.d/test
wait for daemon
exec /tmp/test

quest /tmp# start test
test (#0) goal changed from stop to start
test (#0) state changed from waiting to starting
event_new: Pending starting event
Handling starting event
event_finished: Finished starting event
test (#0) state changed from starting to pre-start
test (#0) state changed from pre-start to spawned
process_spawn: Spawned main process 6380 for test (#0)
Active test (#0) main process (6380)
test (#0) main process (6380) forked new child 6381
test (#0) main process (6381) forked new child 6382
test (#0) state changed from spawned to post-start
test (#0) state changed from post-start to running
event_new: Pending started event
Handling started event
event_finished: Finished started event

The last release (Ubuntu 7.10) was the first in which we shipped Tracker enabled by default; this service runs in the background and indexes all of your files, storing information about them in a metadatabase which can subsequently be searched. The two main ways of searching are through the deskbar-applet (press Alt+F3) and within the nautilus file manager (press Ctrl+F).

That’s all well and good, but since we now have a metadatabase and indexer, what else can we do with it?

The first thing that comes to mind is improve those applications that attempt to maintain their own metadatabase; those that tend to be the primary apps that we use because they manage our all-important content. I’m going to pick on Rhythmbox here since it’s our default music manager, but the same ideas can be applied to our default photo manager, F-Spot, or any other application concerned with content.

A no-brainer is that Rhythmbox no longer needs to worry about walking directory trees, keeping inotify watches on them, identifying media files, etc. Tracker already does all of that. All we need to ensure is that tracker collects all of the metadata that Rhythmbox will need to start with — we expect it to come along and add additional metadata, such as the last time I played the track, where the album cover thumbnail is stored, etc.

Another thing you get to eliminate is the concept of “the Library”. Your entire home directory is already indexed, why care about partitioning it? We can just show the user all of their music, or all of their photos. Immediately. With no need to import from one arbitrary location on disk to another.

Tracker should then grow removable device support, indexing files on removable devices just as it does on the primary filesystem; but keeping mount-relative paths to the files and remembering particulars such as serial number, label, etc. for the device they were found on. This has immediate benefit for Tracker anyway, I can search for a presentation and I’ll be told which USB Key I wrote it to so I can find it again — I’m terrible for losing presentation slides after I’ve given the associated talk.

All Rhythmbox then needs to do is query Tracker for removable devices containing music, and show them as icons in the panel; the contents are already indexing — or if you’ve already used that device, indexed (no more wait for it to index my 40GB media player every single time I insert it). Since there’s just one metadatabase behind this, you may as well add an “All Your Music” option to the top which amalgamates the collection of music on your filesystem and removable devices, eliminating duplicates; this would be the thing you’d share, getting rid of yet another bug.

We then don’t need import dialogs. If I plug a media player in (or a camera, this applies equally there), the content immediately shows up in my browser. The only question we need ask the user is whether they wish to add the music on the device to their local collection, and that can be done inline in the window rather than with an obtrusive dialog. For F-Spot the experience would be that on plugging in a camera of photos, the main F-Spot window would open with the photos already in place (or appearing) in the rest of your collection and a “add these to your collection?” bar at the top — since you have the full app, dealing with adjusting images on import, or removing them entirely is much easier than fiddling inside an option-filled dialog.

The only other backends we’d need would be for remote media such as shared music –why isn’t there a shared photos standard yet?–, online content such as last.fm or flickr and devices that don’t act like disks; there are still some media players and cameras out there which are designed around import/export APIs.

I’ve not really been having much luck with blog software; I’ve found that the harder the software is to use, or the more maintenance it requires, the less I care about blogging.

Ironically, perhaps the easiest time was with Livejournal; it’s easy to set up, maintain and post to simply because it’s a hosted service. Unfortunately you don’t get a great deal of control over the output, and any kind of extras you want to add are out of the window. (Without paying somebody, anyway).

I moved from that to a Pyblosxom blog hosted on my own webserver; this had all the control over the output that I needed, with lots of optional extras. Management was a pain though, relying on me logging in to the web server and editing files directly — since nobody, especially me, likes writing raw HTML I’d chosen Textile as the formatting plugin but could never remember the formatting codes. And dealing with comments and spam? Forget it.

The next change in my experiments came when I moved my blog to being hosted by a friend, and he suggested Typo; the idea here was that it’s a drop-in webapp, so has an admin interface for writing posts, managing existing ones and dealing with comments and spam. Unfortunately it’s one of the slowest and least stable pieces of software I’ve seen, it’s really put me off learning Ruby on Rails as a result! And as a piece of software, it’s pretty inflexible; idiotic limitations made dealing with spam comments an issue and niceties like trackbacks almost impossible.

So I’m back to self-hosting my website and blog again, and at the recommendation of just about everybody, have installed WordPress to do it.

Since this means a change of backend software, this will almost certainly have spammed Planet again; sorry about that. I blame the original Planet author, really, I do.

Also I’ve adjusted my feed URL on Planet Ubuntu; previously this was a technology-only feed, but I’ve received far more complaints about the lack of posts about my flying exploits than when they were present — so the majority appear to want them!

Thanks to a combination of bad weather and the trip away for FOSSCamp, UDS and AllHand, it’s been six weeks since I last got a chance to fly! Last time we’d covered a second session of stalling and recovery, and the next exercises to cover were the all-important circuits: taking off, flying around the field and landing again.

Even despite the weather cancellations before the trip, I knew it’d be at least four weeks gap, so I’d taken the day off and booked two separate lessons either side of lunch. The idea being that we’d use the first lesson for revision, going over all the other exercises to make sure that I could still remember how to fly — and then use the second lesson to start in the circuit, since I’d be learning something new … landing!

Most people seem to assume that summer is the best time to learn to fly as the weather is better, but today was one of those days that proved the opposite. Although the temperature was around freezing point, the skies were clear and the wind calm.

First hour went nice and smoothly; we covered taking off, climbing, descending, turning (including while climbing and descending) and some practice of stalling and recovery. It was reassuring to know that I hadn’t forgotten anything in the long gap between lessons, and still had the feel of the plane.

The weather had put on a special treat for us; for much of the day, fog was clinging to the ground and hills, with many fields still frosted over. From the air it looked extremely pretty, if a little eerie.

After lunch at the airfield’s cafe it was time for the second lesson, circuits! We’d already covered the ground briefing for this in one of the cancelled lesson slots before, so we were ready to go straight up. Another student had flown the plane over lunch, so only a relatively short transit check was needed; checking the fuel levels and other important bits.

John was to fly the circuit first, and talk his way through it as I followed through. A circuit, for those not flying, is: take off; climb and make the first 90° turn onto the crosswind leg; level out at 1,000ft and make the second turn onto the downwind leg (parallel to the runway); call the tower and perform checks for landing; make the third turn onto the base leg and begin the descent before making the final turn onto final and landing.

We were on runway 36, so the traditional left-handed circuit was the order of the day. Wellesbourne switches between left and right depending on the runway direction so as not to overfly Wellesbourne village itself. It’s not a truly rectangular circuit either since there’s three noise-sensitive villages we have to avoid on our way around.

Over lunch, a Kittyhawk had landed at the airfield and was ready to leave slightly before we were; treating us to one of the pleasures of flying from a purely GA airfield. The FISO informed the departing Kittyhawk that the circuit was clear and asked whether he would like to perform a low-level fly past (normally pilots have to beg the FISO or ATCO to show off, and get told no). So as we lined up on the runway, we were treated to a short air display from the warbird, flying past the tower, climbing into a loop and performing a bombing run on the airfield on the way back before heading home.

Entertainment over, work time. John flew the first circuit, then handed me control after landing for a touch-and-go (taking off again without stopping) and it was my turn. I flew six circuits in total, one straight after the other. At first we were the only ones in the circuit, but by the end we were in a queue of three planes all heading down at once. In fact, on one of the goes round, John decided to use it as an opportunity to perform a go-around (aborting the landing).

I think I got something wrong on each of the circuits. My first landing was somewhat rough, having flared too early and been rather too high most of the way down. The next I turned onto final too late and spent most of the time trying to line up with the runway again; in fact, I did this a few times — and turned too early at least once too. By the last landing, I’d got the turn just right, and kept the descent perfect as well; lined up with the runway and at the right height and speed all the way down. Just a slight shame I ruined it with a slightly untidy flare and by bouncing the plane on the touchdown.

On the whole, I was really happy and so was my instructor. I’d been in control the entire time, and had been correctly using the power and attitude to control the approach. None of the landings may have been perfect, but I have plenty more hours of circuits to go yet — dozens of hours in fact — to get that bit right.

P/UT Hours Today 1:50, Total 10:50

A common mistake of user interface design is to come up with a clever solution to a common user problem, when you should work out a way to remove that problem in the first place.

My example here is the password entry dialog, in particular the GNOME Screensaver one.

The common user problem is that their password is rejected, even when typed perfectly, because the Caps Lock key is on.

The clever solution was to display in the dialog that the Caps Lock key was on, and thus hinting to the user why it might have been rejected.

The better solution would be to ignore the state of Caps Lock in all password entry dialogs, so it doesn’t matter whether it’s on or off.

My instructor was away last week, so it’s been two weeks since my last lesson. Sod’s law would suggest that the weather would be terrible, but someone must like me because instead it was one of the nicest days in quite a while!

The only real thing of concern was a bit of an inversion, giving a fairly thick ground haze. The student up before me hadn’t flown in the end because he needed a strong horizon for the exercises he’d been doing (just as I did not so long ago) and had instead practiced taxying around the airfield.

John thought it’d be more than fine for me though, especially since I’d managed worse conditions including the gusting last time! The complete lack of any cloud base meant that the gsson today would be more stalling, getting the opportunity in as there’s a couple of hours of these today.

No drama with the checks or take-off today, I’ve got pretty used to handling these by myself now. In fact, I’d go so far as to say that I nailed the take-off and had spare brain power to remember to deal with the flaps and fuel pump at the right times and watch the engine gauges and make occasional clearing weaves during the climb.

Headed down the Fosse Way to Shipston again, I’ve a hunch that there’s a club rule that newbies got to the west and students in the later exercises go to the south, since we now seem to spend most of our time down here. Easily climbed all the way to 3,500ft with a bit of practice of climbing turns.

Once there, HASELL and a couple of revisions of a clean stall; no drama here, if anything it was easier than last time since we weren’t trying to keep in a cloud hole. In Victor Alpha today which handles a little differently than Victor November, seems to like to dance to the side during a stall; so a bit of extra need to keep it in balance.

John next demonstrated an approach stall with full flaps, and I repeated it with little difficulty, though again forgot to remove the carb heat. Made a mental note that the throttle and carb heat always go together, and didn’t forget it again.

A base leg stall in a turn was up next, a couple to the left since I didn’t get the first one quite right, and then one to the right to mix things up a bit. Much better that time.

Practised a couple of mid-air go-arounds, since the procedure is much the same as cleaning up flap from a base leg stall; and then it was time to head home. A little bit of excitement as a John spotted a PA-28 and pulled us up and out of the way quickly, not that close but they clearly didn’t see us.

Handled the overhead join, descent and turn onto final, following John through for the last part of the landing, then back to the school.

Next lesson: circuits!

P/UT Hours Today 0:45, Total 9:00

Like any sensible software developer, I have a close relationship with revision control systems. In my previous job, I was an SCM Engineer (see Software configuration management) which meant I had an even closer relationship than most, since we were running the CVS servers and actively using them to track changes and deployments.

We all know, deep down, that revision control systems shouldn’t exist. This kind of thing should be inherent in the design of the operating system, through standard file and filesystem formats. The OLPC interface is making some headway towards that, but for the rest of us, it means using a revision control tool throughout the development process.

Unfortunately, even though the tool is expected to be the most-used command on your system, very few of them are particularly easy to use. Thus there’s a large learning curve, and people become religious about their choice since they have invested significant time in using it.

Just to spice the mix up, not only will people religiously defend their choice of revision control system, but they’ll do so while actively hating it.

In the beginning there was CVS and we all thought that it was pretty good. It was based on the simpler RCS and shared a file-format with it, but introduced control of directory trees and remote operation.

Actually, in reality, CVS wasn’t that good. Its command set could be a little strange and inconsistent (e.g. it’s not possible to diff between two dates on a branch); the support for branching assumed that all branches would be merged into the mainline, and only once; and nobody ever really knew how to create a new project in a repository (tip. cvs import is wrong).

But we all used it anyway, and we muddled through. It did have some good features; it was simple, fast and pretty reliable–when it did break, you could usually fix the repository yourself. And most importantly of all, we understood how to drive it.

And so it was for many years, until Subversion (SVN) came along. Subversion intended to be “a better CVS”, perhaps this goal should have made us suspicious at the time since CVS was already being a pretty good CVS by itself; unfortunately we hated CVS so much we flocked to the new system in hope.

In hindsight, Subversion didn’t really improve on CVS much at all. In fact, arguably, the only real improvement was the addition of atomic commits (in CVS, each commit is per-file, so it’s manual labour to work out which change was made to two files at the same time).

(Its support for branching, tagging, copying, renaming, etc. were no better than CVS’s when done in the repository by hand.)

The cost of this single new feature was a much more complicated interface (with two separate commands), a backend that tended to break down weekly and a lethargic slowness to its operation.

Most people I know now justify their use of Subversion instead of CVS by “Subversion is maintained, CVS isn’t” which is a somewhat self-fulfilling justification.

While the mass conversion to Subversion, and ensuing disappointment and frustration, was going on; something new appeared on the horizon: Arch.

Arch was different, it broke one of the core assumptions of revision control, that of the repository as a cathedral. In CVS, and Subversion like it, if somebody wants to modify your code (even if on a branch) you need to give them access to your own repository. In some cases (especially with CVS), vast access control and permission structures would be in place to ensure proper behaviour.

With Arch, you don’t; all you need to give to anyone is read access. Anybody can make their own branch by copying yours and committing to their own copy.

This model also necessitated fixing a long standing problem that CVS had; Arch has repeatable (smart) merging. If you merge from a branch, you can merge again later, and again, and again.

Arch made this possible through each commit (changeset) having a globally unique identifier; made from the branch’s own globally unique identifier and the changeset number in the branch.

Unfortunately while this was a massive step in a new direction, Arch had an absolutely terrible user interface. Its command list was terrifying with over 100 commands, many of which had multiple word names (tla set-tree-version). It exposed too many of its own innards, and expected you to learn them. It also forced baroque file naming semantics on its users and strange policy (though shalt not commit without first running “make clean”).

Efforts were made to improve Arch’s user interface through projects such as baz, but they were always to be doomed from the start.

We’ve since seen an explosion of new revision control systems; Monotone, Darcs, Git and Bazaar.

What’s especially interesting is the commonality between these systems. They are all “distributed” like Arch, though they also all discard the strange “unique branch identifier” convention and instead simply assign a unique identifier to each file or commit.

This means that they all support personal branches, and by necessity all support repeatable (smart) merging.

So how do they differ, what are their killer features and killer problems?

Monotone is all about repository integrity, ensuring that every commit is both authorised and intact. It pays for this with a severe lack of speed.

Darcs is based around a “theory of patches”, a branch is not made up of its history but by the collection of patches in it. Unfortunately this often breaks down, and darcs frequently gets stuck calculating even trial and commonplace branch models.

Git is very strange to me; its killer feature appears to be the speed at which it can handle very large trees, but the interface is as insane as Arch’s was. It is heavily optimised for the “I only apply patches” development model, at the expense of ordinary development models (it shares an issue with Arch where calculating annotations on an individual file is an expensive operation).

What about Bazaar? Its killer feature is that it is designed to work the way you do. The command set is relatively small, and each of them works in the most obvious manner. It also supports plugins so that you can always implement your own workflow.

Of all the revision control systems, it’s the only one (that I’m aware of) that supports both distributed and centralised workflows (and lets you go distributed when you need to, e.g. when you’re on a plane).

Here’s a few examples of how Bazaar’s command set works the way you do. To start managing some code in bzr:

$ cd myproject
$ bzr init

To add the files, copy in your usual .bzrignore file and just add everything:

$ cp ~/bzrignore .bzrignore
$ bzr add
added foo.c
added bar.c

Check the output for mistakenly added files, adjust .bzrignore and remove the file with bzr rm.

A common operation is realising that the commit you’re about to make should really go on a new branch for now:

$ cd ..
$ cp -a myproject myproject-foo
$ cd myproject-foo
$ bzr commit

A copy of a Bazaar branch is a different branch, you can commit to it separately. There’s a bzr branch command for it too (which deals with issues such as bound branches, checkouts, etc.) but it’s nice to demonstrate that Bazaar does what you’d expect even when you don’t use its own commands.

Pulling changes from another branch (where you haven’t made any modifications yet) is easy:

$ bzr pull ../myproject

As is merging (when your branches have diverged):

$ bzr merge ../myproject

One particularly nice feature is that after a merge, you see the merge as a single commit and it can be treated as such; but it also has the set of merged commits indented under it–you can examine these as individual commits as well!

What’s the downside of Bazaar? Well, it’s not the fastest system (but by no means the slowest), for small to medium sized projects this is never an issue but may be for extremely large projects–fortunately the developers are improving its performance all the time!

But that doesn’t matter; it is, honestly, the first revision control system that I don’t hate.

Two lessons booked today, one before lunch and one after lunch. The long term forecast hadn’t looked good, and I thought it’d be a good idea to try and cover the weather. Turns out that my hunch was right, the weather really wasn’t looking that good this morning, but looked like it might clear up towards the afternoon.

The original plan had to be to cover slow flight and stalling today, but the weather wasn’t going to be good enough for that; certainly not good enough for stalling.

John decided that the best thing would be to go up and do some revision of turning, especially while climbing and descending; and an introduction to slow flight. Then after lunch, if it had cleared up, finish up slow flight and move on to stalling.

We had plenty of time, because the previous student had cancelled; and as it turned out, the one between my lessons and the one after cancelled as well!

Victor November as usual, but today spotted a problem doing the checks; a screw had come loose on the left wheel spat and had to be tightened before we took off.

Handled the take-off again today, a fairly easy one along Runway 36 remembering to turn to 030° afterwards to avoid overflying Charlecotte who don’t like it when we do.

First bit of revision into climbing turns accomplished then, and again as we turned onto downwind before leaving the circuit. Held the course south, and did some descending and climbing turns over Shipston-upon-Stour before heading west.

Cloud wasn’t going anywhere, and the horizon was really indistinct which made holding a reasonable attitude quite difficult, let alone turning on it; but managed to muddle through.

Next up was an introduction to slow flight. This is basically slowing the speed right down while holding the altitude, keeping the nose very high. Brought the power back in a couple of stages, and after each one it was increasingly harder to hold the aircraft’s attitude and required huge movements of the controls.

Stall warner sounded as we got particularly slow and it was time to recover, so lowered the nose and increased to full power, climbing out of it.

Practiced those a couple of times to get the feel of it right. Then time for a bit more practice at some turns, had the aircraft in a descent when John asked me to turn, which I did; but I’d forgotten to get it in trim first, as a result made quite a mess of turning out and levelling off. Bugger.

In fact, I felt that the weather was throwing me off completely so we headed back to the school for lunch, with the hope that it’d at least clear up for the afternoon session.

No such luck though, after a decent lunch and some time in the briefing room covering the procedure for stall recovery just in case, the cloud wasn’t going anywhere. It had lifted a bit, and there was a spot of blue sky around Wellesbourne, but no more than that.

Visited the control tower to see what it was like, and they weren’t too keen on it either. Someone was up doing their skills test, but they’d headed off to the east for some decent weather.

Definitely wasn’t going to be doing any stalling today, and John asked me what I wanted to do.

Since it had improved slightly, and I wasn’t happy about mucking up some of the basics in the last lesson, I asked whether we could go up again for some revision of climbing, descending and turning.

He agreed that was a good idea, so that’s what we did. Another take-off, climb up through the circuit and out. He then set me a few exercises such as turning to a particular place, getting us there, changing altitude and turning onto a new heading, flying there; changing altitude again and turning towards home before a standard over-head join into Wellesbourne.

The improved visibility and much more relaxed nature of the flight, not having to learn anything more, really put me back at ease and I found that I was able to do the exercises much more confidently than I had before.

In the end, quite a productive lesson despite the weather. Several things to read up on for next week, since depending on the weather it’ll be more slow flight, some stalling or maybe even a first circuit or two.

P/UT Hours Today 1:30, Total 6:50

Wasn’t sure what I was going to be learning today! I’ve reached an interesting point in the course where there’s any number of lessons I could do, depending on the weather.

Ideally this lesson would be some revision of slow flight, and an introduction to stalling; but stalling is going to require a decent enough cloud base (over 3,000ft!) to be able to do it.

Otherwise if neither of those are possible, it’d be starting on circuits and learning how to land. I feel a bit like Indiana Jones at the moment; when people find out that I’m studying for a PPL, they usually say something like “I didn’t know you could fly?” to which I have to reply “Fly, yes. Land, no.”

Weather didn’t look too bad looking out of the window, but got increasingly worse as I drove to the airfield. Didn’t look like stalling was going to be happening today, the cloud was coming in far too low. John agreed and decided that we’d do the briefing on it, but would probably just do some revision on slow flight and complete that exercise.

A new plane today, G-WAVA. A notorious poor starter, but Stephanie claims has now been fixed! Not sure about that, it definitely didn’t want to start this morning! Probably wasn’t entirely happy about having needed duck tape stuck across the oil filler cap. While doing the checks, I’d been unable to get the cap to stick back down again.

An odd cross-wind today so we were on the much shorter Runway 23, since this was a bit of an unexpected challenge, John handled the takeoff while I followed him through. Once in the climb, I had control again and we did some practice of turning climbs as we headed out of the circuit and down to the South.

Overhead Shipston (they must really hate the sound of small aircraft there, we always seem to be flying in circles around them!) John asked me to bring the power back and hold the attitude to keep the height; more power back, more holding of the attitude and again until we’re only just a few knots away from the stall; once more and the warner sounded, so nose down and full power to recover, climbing away.

A few practices of this, before going again with flaps and then practicing turning while in slow flight. Turning has the extra challenge of having to nudge the power in to avoid a stall, since the turn increases the stalling speed whilst simultaneously decreasing the speed!

Didn’t quite nudge hard enough on a turn to the right, I’m sometimes a little too gentle with the controls when I need to be rather more forceful with the power at times.

I’ve also caught myself adjusting power and watching the RPM meter, rather than listening for the change in tone. Made a mental note to stop that, and found it much easier for the rest of the flight. Had been doing it turns too, and watching the attitude indicator; oops! Bad habits creeping back while I’m busy learning new things.

A few more practices before heading back home, as the rain came in; which we caught over Stratford as turning to begin the overhead join. This was a bit more interesting, since we were in a different pattern and turning at different times to what I was used to (having normally joined for Runway 36).

P/UT Hours Today 0:45, Total 7:35