I’m seeing some funky “new” (to me) behavior that I’m having trouble tracking down. Maybe y’all have seen it before. Using kernel 2.6.18-6-686 (debian etch), I can have a shell script open in vi, and suspend vi to run it. But on 2.6.26-1-686 (debian lenny) I get this error:


host:~/dir# ./shellscript -foo
-bash: ./shellscript: /bin/bash: bad interpreter: Text file busy


If I exit out of vi I can run the script just fine. I can also run the script with “sh shellscript”. strace reveals that the failure is happening super early on:


host:~/dir# strace ./shellscript -foo
execve("./shellscript", ["./shellscript", "-foo"], [/* 19 vars */]) = -1 ETXTBSY (Text file busy)


It looks like the kernel must be checking for exclusive advisory locks before proceeding. I have checked around Google and I see others have had the same trouble, and they’re always told to make sure the file isn’t open by some other process. But I can’t find where new behavior was introduced. Best I can gather, it’s just accepted as the norm now. Seems awfully weird to me.

UPDATE: As noted in the comments, the kernel isn’t doing flock before execve. It’s just preventing you from running commands if the file is open for writing. It’s old behavior. I only saw it now because old nvi didn’t keep the write file handle open (or at least, not in the same way) and new nvi does.

seq is a handy tool if you want a list of numbers:


$ seq 1 4
1
2
3
4


But then they had to go and try to be fancy:


$ seq 1000000 1000010
1e+06
1e+06
1e+06
1e+06
1e+06
1e+06
1.00001e+06
1.00001e+06
1.00001e+06
1.00001e+06
1.00001e+06


What the fuck. (The “fix” is to use seq -f %.f)

One of the most difficult things to deal with while using a Linux desktop is the clipboard. There are apparently two clipboards on my desktop — perhaps more? I’m running Debian Etch w/ Gnome 2 based apps, if that matters.

If you copy text from one window, you may not be able to paste it in to another if it contains certain characters. For example, press releases on Google’s AP site include some sort of double-dash character. If you’re careful not to select that character, you can copy from the page and paste into gnome-terminal or xterm. A more annoying example: to copy text displayed in Flash, you have to select the text, right-click and choose Copy, and then paste it in to some other application such as Firefox or Pidgin. Then copy it from there and paste it to your terminal. It’s a major hassle.

Then there are situations where you’ll copy text in one window and try to paste into another, only to end up pasting something completely different that you’d selected ages ago. It’s almost enough to make me want to switch to Windows at work.

Those of you who use Linux as a desktop: How do you deal with this issue? Or, alternatively, how have you avoided it?

I’ve tried to use glipper, but it doesn’t seem to install properly, at least on my desktop. It won’t appear as a panel option, and when it’s run from the menu, nothing happens. It just sits there and uses CPU time, reading and writing from some buffer over and over again. If glipper really is the shit I’ll try to figure out what’s wrong with my installation of it, but if it’s shit I’ll look elsewhere.

I’ve moved from Iceweasel to Firefox 3 beta4, and I’m in love. The bookmark handling is sweet. You can just edit a bookmark by going to the page and clicking on a little icon in the location bar. You can add and remove bookmarks right there, too. The save-password dialog box has been replaced with a box like the “pop-up blocked” thing that shows up just under the toolbars on FF2/Iceweasel, so you can decide whether or not to save it after you’re sure it was successful.

Best of all, the beta is way faster than Iceweasel ever was.

My only legit issue* with it is the ginormous drop-down that appears when you are entering URLs. If your mouse is hovering over a link in the drop-down, you can’t take proper advantage of the tab-completion — it’ll end up using your URL you’re hovering over. I think that might have been the case before, but it didn’t come up as often because the menu was so much smaller. I’m counting it as a focus issue, something that plagues Linux window managers and applications.

That rant said, I’m giving this browser the dpk stamp of approval.

* That is, other than that some plugins aren’t available for it yet.

Note: This is *way* out of date. But who knows, the patch may still work.

You know how programs like ‘less’, ‘vim’ and apparently ‘mutt’ and others clear the screen when you exit or suspend them? To some, it’s a feature. To others, myself included, it’s an abomination. Ptang Ptang Olay Biscuit Barrel posted animations that demonstrate the wrong way and the right way for terminals to behave.

If you’re using xterm, you can disable this by adding “XTerm*titeInhibit: true” to your .Xresources file. There are simple ways to fix this in most terminal programs I’ve looked up. The one exception: gnome-terminal.

I won’t speculate as to why gnome-terminal, or more specifically, libvte does not offer a way to disable the “alternate screen” functionality. Instead, I just hacked the code up a little. This is a really brute hack (not user-configurable, just a dumb if (0) here and NULL there), and I’m not particularly proud of it, except that I think it might be the first public attempt to resolve this issue at the source. I can’t guarantee these will work for you, of course, but they do work for me. They are Debian packages built on an etch system.

libvte-common_0.12.2-5-dpk1_all.deb
libvte4_0.12.2-5-dpk1_i386.deb

The technical details: What I did was make it so 47, 1047, and 1049 “codes” would not swap between the alternate and the primary terminals. Then I commented out all of the code in 47, 1047, and 1049 and put in a call to vte_sequence_handler_ll which scrolls to the end. Here’s the diff. If one is so inclined, it would be neat to make it an option configurable via gconf, or whatever configuration method is used for vte or gnome-terminal these days. I’m not so inclined because I cannot imagine a scenario in which I would ever want the screen to clear when I suspend a man page or vi.

There’s not very much information online about using a IBM TS3200 (3573-TL) SCSI tape library with the “mtx” utility, and the documentation for the library doesn’t mention much about Linux at all. I’m using rdump, over SSH, and I’ve reached the end of tape. As I understood it, the tape library was supposed to automatically load the next tape in sequence. It did not, so I attempted to do move on to the next tape manually, using “mtx next” or “mtx unload”, both giving the same error: *(See update at the end).

Unloading Data Transfer Element into Storage Element 1…mtx: Request Sense: Long Report=yes
mtx: Request Sense: Valid Residual=no
mtx: Request Sense: Error Code=70 (Current)
mtx: Request Sense: Sense Key=Not Ready
mtx: Request Sense: FileMark=no
mtx: Request Sense: EOM=no
mtx: Request Sense: ILI=no
mtx: Request Sense: Additional Sense Code = 04
mtx: Request Sense: Additional Sense Qualifier = 8E
mtx: Request Sense: BPV=no
mtx: Request Sense: Error in CDB=no
mtx: Request Sense: SKSV=no
MOVE MEDIUM from Element Address 256 to 4096 Failed

According to IBM’s somewhat hard to find information, the error code 70 does indeed mean “Current” as mtx indicates. The sense key means “Hardware error”. The doc references the TSM Appendix C to determine the “Additional Sense Qualifier”, but the information is not actually contained there. I remain unsure exactly what it means. There’s some indication on non-IBM sites that it means the library is in sequential mode (which it is) and that the software needs it to be in random mode. I dunno, random mode doesn’t make a lot of sense to me.

In any case, this error is pretty far from “clear”. I hope this information helps someone in the future. The mtx man page indicates: “You may need to do a ‘mt offline’ on the tape drive to eject the tape before you can issue the ‘mtx unload’ command.” With this library and its autoload configuration, you do indeed need to run “mt offline” and then it will automatically load the next tape in sequence.

Now if only I could figure out why it gives the same errors above when I run “mtx first” or “mtx load 1″ or even “mtx transfer 1 21″ then I’d be set. All of that worked in the past (as in a couple of days ago). Does everyone just use backup management software to handle all of this nowadays? Are we the last “dump” holdouts? I’ll update this post if I figure out a reliable way to use this library with Linux — the last thing we need is more pages with more questions than answers online, and here I go posting one of those. :)

Update: Yes, the library needs to be in random mode to use mtx’s “next” “load” and “unload” commands. Random mode basically means “fully manual” mode, which is exactly what I was hoping to have. Sweet. As far as backup speed is concerned, we’re pushing 230Mbit/s with xfsdump over rsh/ethernet, which isn’t quite up to the drive’s rated speed, but it’s the max we’ve been able to get.

We’re testing a new server from our primary vendor, one which uses Xeon 5130 chips, on the SuperMicro X7DVL-E motherboard. This board uses Intel’s new onboard 82563EB NIC. For some reason Intel designs their NICs to not be backwards compatible in any way, and so each new NIC release seems to require a brand new version of their drivers — I guess we’re using bleeding edge ethernet technology!!!1!1!

Unfortunately, Intel themselves only offer a Windows driver. Searches on Intel for “82536EB linux” and similar queries turn up nothing (Update May ’08: I typo’d. You can indeed find them by searching for 82563EB. I don’t remember if that was the case in ’06.). Strangely, the only place you can find the Linux driver is at Supermicro’s FTP site. The driver is not in to the most recent Linux kernel (2.6.17.8 at the time of this posting).

Loosely following the directions to install Debian on Areca-based RAIDs, I’ve made an ISO that will let you net-install Debian Sarge 3.1 (r0a) on a server with a 82563EB chip. The only differences between this CD and Debian’s official CD are an updated e1000 driver in the nic-extra-modules udeb, in the kernel-image-2.6.8-2-386.deb and in the initrd image. If you choose to upgrade or replace the kernel, you’ll want to rebuild the e1000 driver using the source code found at the FTP server mentioned above.

I can’t provide any support for this ISO, of course. At your own risk, yadda yadda.

FreeBSD users: The mailing lists indicate that driver support for this card is now available in 6.1-STABLE (so install -RELEASE from a CD, and then I guess cvsup on another server, burn the contents of /usr/src/sys to another CD, and sneakernet it over to your new box?), but I still don’t see any notes about it in the CVS commit logs (and they do usually list the chips that are newly supported).

(Updated: It’s not the 82536, it’s the 82563.)

Time zones are a major source of annoyance for me, when writing code or working with databases that store time-keyed data. It’s especially irritating when you have to deal with the abomination that is daylight savings time.

So, I’ve finally decided to go ahead and set my server clocks to UTC (or GMT). It wasn’t hard to figure out how to do this, but documentation for this specific task was rather sparse as most people seem to want to move away from UTC.

On FreeBSD and Debian (Sarge) Linux, you can do this by copying /usr/share/zoneinfo/Etc/UTC to /etc/localtime . On Debian, you’ll want to replace what is currently in /etc/timezone with the string “Etc/UTC”. Then run ntpdate against your favorite time server, and reboot so all applications have the proper timezone setting.

You’ll need to figure out how you want to set your CMOS clock. I’ve left them as they are, set to local time, because it’s not convenient to load up the BIOS and change them. On FreeBSD, if your CMOS clock is on local time, touch /etc/wall_cmos_clock . If UTC, rm /etc/wall_cmos_clock . On Debian (Sarge) Linux, run “hwclock –localtime” or “hwclock –utc”.