HallmarcDotNet

Marc Elliot Hall's Blog

Headlines

Thomas wrote about our community Saint Peters, Missouri...

Christmas card is up Check out the Flash...

Blog-o-licious We've got blogs...

Site Redesigned HallmarcDotNet has a new look...

 

Welcome to Marc's Weblog

— also known as my vanity gripe page

From sunny, Las Vegas, Nevada, this is the blog of Marc Elliot Hall, leader and system engineer extraordinaire.


September
Sun Mon Tue Wed Thu Fri Sat
         
25 26 27 28 29 30
2017
Months
Sep
Oct Nov Dec

Thu, 26 Nov 2015


Left Holding (Open) the Bag


Filesystem inode Trouble Part II

You may recall that in January, 2014 I wrote a piece about inodes and filesystems behaving badly. At the behest of a colleague (Hi, Josh!), this is the exciting conclusion to that saga.

When last we left the action, my free disk space looked like this:

[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 9.9G 7.6G 1.8G 81% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/sda1 485M 70M 390M 16% /boot
/dev/sda5 4.0G 808M 3.0G 22% /tmp
/dev/sda7 53G 670M 50G 2% /var
/dev/sda3 5.0G 216M 4.5G 5% /var/log

Yet, ordinary users were unable to log in, and I could not create new files on the root (“/” ) filesystem.

To summarize thus far:

  1. My users can’t log in.
  2. I have disks, which the OS has identified.
  3. I have filesystems on the disks.
  4. I have mount points for the filesystems.
  5. I probably even have mounted those filesystems.
  6. I was able to rebuild the mounted fileystem table.

After digging about and recreating the filesystem description table, I determined that the system had run out of inodes:

[root@localhost ~]# df -ih
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 982K 632 982K 1% /dev
tmpfs 985K 1 985K 1% /dev/shm
/dev/sda2 640K 640K 0 100% /
devtmpfs 982K 632 982K 1% /dev
/dev/sda1 126K 50 125K 1% /boot
/dev/sda5 256K 96K 161K 38% /tmp
/dev/sda7 3.4M 3.4K 3.4M 1% /var
/dev/sda3 320K 177 320K 1% /var/log
tmpfs 985K 1 985K 1% /dev/shm
tmpfs 985K 1 985K 1% /dev/shm
tmpfs 985K 1 985K 1% /dev/shm

A quick reminder about inodes: Linux (and other Unix and Unix-like operating systems) in their default configuration use inodes to keep track of what file goes where on the system’s disks, and to keep metadata about the file (user and group ownership, creation time, read and write permissions, etc.). Think of inodes as the index for the file system: at least one inode for each file (you will have more than one inode per file if the file is linked to multiple locations in your filesystem). Unfortunately, there are a finite number of inodes available (varying from filesystem to filesystem and configuration to configuration, but typically numbering well into the tens of thousands), and when they run out — even if the system has more raw space available — it can’t create any more files. Moreover, the number of inodes a filesystem has cannot be (easily) changed after it is created.

Fortunately, there is a simple solution!

Unfortunately, I no longer have access to the system that I was troubleshooting when I wrote my earlier post. However, the fix is pretty universal. With a little script-fu, we can find out how many files each directory in the filesystem has. Once we have identified the quantity and location, we can determine whether there is any particular reason to keep those files. Most of the time in a situation like this, some runaway process has been spewing data that doesn’t get cleaned up properly, either because the process never terminates or because the process isn’t properly coordinating with tools like logrotate. If the data being spewed is a bunch of small files, we can then simply delete the files.

To start, then:

echo 'echo $(ls -a "${1}" | wc -l) ${1}' > /tmp/files_`date +%F`
chmod 700 /tmp/files_`date +%F`
find . -mount -type d -print0 | xargs -0 -n1 /tmp/files_`date +%F` | sort -n | tail -10

This will:

  1. Generate a list of directories in the root filesystem;
  2. Count the number of files in each directory;
  3. Spit out the list with two columns:
    • the right column with the directory name,
    • the left column with the file count;
  4. Sort the two-column list by the file count value;
  5. If the list is more than 10 lines, only show you the 10 with the most files.

Usually, the directory with the most files is your culprit. You’ll want to verify that, then determine whether you should just delete the oldest umpteen files in that directory, all the files in the directory, or whatever other subset is appropriate. You’ll also want to correct whatever process is generating the files. Short of rewriting the program that spewed so much data, you can fix this a number of ways. Three straightforward methods are:

  1. Set up a wrapper script that manages it properly,
  2. Create a logrotate script to clean it up, or
  3. Build a cron job that will periodically do that for you.

Don’t forget to delete your temporary file:

rm -f /tmp/files_`date +%F`

Happy hunting!

posted at: 20:20 |


Mon, 27 Jan 2014


Network Neutrality Setback

Network Neutrality is an issue that I've been following for a long time.

The premise of Network Neutrality is that ISPs (like Cox, Comcast, and AT&T) should prioritize protocols (web traffic before email or DNS lookups before bit torrent) and regulate bandwidth hogs on their networks however they feel appropriate for their business. However, they shouldn't be allowed to prioritize content providers (Netflix over YouTube, hallmarc.net over Facebook), or their own content over their competitors'.

Recently, a federal appeals court ruled that the FCC's Network Neutrality regulations were invalid because the FCC has not chosen to classify broadband Internet access the same way it classifies your home phone — as a telecommunications service with equal access to all. If the FCC reclassifies Internet access, Network Neutrality will be restored.

Although you may not particularly admire the ACLU, I urge you to sign their petition in support of restoration of Net Neutrality.

If you are unsure about whether to take my word for it, or have questions about the implications for society at large, please refer to these resources for more information:

As always, I am happy to answer any other questions you might have.

Thank you! I appreciate your thoughtful consideration.

posted at: 12:13 |


Wed, 08 Jan 2014


I’ve Run out of Places to Put Stuff


Filesystem inode Trouble

When I want to find out how much space is available on a server, I use the df command, usually with a flag like -h for “human readable”. This provides me with a nice summary of space in the filesystems, in this case showing me that my root ( “/” ) filesystem has 1.8 GB available out of 9.9 GB total, for example:

[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 9.9G 7.6G 1.8G 81% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/sda1 485M 70M 390M 16% /boot
/dev/sda5 4.0G 808M 3.0G 22% /tmp
/dev/sda7 53G 670M 50G 2% /var
/dev/sda3 5.0G 216M 4.5G 5% /var/log

Sometimes, things go dramatically awry, however. For example, I recently encountered a situation where ordinary users were unable to log in to a host. I could only log in as root. This is generally a bad practice (and not everybody should have the power of root anyway), so I went about troubleshooting. Among the things I did was check whether any filesystems were full with the aforementioned df -h command.

And I got this output:

[root@localhost ~]# df -h
df: cannot read table of mounted filesystems

This is suggestive of a major problem. The system is running, obviously. And, this is good: it means that the system can read at least a couple of the filesystems directly. It just can’t summarize their status for me.

So, I look at the file that is supposed to contain the table of mounted filesystems:

[root@localhost ~]# cat /etc/mtab

No output at all sad

Then I look at the partition table (using fdisk -l), to see what the system thinks its disks look like:

[root@localhost ~]# fdisk -l

Disk /dev/sda: 80.5 GB, 80530636800 bytes
255 heads, 63 sectors/track, 9790 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d5e85

Device Boot Start End Blocks Id System
/dev/sda1 * 1 64 512000 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 64 1370 10485760 83 Linux
/dev/sda3 1370 2022 5242880 83 Linux
/dev/sda4 2022 9791 62401536 5 Extended
/dev/sda5 2023 2545 4194304 83 Linux
/dev/sda6 2545 2800 2048000 82 Linux swap / Solaris
/dev/sda7 2800 9791 56156160 83 Linux

So far so good: this system knows it has a disk (/dev/sda) with partitions (sda1 through sda7); and it at least can identify the type of filesystems they contain.

Just in case any of the fileystems aren’t mounted, using mount -a I attempt to mount them all:

[root@localhost ~]# mount -a
mount: /dev/sda1 already mounted or /boot busy
mount: /dev/sda5 already mounted or /tmp busy
mount: /dev/sda7 already mounted or /var busy
mount: /dev/sda3 already mounted or /var/log busy
can't create lock file /etc/mtab~1605: No space left on device (use -n flag to override)
mount: devpts already mounted or /dev/pts busy
mount: sysfs already mounted or /sys busy

That looks mostly good; they’re already showing as mounted (or just busy, but that’s a rather improbable situation). However, I see the line that says can't create lock file /etc/mtab~1605: No space left on device (use -n flag to override), which worries me. Quite a lot.

Looking a little deeper, I try to see whether /etc/mtab (my mounted file system table file) even exists at all:

[root@localhost ~]# ls -l /etc/mt*
-rw-r--r--. 1 root root 0 Jan 3 09:20 /etc/mtab

It’s there, but has zero bytes! That means the file is empty. It should contain enough information to describe the mounted filesystems — always more than zero bytes.

To summarize thus far:

  1. My users can’t log in.
  2. I have disks, which the OS has identified.
  3. I have filesystems on the disks.
  4. I have mount points for the filesystems.
  5. I probably even have mounted those filesystems.
  6. But, before I can check the status of the filesystems, I’ll have to force the system to rebuild the mounted fileystem table.

Fortunately, because Linux has a virtual filesystem containing information about the current running environment kept entirely in system RAM (the /proc filesystem), using grep and I/O redirection I can export the contents of the known mounts file ( /proc/mounts ) into a new /etc/mtab file and try my df command again:

[root@localhost ~]# grep -v rootfs /proc/mounts > /etc/mtab

Now I can see that my /etc/mtab file contains 1423 bytes:

[root@localhost ~]# ls -l /etc/mt*
-rw-r--r--. 1 root root 1423 Jan 3 09:30 /etc/mtab

Then I can check whether the system can tell me about the filesystems using df and the -h flag:

[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 9.9G 7.6G 1.8G 81% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/sda1 485M 70M 390M 16% /boot
/dev/sda5 4.0G 808M 3.0G 22% /tmp
/dev/sda7 53G 670M 50G 2% /var
/dev/sda3 5.0G 216M 4.5G 5% /var/log

It claims I’ve got plenty of space! Why, then, can I not use touch to create a file in the / directory, let alone log in as an ordinary user?

Possibly, because the inodes are all used up. But, “What are inodes?” you ask… Linux (and other Unix and Unix-like operating systems) in their default configuration use inodes to keep track of what file goes where on the system’s disks, and to keep metadata about the file (user and group ownership, creation time, read and write permissions, etc.). Think of inodes as the index for the file system: one inode for each file. Unfortunately, there are a finite number of inodes available (varying from filesystem to filesystem and configuration to configuration, but typically numbering well into the tens of thousands), and when they run out — even if the system has more raw space available — I can’t create any more files; thus our current problem.

Fortunately, now that my mounted filesystem table has been rebuilt, I can check for what inodes are looking like using df and the -i flag:

[root@localhost ~]# df -ih
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 982K 632 982K 1% /dev
tmpfs 985K 1 985K 1% /dev/shm
/dev/sda2 640K 640K 0 100% /
devtmpfs 982K 632 982K 1% /dev
/dev/sda1 126K 50 125K 1% /boot
/dev/sda5 256K 96K 161K 38% /tmp
/dev/sda7 3.4M 3.4K 3.4M 1% /var
/dev/sda3 320K 177 320K 1% /var/log
tmpfs 985K 1 985K 1% /dev/shm
tmpfs 985K 1 985K 1% /dev/shm
tmpfs 985K 1 985K 1% /dev/shm

Yup, out of inodes on the / filesystem. What to do?

Join us next time for the exciting conclusion!

posted at: 16:37 |


Fri, 03 Jan 2014


Take this job…


I/O Redirection

Linux shells (and Unix shells before them) have three popular methods for passing data around: STDIN (standard input), STDOUT (standard output), and STDERR (standard error). To keep things simple, think of STDIN as your keyboard, STDOUT as your screen, and STDERR as, uh, your screen when something breaks. As you will see later, there are nuances — STDIN isn’t always the keyboard, nor are STDOUT and STDERR always your screen.

Let’s start with a simple reason for knowing what STDIN, STDOUT, and STDERR do. For example, sometimes I want the output of a command to go somewhere besides the screen right in front of me. Instead, I may want the output to go to a new file, fileout.txt, so I can read it later.

To do this, I would redirect the output from my command, like so:

ls foo > fileout.txt

That “>” means “take standard out from the previous command (ls foo) and redirect it to the named file (fileout.txt); if the file already exists, overwrite it with whatever output I give you”. It’s what’s called an I/O redirection operator. Other such operators are < (take the following file and give its contents to the preceding command) and >> (append the output of the previous operation to the following file; if the file doesn’t already exist, create it).

STDIN, STDOUT, and STDERR have numbers, too. STDIN is 0, STDOUT is 1, and STDERR is 2. When using I/O redirection operators without an identifying number, the shell presumes that you want to reference STDOUT. However, you can always choose to explicitly use the numbers. Let’s say I want STDERR to be redirected to a file:

ls foo 2> fileerr.txt

After running the command, fileerr.txt would contain text like this:

ls: cannot access foo: No such file or directory

Presuming, of course, that a file named “foo” does not exist in the current directory.

Naturally, there are ways to combine redirection operators to make scripting output less verbose and avoid having your system administrator contact you about your abuse of the system.

Join us next time for another exciting episode!

posted at: 09:43 |



Take this job…


I/O Redirection

As previously discussed, sometimes I want the output of a command to go somewhere besides the screen right in front of me.

For example, I have a script running from cron — which has no screen to which it should send its output. On many Linux and Unix systems, it will instead generate an email, which is generally sent to the system administrator. She probably doesn’t want to see the output of my script, however. Especially if there are 50 users on the system, all of whom are sending script output to email. And we certainly don’t want the output to go to the great bit bucket in the sky… At least not until we learn about /dev/null.

Instead, I want both <STDOUT> and <STDERR> to go to a file. Earlier, I showed you how to send either <STDOUT> or <STDERR> to a file. However, I can also combine these into a single I/O redirect, like so:

ls 2>&1> foo

This has taken the <STDERR> and redirected it to the same file descriptor as <STDOUT>, which is then dumped to a file. This is rather complicated to type, so more recent versions of some shells provide a shorter method:

ls &> foo

But what if I want my <STDOUT> and <STDERR> to go to two different files? Stay tuned…

posted at: 09:43 |


Wed, 04 Jul 2012


“Once Upon a Time…

…there was a magical place where it never rained.”

So goes the line from Holes, when Mr. Sir is explaining to the inmates of Camp Greenlake that they should not expect any reprieve from the oppressive heat.

“The end,” he finishes.

Moving to Las Vegas made me feel a lot like that… Except today, on July 4, 2012, it rained.

Although I have photographic evidence, I cannot upload it from my phone at the moment sad

posted at: 22:19 |


Wed, 25 Apr 2012


Playing Alaska Tourist (Part 1)

Having now wrapped up my project with GCI, I’m ready to have a few days of fun before I head back to the lower 48. (Wow! Don’t I sound just like an Alaskan?)

Two things I wanted to do before heading south were to visit the Alaska Aviation Museum and see some wildlife on the water. So, I drove south along the highway to Seward, Alaska’s only year-round ice-free port with access to the interior. There, I boarded the Orca Song for a tour around Resurrection Bay.

thumb.20120423_012.jpg

Out on the water, I saw Sea Lions,

thumb.20120423_028.jpg

A huge variety of birds, and the namesake of my transport, the highlight of the trip:

thumb.20120423_034.jpg

A pod of whales, including a very young orca, still juvenile tan instead of black and white. I apologize for the poor quality of the photos… The orcas were not cooperating, although the baby was so cute! The battery on my phone was about to die and getting these two shots was difficult as it was.

thumb.20120423_035.jpg

posted at: 21:12 |


Sat, 07 Apr 2012


Farewell Anchorage

My work here in Anchorage is about done, so this entry will be a dump of all the photos I haven’t been able to use in previous postings but still think are representative of my last three months.

The Tony Knowles trail down to the Cook Inlet is clear!

thumb.20120406_003.jpg

Look at those daredevils out there on the ice…

thumb.20120406_002.jpg

Sunset over the Cook Inlet:

thumb.20120403_002.jpg

The view up from Ship Creek to the downtown skyline:

thumb.20120318_004.jpg

A map of Anchorage as it was originally planned (from the Anchorage Museum):

thumb.20120218_004.jpg

Anchorage as it actually is:

thumb.20120318_001.jpg

I’m just kidding about that… This is where they store the signage for the farmers’ market that goes up once all the snow has melted.

Here’s the Statehood monument overlooking Ship Creek:

thumb.20120212_001a.jpeg

Last but not least, the best picture I could get of the Northern Lights:

thumb.20120308_002.jpg

Unfortunately, the lights of Anchorage are too bright when reflecting up from the snow to see much of a view of the Aurora Borealis. My chief regret from my time in Anchorage is that I was unable to get more than a smudgey glimpse of the Northern Lights.

posted at: 21:12 |


Mon, 02 Apr 2012


Farewell Winter

Anchorage has been a good place to visit this winter, despite all my kvetching.

Spring is nearly here…

thumb.20120330_004.jpg

If you look closely, you can see grass under those trees!

thumb.20120330_003.jpg

So now that I’ve experienced the harsh reality of an Anchorage winter, I’m leaving for warmer climes… And I won’t see the glory that is Alaska in summer.

posted at: 21:12 |


Sun, 01 Apr 2012


Spring

We've had several consecutive days of above freezing weather here in Anchorage. The roads have mostly cleared of ice, although a few patches of black ice hide in the shadows. The sidewalks are occasionally a bit dangerous, but since the second or third day of the thaw they've been much less icy.

Folks here in Alaska call this "break up", and it's much like you'd expect from a phrase like that — you never know what the mood of the weather will be; you never know what you're about to put your foot in; and you never know when you're going to embarrass yourself by falling on your butt.

Generally, though, it's shirt-sleeve-warm and pleasant for mid-day walks, at least for a larger guy like me. But when the sun sets at around 8:30 p.m., it doesn't take long for it to get quite chilly. The puddles ice over in about thirty minutes and footing is treacherous from not long after that until an hour after sunrise at about 8:30 a.m. .

When I go on my early evening walks, I keep an eye out for scenery worth sharing — during break up, there's not much of that, because the snow is an ugly brown and the roads are a wet black. There's not much that's photogenic about Anchorage right now. 

However, I did catch a couple of glimpses of spring greenery this week. Here are a couple of blades of grass just trying to poke out of the cold, damp earth.

thumb.20120330_001.jpg

Hope springs eternal! 

 

posted at: 00:46 |


Tue, 27 Mar 2012


Road Trip II

Last weekend I took advantage of some clear weather and clear-ish roads to take another road trip. This one was south along the Seward Highway, which runs along the Turnagain Arm of the Cook Inlet.

The fjord-like waterway is stunningly gorgeous.

thumb.20120324_001.jpg

This a view from the north side of the Arm looking south across the water. In the foreground, you can see the railroad tracks that run between the road and the water. Across the center of the channel are broken blocks of ice, each about half the size of a small car. While I was driving, I didn't notice this; but the water is flowing out toward the Inlet. You can tell because the ice is moving swiftly downstream. Very swiftly. Dangerously swiftly.

As I drove further along, I came upon the town of Girdwood. From one perspective, Girdwood is 40 miles from Anchorage. However, from a strictly legalistic perspective, Girdwood is inside Anchorage, because the Anchorage City limits are enormous, encompassing a goodly portion of Alaska's Chugach State Park. Girdwood is perhaps best known for its famous ski resort, Aleyeska. Here are a pair of views of the chair lift from the main road through town:

thumb.20120324_011a.jpeg

If you look closely, you can just see the main lodge at the base of the mountain and the chairlift wending its way up the snow face.

thumb.20120324_012a.jpeg

I also tried to capture some panoramas of the Turnagain Arm, but haven't yet stitched them together. We'll save that for another post, I suppose.  

posted at: 00:55 |


Mon, 19 Mar 2012


Road Trip

Just because I'm in Anchorage in dead of Winter doesn't mean I can't get out and see Alaska. Sometimes the weather even cooperates.

For example, two weeks ago I drove north up the Glenn Highway to see if I could catch a glimpse of Denali. While I only got about 20 miles past Wasilla (you betcha, that Wasilla) before the cloud cover rolled in, I did get a view of some mighty pretty mountains.

thumb.20120310_005.jpg

This is the northern end of the Chugach mountain range that borders Anchorage to the east; it forms the southeastern edge of the Knick Arm of the Cook Inlet, just off the Gulf of Alaska. Anchorage sits at the confluence of the Knick Arm and Turnagin Arm of the Inlet, and each arm is fed by a river.

I’d put a map here, but Google isn’t cooperating… Instead, here’s a link to the region.

So, while I didn't get to see the tallest mountain in North America, I did see some spectacular scenery.  

posted at: 16:10 |


Wed, 14 Mar 2012


Cold? What’s a Little Cold to an Alaskan?

I know I've griped about how cold it can be in Anchorage (true to form: my car thermometer said 6F this morning).

But the people who live here year 'round, year after year, don't let a little cold get in their way of a fun time!

Witness the fairway laid out for the week of the Fur Rendezvous (affectionately and illiterately known as the Fur Rondy around here) and the Ceremonial Start of the Iditarod:

thumb.20120303_001a.jpeg

Nobody's on the rides at the moment I took the photo because they're all on Fourth Street for the Ceremonial Start. Don't let that fool you!

thumb.20120303_037a.jpeg

In case you missed my comments about it being cold, allow me to show you this evidence:

thumb.20120303_039.jpg

This is the starting point of a several mile walk that follows a scaled-down path through our solar system. Mercury and Venus are both less than two blocks away, while Pluto (yes, it still has Pluto despite that celestial body's demotion to planetoid) is out past the airport.

But just so you don't miss the point: that's right, folks. It's so cold in Alaska, it even snows on the sun!

 

posted at: 00:03 |


Tue, 13 Mar 2012


Where Does All the Snow Go?

As I've previously blathered, it snows a lot here in Anchorage. And, as I've shown in pictorial splendor, equipment runs night and day to remove it.

Since the weather is clearly too cold for the snow to melt, where does it go?

Here:

thumb.20120214_002a.jpeg

That mountain of snow is about forty feet high, and there are piles just like it all over town. 

posted at: 00:01 |


Fri, 09 Mar 2012


People Mover

The Anchorage bus system is called the People Mover, and it's a popular way to get around.

This week, I bought a 2002 Subaru Forester and returned my rental car. I figure, even if I lose $1400 dollars when I sell it after I'm through in Alaska, I'll be farther ahead than if I keep paying $750 a month for a rental car. I could be driving a BMW or Mercedes for that kind of payment. 

But no, instead I bought an econobox AWD car with nearly 150 thousand miles on it:

thumb.2002 Subaru Forester 1.jpg  

Doesn't she look like she's ready for an Alaskan winter? And camouflaged, too!

So why did I bring up the People Mover?

Well, dropping off the Chevrolet Aveo rental car and picking up the Subaru Forester took some logistical effort. 

My plan was to walk to the bus station, ride the bus out to Tudor Road, pay for and pick up the Subaru, drive it downtown, walk to the condo, drive the Chevy out to the airport, and ride the bus back downtown. Total distance: less than twelve miles. The People Mover is a hub-and-spoke system; while there are some places where you can transfer directly from bus to bus on the side of the road, most lines converge at three major hubs. I was going to have to ride two buses, so I needed to be at the downtown terminal to switch. 

As I've mentioned before, I enjoy walking around downtown Anchorage and seeing the sights. I've walked past (and into) museums, galleries, restaurants, bars, stores, coffee houses, parks, and neighborhoods. I've even walked past the People Mover downtown terminal and transfer station. Many times. 

However, on Wednesday, when I was ready to pay for and pick up the car, I couldn't find it! I wasted a good 25 minutes looking for it before giving up and driving the Chevy out to Tudor Road. Obviously, I wasn't going to be able to pick up the Subaru right then, as I would need two drivers for the two cars.

So the seller and I did the paperwork, I gave him a check, and I drove the Chevy to the airport. On the way to the airport, I wanted to fill the gas tank, since Alamo would have likely charged me $23 a gallon to do it for me. I stopped at a Holiday station on the way and swiped my card at the pump, which promptly told me to talk to the cashier. Well, I didn't want to talk to the cashier — I needed to get to the airport early enough that I would have time to catch the bus back downtown and then outbound to Tudor Road before they stopped running for the night. So I jumped in the car and drove to another gas station. 

Which did the same thing. 

This time, I did talk to the cashier. My card had been declined. Frustrated — and in a hurry — I paid with cash and drove off to the airport. At the Alamo drop off, I returned the car and asked for directions to the bus stop at the airport terminal. It was right across the street, and I was going to be able to catch the next inbound bus!

However, once I reached the terminal, I realized that the Citibank Rewards MasterCard was not going to miraculously fix itself, so I walked into the (warm!) terminal and called customer service to see what the problem might be. After ten minutes on hold, my call was dropped. I called back. After 15 minutes on hold, I was told a security flag had been raised on my account and I needed to talk to the security department. After 15 more minutes on hold — well, by now I'd missed my bus. Twice. But, the security department finally told me, the Holiday station had reserved $50 of my credit line when I swiped my card, and that had raised a flag. Well, when gas is $4.08 a gallon, it doesn't take much of a tank to use $50 worth. Their algorithm was a little over sensitive. So, I had missed my bus — possibly three times if you count having to stop at two gas stations and waste time with an attendant — and wasted more than an hour dealing directly with CitiCard's customer service. But! Now I could get on the bus and ride downtown. It was about 9:30 p.m.

thumb.20120307_002.jpg

I've been on a lot of buses, in a lot of cities. In more than one country. I commuted daily by bus and light rail for more than two years as a young man, before I bought my motorcycle. I'm used to buses and the types of people who ride them. And, inbound to the downtown terminal from the airport, the driver and my fellow riders were exactly what I expected: friendly, courteous, and quiet. 

However, when I reached the downtown terminal, I experienced a new environment. 

Indoors, it was chaotic and noisy; shouting drunkards arguing with transit cops, groups of disaffected youth in ragged clothes. Panhandlers insisting I give them my change. Outdoors, it was almost as noisy; the thick cigarette and marijuana smoke choked me; the calls asking if I wanted to buy (or sell) marijuana were aggressive; the clusters of tokers were arguing about who got the next drag — basically, it was like high school, only with old people. 

For obvious reasons, I didn't take any photos. 

Amid the chaos, I saw an approaching bus. "Out of Service" it said, but it was pulling up to the stop for the route I wanted to board, and it was not time for any other bus routes to have stopped there. The driver shut down the engine, walked to the back to verify it was empty, and then exited the bus. He was five minutes early, but I was eager to be on my way, so I stood by the folding doors and waited for him to return. Which he did just a few minutes later. Sure enough, the indicators on the bus changed to announce that this was my ride. I climbed aboard, paid my $1.75, and took a seat. The driver greeted me with a friendly word or two as I boarded.

And, again, the ride itself was quite pleasant. So, apparently, it's the terminal itself that has issues, rather than the buses.

As we approached the neighborhood where my Subaru waited, I tugged the stop request cord. The driver coasted to a stop, I thanked him, exited, and began walking through the dark. As the bus pulled away, though, I noticed that the pavement was very slippery. Dangerously so. 

Despite noticing this, though, I was not being particularly careful. I had realized on the ride outbound that my GPS mount was still in my rental car; I was fiddling with my phone getting ready to call Alamo when my feet began skidding uncontrollably across the ice. Suddenly, I was on the ground. My hip had smacked the sidewalk. Fortunately, nothing — including my phone — was broken. In fact, as I recovered my feet, I felt like I had avoided any injury. Walking the remaining block, I unlocked the Subaru, started her up, and began driving to my condo. Since I had already added them to my speed dial, I called the Alamo desk. "You probably hear this a lot", I said, "but I think I left my GPS mount in my rental car. Can I swing by the garage right now to retrieve it?" The clerk laughed and asked when I had dropped off the car. When I told her at about 7:30 that evening, she replied that more than a dozen GPS mounts had been left in vehicles since 4:30 that day. "So, that's 'yes', you do hear that a lot," I said. She laughed again.

Now it was close to 10:00.

I drove into the rental return garage at the airport, parked, and stepped over to the attendant's booth. "Hey," I said. "I just called…" Before I could finish, the attendant held out the GPS mount for me. "Thanks!" I said. And I meant it. Now I could go home.

So, finally, my ordeal completed, I parked at my condo at 10:30. Four hours from the start to finish. But I was done. 

It was only today that my neck and hip started to hurt. So, while I now know exactly where the People Mover terminal is, I didn’t get away clean.

posted at: 21:21 |



Marc Elliot Hall St. Peters, Missouri 

Page created: 21 January 2002
Page modified: 31 December 2009

spacer About Us | Site Map | Privacy Policy | Contact Us | ©1999 - 2009 Marc Elliot Hall