Monday, July 30, 2012

Starting Programs on Boot in Linux

Using the System V Init process
Wanting to be able to set programs to automatically run when my computer turns on is a common issue.  I usually have a variety of different programs running all the time on my Linux server, doing anything from recording webcam footage I want to go back and review, to watching for interesting tweets to print, to sending me text messages with NWS weather alerts, to running a Minecraft server.  Many of these (like checking for new weather alerts every 30 minutes) can be easily scheduled to run at regular intervals using the Unix cron tool, but many others really have to be running all the time and just need to be started when the system first boots.

Luckily, the System V Unix standard exposes an easy way to control how these long-running processes (called daemons) can be started and stopped when the computer is booted and shutdown through the init system.  Init is the very first process that the Linux kernel executes when you boot you computer, and init then goes on to spawn, or spawn the spawner of (or spawn the spawner of the spawners of,etc), every other process running on your computer.  Likewise, when you go to turn off your computer, init is the process that tells every running daemon to clean up whatever it's working on and exit so the system can shutdown cleanly.  The question then becomes "how does init know when we're turning on or turning off the computer, and how does it know which programs to start or stop at each point?"

Of course, since System V came out nearly three decades ago, programmers have developed alternatives to init, such as Upstart (which is used by Ubuntu), and systemd (which is used by Angstrom - Tutorial).  Luckily, since System V was such an important part of Unix history, even when a distro uses one of these other systems, they usually still support the init protocol using /etc/init.d and /etc/rc[0-6S].d/ I'm going to describe for you here.

Run Levels

Signalling init as to what we want it to be doing is done through what's called runlevels.  I always think of runlevels like DEFCON; a simple indicator of what general state of readiness the computer needs to be in.  Unfortunately, unlike DEFCON, runlevels aren't quite clearly as defined as DEFCON levels:
  • Runlevel 0 - This runlevel is for when an admin has told the computer to shutdown, so init sends signals to processes running which need to perform cleanup, and runs shutdown scripts to do things like unmounting hard drives and releasing resources on the network.
  • Runlevel 1 - Single-User mode is usually for when something has gone wrong, so we want as little of the system running as possible.  Runlevel 1 starts the bare minimum needed so that the superuser (root) can log in and play God while he fixes whatever is wrong for the peasants (otherwise known as normal users).  Once the superuser has fixed whatever was wrong (corrupt filesystem, mis-configured daemon, etc), he will tell init to take the system to one of the other runlevels, at which point init brings up the rest of the services that normal users use, like graphical interfaces and file servers.
  • Runlevel 2-5 - This is where the differences between different flavors of Linux get a little annoying.  Runlevels two through five are the normal "multi-user" runlevels that systems spend most of their time in, providing various levels of usefulness for all of the normal users; what exactly that means is defined differently for every distribution.  Usually, as you move to higher runlevels, init will start progressively more services, such as the graphical interface, etc.
  • Runlevel 6 - Level six is much like runlevel 0, and is usually almost the same set of shutdown scripts, with the one difference that at the very last moment, instead of shutdown down, the computer should reset itself and come back up.  Of course, any programs that you have running will definitely be stopped in either case, but if you know that the computer is just rebooting and not being shutdown to be put in cold storage, maybe you only want your daemon to say "hey! BRB!" instead of "Goodbye, cruel world!"  Exactly what that difference implies depends on exactly what the daemon is doing.


So init has eight different run levels (0-6 and "S"), which each have a corresponding set of programs that should be either started or stopped when the system enters that runlevel.  Of course, now you want to add your own program to these glorious sets of lists, so that if the computer ever happens to be turned off, the programs will automatically come back up with it, instead of you having to manually log in and try and remember everything that you had running in the background the last time you rebooted your computer.

These magical lists are stored as eight directories of shell scripts in the /etc/ settings folder: /etc/rc0.d/ - /etc/rc6.d/ and /etc/rcS.d/ (which are often written using the shorthand /etc/rc[0-6S].d/).  The problem is, having a shell script to start your program in eight different places is going to be a pain in the ass, come the time you ever need to make an edit to this script.  To solve this, these eight directories actually contain no scripts at all, but just symbolic links pointing at master copies of all the scripts in a single directory: /etc/init.d/.

Depending on exactly which Linux you're running, and exactly what services you have installed, your /etc/init.d/ folder will have various different files in it.  The most useful file in this directory is the /etc/init.d/skeleton file, which is a shell script with all of the boiler plate already written for your script to behave properly when init, or an admin runs it to start or stop your daemon.

To write your own init.d script, copy this skeleton script:
# cp /etc/init.d/skeleton /etc/init.d/my-first-daemon
And then fill in all of the details about the daemon at the beginning of this script (bah! comments!), and then fill out the do_start() and do_stop() shell functions so that they, respectively, start and stop your daemon.

update-rc.d my-first-daemon defaults

Once you have your init.d script written, it's time to properly create all of the symlinks to it in the eight /etc/rc[0-6S].d/ directories.  Unfortunately, these symlinks all need to be made in a very specific format.  Fortunately, generations of admins before you have been really lazy, so you'll usually find a tool called "update-rc.d" which will do all of the hard work for you.  All you have to do is tell it what your init.d script is named, and then tell it which run levels you'd like init to either start or stop your daemon in.

The vast majority of the time, you'll want your daemon to start for the four multi-user modes, and stop for all the other modes.  This typical setting can be described as "defaults," which is a lot less verbose than the equivalent command which explicitly lists every runlevel under either start or stop:
# update-rc.d my-first-daemon start 20 2 3 4 5 . stop 20 0 1 6 .

Notice the 20 immediately after start and stop; this is where in the transition sequence you want your daemon's init.d script to be run.  These numbers range from 00 to 99, and are only important if your daemon depends on other services (which it probably does...) like networking, ssh, etc.  These sequence numbers, as well as the choice between starting or stopping a daemon, are actually encoded into the names of the symlinks, as follows:

Sample listings:

  • Each symlink will start with either an S (for start) or K (for kill), indicating if that daemon should be started or stopped.
  • Immediately after the S or K is the two digit sequence number dictating in what order all of the init.d scripts are run.
Luckily, you don't really need to remember this.  All you need to know is how to use the update-rc.d tool, and it does all the hard lifting and remembering for you.

UserStart - A Simple Example

Now that you know how to write an init.d script which will properly respond when init or root prod it, and how to tell init which runlevels you want your daemon started or stopped in, it's time for a useful example I use on some of my systems.

UserStart Source Listing:

This script (which is based on /etc/init.d/skeleton) scans through each user's home directory looking for a ~/cron/ script which, if it exists, this script executes as that user.  I find this useful because the init system is designed to start full-blown daemons as root, but often I want to start programs as a normal user.  This now lets me just add a call to my programs from ~/cron/ instead of having to go through all of the work of building an init.d script and installing it for every separate program.

Of course, this script has some glaring security issues; when a user can schedule something to run on startup, they can schedule things that go horribly wrong and make even booting a system to remove their scripts kind of a pain in the ass.  Also, having init run ANY ~/cron/ script for ANY user willy-nilly is kind of a bad deal.  This all means that you should probably only deploy this script on a system where you inherently trust all your users, but then again, I have a rather unpopular opinion that Unix is an inherently insecure operating system all together...

Thursday, July 26, 2012

Road Trip Day 4 - Titan Missile Museum

As our big summer trip this year, my dad and I decided to take a six day road trip across southern California and Arizona to hit a number of museums that have been on our respective bucket lists for some time now.
 Now let's first get something very clear; every place we stopped at before this (part 1, part 2, part 3) were well and good, but the Titan Missile Museum is the single reason why we picked up and drove 1,000 miles into the Arizona desert.
This museum is built around the last Titan missile silo, to preserve an integral part of the Cold War between the US and the USSR.  I heard about it online two years ago, and thought it sounded interesting, but missile silos tend to be out in the middle of nowhere and that would be that.  BUT, the TMM offers a "Top-to-bottom" tour, where you get to spend a whole day, as part of a group of no more than six, working your way from the very top to the very bottom of the ENTIRE silo. Hold the freaking phone.  This is why this road trip happened, and I would say it easily made driving all 1,000 miles worth it.
In the words of the tour guide, this is the E ticket tour of this facility, and he made a point of making us remember that.  This tour gives you free reign of the entire facility and he showed us anything we wanted to see.
 Starting at the top, the missile silo is really just about as much as you would expect; a concrete cap and a few antennas.
As part of the arms reduction treaties, this silo has been chocked half-closed, but other than that and some other disabling measures, the entire facility has been immaculately preserved.
The facility includes several interesting radio antennas, including this HF one which is fully operational and actually has an amateur radio station connected to it to activate for special events.
This UHF antenna stands about 3 feet wide.  There were another half dozen antennas on various bands to REALLY ensure that communications to the silo could not be cut off.

At ground level is various pieces of Titan missiles, to let you really get a sense of scale.

The typical walk-in tour takes you down to the control room, which is part of the crew quarters connected to the silo via two blast doors and a long reenforced tunnel.  The control panels are still operational, and they have a simulator built into the control center so that you can "launch the missile" and get the full experience of what launching a ICBM was like.
 The standard tour ends there, but we got to visit the crew quarters and the radio electronics room, above and below the control room, before heading over to the actual silo for the rest of the tour.

One little piece of nerdy trivia I enjoyed was the fact that all of the original wiring was done using lacing cord, which is a strong waxed thread used to make wiring harnesses before the modern advent of velcro and zip-ties.  Lacing cord does a particularly good job because its waxyness tends to grip the cables and hold the harness in the desired shape, without needing to grossly over-tightness the straps like you do for zip ties.  Of course, the modern retrofitted CAT5e Ethernet cable was zip-tied into the bundles. You can't have everything.

It's becoming increasingly rare, but there are still a few places, namely on eBay, that you can still buy lacing cord, and I actually rather enjoy using it for cable control.

Another interesting feature of the facility was how everything was designed to withstand severe shock from aerial assault.  Every console, and every motor, and even the entire crew quarters, is suspended via giant shock absorbers.

As part of being able to get where it wants to go, an ICBM needed to know precisely where it is when it starts.  This was done by regularly sighting the missile off of a number of major land features surrounding the valley that the silo was built in.  Shown is the triangular concrete platform for the sextant tripod at ground level, the pipe running down two stories to the blue sighting table, which then fed through a portal in the side of the silo to the inertial navigation unit in the missile.

The website isn't kidding around when they say that you need to be physically fit to perform this in-depth tour.  Most of the trip was taken via the service elevator shown above, but there were a few ladders which needed to be climbed to reach some of the deeper corners of the facility.

As we worked our way down the nine levels of the silo, at each level we were first shown what various support equipment was installed at that level (generators, control circuitry, water tanks, etc), and then we were allowed to go out on the service platforms inside of the actual silo.  It was an amazing way to get a sense of scale to be able to stick your head out and look down the entire length of the missile, without any kind of window or grating standing between you and 100' of missile.

The electronics nerd in me had plenty to enjoy along the entire tour, and I was even able to point out some interesting points of the control systems which the guide didn't know (he was a retired major who originally operated these silos, but understandably didn't know ALL of the technical minutia of a missile silo).  I've used a piece or two of military grade 5400 logic before, which is equavalent to the standard 7400 TTL logic, but "better."  It was interesting to see entire circuit boards of 5400 logic in all the equipment.

Once we reached the bottom of the missile, the tour guide then asked if there was anywhere we wanted to go back and look at again.
In response, I pointed out that this was a "top-to-bottom" tour, and we weren't really at the bottom yet... I wanted to get down in the flame deflector, just to be able to say that I had.  The guide's response was "well... we're not normally supposed to take you down there, but if you're careful..."

This tour was amazing.

 Once down in the flame deflector, you can see the four main water jets, which would dump a tremendous amount of water below the missile engines to facilitate lift and cooling of the engine exhaust.
And this is then looking back up the exhaust manifolds towards ground level ten stories up.

So in summary, this was an amazing tour, and even at $80 and having to make reservations several months in advanced, was easily worth the expense and hassle of having to travel all the way to the middle of Arizona.  If you ever happen to be in the Tuscon area, I urge you to make a point of spending the time to go down and take either this, or even just the standard one-hour control center tour.  In either case, this is an amazing museum which is doing an incredible job preserving a very important piece of American history.

Tuesday, July 10, 2012

Decompressing JPEGs in RAM

As part of my summer computer vision job, I need to write a piece of software that will decompress JPEGs into bitmaps, then process and analyze the images to find and track the hockey players in the scene. Decompressing JPEGs really isn't that difficult; I've been doing all my testing so far using the OpenCV image loading mechanism, and that has been working fine.

The problem is that once I deploy the final system, I'm not going to be able to use the typical JPEG decompression routines, because they expect you to pass them the file path of the JPEG - fine when you are trying to decompress a JPEG file, but I need to decompress JPEGs which are entirely stored in memory buffers, and which are hopefully never even written to disk (due to some fancy mmap trickery).

Luckily, the Independent JPEG Group has been maintaining the de facto JPEG library (jpeglib) since approximately the beginning of time, so this shouldn't be too large of an issue.  Unfortunately, it seems that they didn't add memory buffers as a canned JPEG source until quite recently, so most of the questions online on how to use it are answered simply with "roll your own source manager module."  Further, all the examples that come with jpeglib are for loading from filename.jpg, which simply won't do for what I need.

Long story short, I spent part of an incredibly frustrating day trying to cobble together enough understanding of jpeglib to finally be able to build a working proof-of-concept snippet.  For the good of the Internet, I present to you the ~40 lines of C and ~160 lines of comments which resulted from my frustration, and which finally get libjpeg-8d to decompress a JPEG from a memory buffer.

Source Code:

Monday, July 9, 2012

Birthday Number 23

I'd like to just say thank you to everyone who sent me birthday wishes and presents this week.  It was 23 years ago on July 7th that my wonderful mother brought me into this world, and in what would turn out to be befitting of my personality, I saw little motivation to breathe for myself when someone else had been doing it so well for me for the last nine months.  Luckily, that little road-bump was overcome and I've managed to make a respectably good ado of my first 23 years hanging out around here.

Due to my trip to Dallas and getting back 10AM PDT on my birthday, my family was kind enough to give me a mulligan and we celebrated my birthday on Sunday instead.
The highlight of the day was my favorite - a flourless chocolate cake.  If you get the feeling that it looks like a giant block of dense fudge, don't panic - that is because it really does turn out like a dense block of fudge, and that is awesome.  Of course, it never quite slices well, so I figured I'd apply one of my birthday presents (A manual on lumber woodworking) and cut my cake like a lumber mill, because that's just how I roll.
The birthday gifts were numerous, and I would have inevitably missed some, so I'll only talk about those from my sit-down-to-presents proper.
  • A set of 12" interchangeable driver bits, because a holiday just isn't a holiday without hand tools.
  • Code, Petzold: I was keyed onto this book by Larissa, and it is amazing.  In short, it is a book that explains how computers work.  Like, really work, from the ground up, and he does it really well.  He doesn't use strange analogies to explain computers, but really just starts with a flashlight and a relay, and builds on that until by the end of it you understand how a computer really works.  A great introduction to the subject for anyone who hasn't taken a college processor architecture class yet, regardless of your background (This is one of those technical books that even a mother would understand*).
  • The Ashley Book of Knots: Another of the multitude of things that I totally nerd out about in life is knots.  (While in high school, I was passed down the title "Tetris Master," who is the marching band member responsible for over-seeing the weekly loading of the truck with all the band equipment on the way to band competitions.)  The Ashley knots book is actually so definitive, knots are often simply referred to by the number he assigned them in his index. 
    • Understandably, you maybe not be as excited about spending that much on a tome about knots, and may like more written context about each knot than he provides.  A good alternative for the beginner would be The Ultimate Encyclopedia of Knots & Ropework, Budworth, which can be had for <$10 used.
  • Finally, a set of accessories for the Vixia HF R21 camcorder, which I originally got as my graduation gift, and which all of you should appreciate for the positive impact this will have on the video content of future blog posts.
    •  A 32GB SD card - In the remote chance that a mere 10 hours of recording time will ever not be enough.  The Vixia R21 has the awesome feature of supporting 2 SD cards in addition to the 32GB of internal storage, so we decided to populate one slot with the current capacity sweet-spot and leave the second empty while the storage-price knee continues to move up until there is a definite need for it.
    • A set of 34mm filters - The Vixia has a 34mm accessory thread in front of the lens.  Although 34mm is a somewhat rare size, we were able to find the standard UV, FLD, PL set for it.  This set also came with a cleaning kit and a pocket tripod, which I don't need for my typical use-case (Park-n-bark in front of my electronics workbench), but may be handy if I'm every shooting on the road.
      • UV - Ultraviolet filters are used to reduce general hazyness of images by removing the higher colors which we can't see but which effect the camera's sensor.  This filter is also desirable because it is a much cheaper piece of glass than one's lens, so you would typically leave this one on your camera all the time for protection.
      • FLD - This filter is slightly pink, and is used to normalize light from fluorescent lights, which have a color spectrum which tends to make scenes seem oddly lighted and people appear sickly.
      • PL - Polarizing filters are used to remove the glare from reflective surfaces in scenes (water, etc) and add color depth to sky.  My one complaint is that the filter that came with this set isn't circularly polarized, so you do need to be aware of how far your screw it on for best impact.  Higher-quality PL filters will have an adjustment knob to allow you to rotate the polarization independent of the screw thread.
    • 34mm to 37mm Adapter Ring - Unfortunately, since 34mm is a relatively rare accessory size, to be able to use anything other than your basic filter set requires an adapter ring to the next larger "standard" size, which happens to be 37mm.
    • +1, +2, +4, +10 Macro Lens kit - Since much of my recording will likely be very close-up scenes of small electronics, close focal ability is important.  Of course, no reasonable camcorder user ever needs to focus on things 4" from the lens, so Canon didn't design the Vixia to do so.  I, on the other hand, do need to focus on things 4" away from the camera, so these macro lens simply move the focal length of the camera closer to the lens, in +1, +2, +4, and +10 steps, or any combination of such since they can stack. (I would assume these are measured in diopters, but can't find any solid sources on the matter at the moment).  This of course does slightly reduce the quality of the lens stack as a whole, and removes the ability to focus on things far away, since "Infinity" is now a very finite distance from the camera.  The Amazon reviews knocking this trade-off baffle me...
    • A Vented Sun Hood - In the not-entirely-unlikely event I ever end up shooting outside in actual sunlight, being able to keep sun glare off of the lens itself is important to maintain scene quality.  With the step ring and my Vixia zoomed ALL the way out, you can just pick up this hood in the corners of the scene, but simply zooming in a bit solves that at no appreciable expense.
Again, thank you to everyone who sent me birthday wishes and presents; they were all very much enjoyed and appreciated.

* - I say a mother, because using my mother as an example wouldn't be particularly fair; she majored in computer science and worked for HP writing compilers before coming to the realization that dealing with my antics as  a child full-time would be so much more fun than working.