Using Plan 9

The Plan 9 environment takes some acclimating. Many of the commonly-found UNIX utilities have been replaced or removed (there's no vi and no emacs), and the user interface relies heavily on mouse usage. In fact, a three-button mouse is strongly preferred. This might be a little strange if you're a hardcore CLI person. It took me some time to get the hang of it.

I recommend going through the READMEs for Rio, the Plan 9 Window Manager, and Acme, the programmer's editor. I found the Plan 9 Newbie Guide (PDF) and the RIT Plan 9 Introduction to be very useful. There are also a few helpful youtube videos:

• Using Plan 9--a basic session
• Narrated Plan 9 Demo
• Acme Editor Demo
• Acme Mail Demo
• Plan 9 Acme Intro - Part 1 
• Plan 9 Acme Intro - Part 2
• Plan 9 Acme Intro - Part 3

Plan 9 from Bell Labs

Plan 9 is an interesting operating system, and it's got pedigree. It comes from the same Bell Labs folks that brought us UNIX and the C programming language. Plan 9 pushes a lot of the UNIX ideas further. For instance, Plan 9 employs the UNIX file metaphor ubiquitously by representing nearly every system resource as a file including processes, network protocols, windows. Several Plan 9 innovations made their way into other operating systems including UTF-8, procfs (and sysfs), and the rfork() system call (clone() in Linux).

For a good intro to Plan 9, check out this FOSDEM 2006 talk:

Submit Your First Linux Kernel Patch

Greg Kroah-Hartman, a core Linux developer, gave a talk at FOSDEM 2010 titled "Write and Submit your first Linux kernel Patch." He leads you step-by-step through the process of writing and submitting your first kernel patch. He gives a brief introduction to common kernel development tools such as git, checkpatch.pl, and get_maintainer.pl. He goes through the process of creating the patch, building the code, and he even mails out the patch.



Alternatively, you can download the talk from the FOSDEM website. You can also check out the talk slides (PDF).

After watching the video, you might also want to read:

• Documentation/HOWTO
• Documentation/CodingStyle
• Documentation/SubmittingPatches
• Documentation/SubmitChecklist

Greg is the maintainer for the staging drivers (i.e., drivers/staging), and it's a great place to start contributing to the kernel. The staging drivers hold all the work-in-progress drivers that don't yet meet the kernel's coding standards. There's a lot of low-hanging fruit for those who are new to the kernel development. See Greg's patch if you don't believe me. You might also follow the Linux Driver Project mailing list. This is the main developer list for staging drivers. You can get a better idea of the patches that people are submitting.

Killing Memory Hogs with Magic SysRq

If your system is thrashing, you can use the Linux kernel's magical Magic SysRq feature to call the out-of-memory (OOM killer). If you enter the key sequence ALT-SysRq-f, the Linux kernel's OOM killer will kill the greediest memory hog process. Alternatively, you could run:

sudo sh -c "echo f > /proc/sysrq-trigger"

It is important to note that you will have zero input as to which process gets killed; the kernel makes that selection for you. You will see something along the lines of this in your dmesg:

[848124.522901] SysRq : Manual OOM execution
[848124.523533] events/1 invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0
[848124.523544] events/1 cpuset=/ mems_allowed=0
[848124.523553] Pid: 10, comm: events/1 Not tainted 2.6.35-24-generic #42-Ubuntu
[848124.523560] Call Trace:
[848124.523580] [] dump_header+0x7a/0xb0
[848124.523590] [] oom_kill_process+0x5c/0x160
[848124.523600] [] ? select_bad_process+0xa9/0xe0
[848124.523611] [] __out_of_memory+0x51/0xb0
[848124.523620] [] out_of_memory+0x58/0xd0
[848124.523632] [] moom_callback+0x23/0x30
[848124.523645] [] run_workqueue+0x8e/0x150
[848124.523655] [] ? moom_callback+0x0/0x30
[848124.523666] [] worker_thread+0x84/0xe0
[848124.523677] [] ? autoremove_wake_function+0x0/0x50
[848124.523687] [] ? worker_thread+0x0/0xe0
[848124.523696] [] kthread+0x74/0x80
[848124.523706] [] ? kthread+0x0/0x80
[848124.523716] [] kernel_thread_helper+0x6/0x10
[848124.523723] Mem-Info:
[848124.523728] DMA per-cpu:
[848124.523735] CPU 0: hi: 0, btch: 1 usd: 0
[848124.523742] CPU 1: hi: 0, btch: 1 usd: 0
[848124.523747] Normal per-cpu:
[848124.523754] CPU 0: hi: 186, btch: 31 usd: 153
[848124.523761] CPU 1: hi: 186, btch: 31 usd: 181
[848124.523766] HighMem per-cpu:
[848124.523772] CPU 0: hi: 186, btch: 31 usd: 133
[848124.523779] CPU 1: hi: 186, btch: 31 usd: 138
[848124.523794] active_anon:224139 inactive_anon:150187 isolated_anon:0
[848124.523797] active_file:22548 inactive_file:20422 isolated_file:0
[848124.523801] unevictable:6 dirty:87 writeback:0 unstable:0
[848124.523804] free:67835 slab_reclaimable:8910 slab_unreclaimable:4561
[848124.523807] mapped:17499 shmem:33272 pagetables:4843 bounce:0
[848124.523828] DMA free:3544kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:3488kB inactive_file:504kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15808kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:192kB slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[848124.523844] lowmem_reserve[]: 0 865 2007 2007
[848124.523870] Normal free:201160kB min:3728kB low:4660kB high:5592kB active_anon:176184kB inactive_anon:331536kB active_file:40292kB inactive_file:29864kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:885944kB mlocked:0kB dirty:248kB writeback:0kB mapped:22344kB shmem:55476kB slab_reclaimable:35448kB slab_unreclaimable:18236kB kernel_stack:4312kB pagetables:3192kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[848124.523887] lowmem_reserve[]: 0 0 9134 9134
[848124.523913] HighMem free:66636kB min:512kB low:1740kB high:2972kB active_anon:720372kB inactive_anon:269212kB active_file:46412kB inactive_file:51320kB unevictable:24kB isolated(anon):0kB isolated(file):0kB present:1169244kB mlocked:24kB dirty:100kB writeback:0kB mapped:47652kB shmem:77612kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:16180kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[848124.523930] lowmem_reserve[]: 0 0 0 0
[848124.523943] DMA: 30*4kB 14*8kB 19*16kB 16*32kB 33*64kB 3*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3544kB
[848124.523975] Normal: 26058*4kB 8958*8kB 1255*16kB 26*32kB 16*64kB 6*128kB 2*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 201160kB
[848124.524008] HighMem: 11719*4kB 2372*8kB 49*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 66636kB
[848124.524040] 94992 total pagecache pages
[848124.524046] 18750 pages in swap cache
[848124.524053] Swap cache stats: add 2029477, delete 2010727, find 4243143/4373258
[848124.524059] Free swap = 903984kB
[848124.524064] Total swap = 2096444kB
[848124.544017] 521938 pages RAM
[848124.544025] 294613 pages HighMem
[848124.544030] 9033 pages reserved
[848124.544034] 148399 pages shared
[848124.544039] 392113 pages non-shared
[848124.544048] Out of memory: kill process 28044 (chromium-browse) score 1337216 or a child
[848124.544058] Killed process 28044 (chromium-browse) vsz:83576kB, anon-rss:116kB, file-rss:3628kB

The kernel ring buffer shows various system-wide memory statistics and tells you which process was killed. Sorry, chromium. You didn't do anything wrong. I wanted to show an example, and the kernel chose you for termination.

I've found this Magic SysRq command to be handy when my machine's disk LED is blinking furiously and the system is painfully unresponsive.

Note to self: buy more memory.

Magic SysRq: Reboot Even If System Utterly Broken

If your system is locked up, you can use Magic SysRq to reboot safely (unless your kernel is in very dire straits). The Magic SysRq Wikipedia article describes the process and provides the handy, amusing mnemonics: "Reboot Even If System Utterly Broken", "Raising Elephants Is So Utterly Boring", and "BUSIER" backwards (well, this one's not as amusing). The Magic SysRq command sequence is r-e-i-s-u-b. If you recall from the first Magic SysRq post, you will enter the key combo 'ALT-SysRq-<command key>' for each key in the sequence. You would enter ALT-SysRq-r, ALT-SysRq-e, ALT-SysRq-i, ALT-SysRq-s, Alt-SysRq-u, Alt-SysRq-b. Wikipedia provides the secret decoder ring to decipher this key sequence:

• unRaw - Take control of keyboard back from X
• tErminate - Send SIGTERM to all processes, allowing them to terminate gracefully
• kIll - Send SIGKILL to all processes, forcing them to terminate immediately
• Sync - Flush data to disk
• Unmount - Remount all filesystems read-only
• reBoot

This will shutdown all the processes cleanly and write all the data to disk. You may need to wait a few seconds between commands. During the Sync step, you should see an "OK" and a "Done" when the sync is finished unless the kernel is really hosed.

If you haven't already, check out the first Magic SysRq post for a detailed introduction on how to use Magic SysRq.

Magic SysRq is Pretty Magical

There was a recent KernelNewbies thread about the Linux kernel's Magic SysRq feature. The kernel documentation says that Magic SysRq "is a 'magical' key combo you can hit which the kernel will respond to regardless of whatever else it is doing, unless it is completely locked up." Sounds good to me. I like magic, especially when it allows you to restart a hung machine, recover from X crashes that leave you without a console, and helps you out of other unpleasant scenarios.

As the thread mentions, you enable Magic SysRq by running:

sudo sh -c "echo 1 > /proc/sys/kernel/sysrq"

If you would like Magic SysRq enabled all the time, you can add an entry to /etc/sysctl.conf:

kernel.sysrq = 1

Of course, Magic SysRq support must be built into your kernel (CONFIG_MAGIC_SYSRQ = y), but that is likely the case with most distribution kernels. Now, if you type in ALT+SysRq-h (assuming you're on an x86 machine), the kernel will display help for Magic SysRq. If you run dmesg, you should see something like this in your kernel ring buffer:

[638484.759205] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount force-fb(V) show-blocked-tasks(W) dump-ftrace-buffer(Z)

I had to follow the advice from Documentation/sysrq.txt for my laptop keyboard:

Some keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is also known as the 'Print Screen' key. Also some keyboards cannot handle so many keys being pressed at the same time, so you might have better luck with "press Alt", "press SysRq", "release SysRq", "press <command key>", release everything.

I have no SysRq key, so I hold down the Alt key, hold down the Fn key, press the "Prnt Scrn" key, release the "Prnt Scrn" key, release the Fn key, press h (or whatever command key you like), and then release the Alt key. It's a little complicated, but you get the hang of it.

Alternatively, if you don't want to deal with the complicated key sequence (and your console is working), you can run:

sudo sh -c "echo h > /proc/sysrq-trigger"

You can replace 'h' with the command key of your choosing. You might try 'm' to dump memory info or 'l' to dump a stack trace for all active CPUs. For the other command keys and more info, you can read Documentation/sysrq.txt in your kernel's source tree. There's plenty of other magical SysRq goodies.