Log

Occassionally you'll want to verify that your gigabit network is actually running in gigabit mode.  Or, to futureproof this little post, maybe we're talking about kajigabits.

Anyway, normally there are little mode LEDs on your network hardware that indicate what speed it's operating at.  However, if you aren't in a position to physically see these little lights on the back of your network card or router, or you are but you're too lazy to get off your cushy chair and go look, here are a couple of quick and totally unintuitive ways of examining things using nothing but your trusty shell.

1. Use mii-tool (as root):
   
   • mii-tool -v eth0
   • Look at the 'negotiated' value.  It'll indicate what speed the interface is using.  'FD' means 'Full Duplex'.  'HD' means 'Half Duplex'.  For example, '100baseTx-FD' means 100mbit Full Duplex.
2. Use tcpdump (as root):
   
   • tcpdump -v -i eth0 -c 1
   • Look at what it says for 'link-type', although I'm not convinced this is an accurate method for speed reporting.  But tcpdump is awesome for other stuff, and maybe I just don't know how to interpret what it's saying.
3. Use dmesg:
   
   • dmesg | grep eth0
   • Look for a line similar to one of the following:
     • eth0: link up, 100Mbps, full-duplex
     • e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex
   • It may be that your dmesg buffer doesn't go back far enough to include that.  If so, try one of the other methods.  Or I guess you could cycle the interface down/up, and then peak at dmesg again.
4. Use ethtool:
   
   • ethtool eth0
   • Look for the 'Speed:' value.  Lots of other good info is listed as well.  This technique  is the one that produces the most self-explanatory output, but it probably also the least likely to already be available on your system.

There are a lot of ways to capture image buffers in an X-Org based environment, but I found one that I preferred, and it's ImageMagick's 'import' utility.  Very flexible, and more importantly, well documented and maintained.  Out of the box, it does time-lapse multi capture, which is generally what I'm after when I'm playing games (which I'm doing more and more of on Linux and not on Win32) and I want to have a framegrabber running in the background taking periodic grabs.  A line like the following will get the job done adequately:

import -depth 32 -pause 10 -quality 100 -silent -snaps 5 -window root foobar.png

I'm probably going to cook up a little python script that leverages import, rather than relying on just the command line, since it will provide greater control and flexibility for a session-based use of the tool, and because it looked like import keeps all the grabs in memory until it's done, which isn't suitable for accumulating a lot of images in one session.

This worked a lot better than other attempts with things like scrot, fbgrab, etc..  xv is good for one-off manual grabs, but doesn't provide any automated time-lapse feature, which is what sent me googling in the first place.

I run nightly backup scripts, which email me a summary report that includes, among other things, information on disk usage.

I'd been watching the percentage creep steadily up on my main (root) mount drive with increasing concern, but not sufficient concern to actually investigate what the culprit was and whether or not it was a legitimate use of drive space.

Except the other day the percentage finally got dangerously close to 100%, so I finally had to stop putting it off and figure out what was going on.

Turns out it was embarrassingly simple.  MySQL was happily generating binary log files which tracked Every Single Thing it did, ever, all the time.  Just like it was told to do by my /etc/mysql/my.cnf file (via the 'log-bin' option).  Only apparently the files never go away and don't participate in the normal logrotate process (for obvious reasons, once you understand the purpose of the binary logs).  So they just keep piling up, indefinitely.  To the tune of ~25GB, in my case, for a small set of low-footprint MySQL databases running since about 2006.

Once I understood the situation, it was easily remedied by adjusting the options I supplied to the nightly run of mysqldump (which is what I employ as my MySQL backup method):

--flush-privileges
--flush-logs
--delete-master-logs
--master-data=2

The critical one was '--delete-master-logs', not surprisingly, but the other ones came along for the ride as I waded through the mysqldump man pages.

"Why not just disable binary logging", you ask.  Because they're actually a good thing, which is why they're enabled by default.  In a disaster recovery scenario, they let you bridge the gap between your last full backup and whatever transactions occurred until the point of the disaster.  The issue wasn't that they were being generated, it was that they weren't being cleaned up each time I did a full backup (at which point they become superfluous).

So.. the moral of the story is the age-old lesson that computers always do precisely what you've told them to do, whether you actually want what you asked for or not.

I tripped on this issue awhile back (when a lightning strike killed one of my nics), but in all the recovery chaos I neglected to document the issue.  And so I tripped on it again just yesterday when I juggled nics between two machines.

The issue is that udev makes a note to itself of which mac addresses correspond to which ethernet device indicators (eth0, eth1, etc..), when they're initially discovered.  And then it 'reserves' that indicator, so if, say, you pull out the nic that was eth0 and put in a new one, it won't get eth0, which is non-intuitive (at least if you've been installing nics for years).

The fix is easy, though.  Just edit the following file:

/etc/udev/rules.d/70-persistent-net.rules

You can either delete the line that contains the indicator that you want to reassign, or you can just edit the mac address itself.  A reboot (or possibly even a restart for udev - I don't know I didn't try) will get the new nic exposed as expected.

It can also be helpful to just run: 'ifconfig -a' if you're not sure which nic got assigned which ethernet device indicator.