Tag: gdb

 

gdb ruby $pid

gdb is my “tool of last resort”. When all other online diagnostics have failed, I know enough gdb to pull out a C level stack trace.

  % gdb $SHELL $$
  GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:06:22 GMT 2006)
  /Users/dom/320: No such file or directory.
  Attaching to program: `/bin/zsh', process 320.
  Reading symbols for shared libraries ........ done
  0x90006108 in syscall ()
  (gdb) where
  #0  0x90006108 in syscall ()
  #1  0x00054558 in signal_suspend ()
  #2  0x0002c9a8 in waitforpid ()
  #3  0x0002cb4c in waitjobs ()
  #4  0x00012584 in execlist ()
  #5  0x00011c24 in execlist ()
  #6  0x00011874 in execode ()
  #7  0x00026890 in loop ()
  #8  0x0002945c in zsh_main ()
  #9  0x00001d14 in start ()

It’s not terribly informative, but in the past, it’s given me just enough of a clue to start looking at the SSL libraries (for example).

Jamis Buck has gone one better—he’s pulled a ruby stacktrace from a running process. Which seems quite magical to me indeed. I also think that you can turn most of what he’s done into a gdb macro. I’ll have to have a look at some examples

In the past, I’ve resorted installing a signal handler “just in case” to pull out this sort of information. All of my Perl apps have this in their startup files.

  $SIG{ USR2 } = sub { Carp::cluck("Caught SIGUSR2 in $$") };

Which is all very well, if you know what you need in advance. Which is not usually the case.

Jamis++

Update: Ok, turning it into a gdb macro is dead easy. Save this lot into ~/ruby.gdb

  # A quick hack to show the environment for a Ruby process.

  define printenv
    set $index = 0
    while environ[$index]
      x/1s environ[$index]
      set $index = $index + 1
    end
  end

  document printenv
    Display the environment for the current process.
  end

  define rb_where
    set $ary = (int)backtrace(-1)
    set $count = *($ary+8)
    set $index = 0
    while $index < $count
      x/1s *((int)rb_ary_entry($ary, $index)+12)
      set $index = $index + 1
    end
  end

  document rb_where
    Show the ruby stacktrace.
  end

To use it do source ~/ruby.gdb from the gdb session, and then you get two new commands: printenv and rb_where.

Oh yes, I do know how super-trivial all this would be if only I had DTrace. Roll on Leopard.

My Sysadmin Toolbox

After seeing lots of these at Linux.com recently, I thought I’d try to come up with my own list. I used to be a sysadmin (I’m now a programmer), and I’ve long felt that you really a good set of tools (and to know how to use them) in order to be most productive.

  • zsh

    I spend the vast majority of my time at a command line. Zsh ensures I make best use of my time. If you’ve used bash, you might think you know what completion is—press the tab key and it fills out file names for you. But zsh takes it to a whole new level. Not only does it complete file names, but also users, hostnames, option flags, environment variables, PIDs and more. On top of that, it does it in a context-sensitive manner. So if you type in “chown ” and press TAB, it starts completing usernames. Type in a space and another TAB and it starts completing file names again.

    On top of that, it allows partial completion. If I type in /u/l/e/r/ and press TAB, It gets expanded to /usr/local/etc/rc.d/. This is phenomenally useful.

    But it’s not just completion that zsh is good at. It’s also good at globbing. That’s turning wildcards into filenames. In addition to the usual forms of globbing, zsh can glob recursively. So if I want to look for “foobar” in all my files (but not directories), I can do:

      % grep foobar **/*(.)
    

    The “**/*” is the recursive glob, and the “(.)” limits it to files and not directories. You can also limit by user, by timestamp and a few other things.

    This is just covering the surface of zsh. Suffice to say that if you make heavy use of the command line, investing some time in learning zsh will make you vastly more productive.

  • screen

    This was mentioned on a few of the other lists as well. GNU Screen on the face of it doesn’t do anything. You just end up with another command line when you first run it. But the beauty of it is that if you get disconnected, you can just log back in, run screen -d -r and pick up exactly where you left off. For me, this is ideal, given the flakiness of my home wireless network. But you might want to use it so you can shut down your PC at night and pick up where you left off in the morning.

    On top of that, screen lets you run multiple command lines at once inside it, log the output and cut’n’paste between them. Think of it as a safety harness for your work.

  • rsync

    Rsync is one of the closer things to magic that’s around. It’s a simple file copying utility. But the clever bit is that it only copies the things that have changed. This doesn’t sound like much until you’ve edited several files in a collection which is 200Mb and needs to be on another box. When rsync tells you it’s finished and only transferred 10Kb instead of 200Mb, you’ll really come to appreciate it.

    If you’re still using tar/gzip or zip to create an archive to ship to another computer, stop wasting your time and disk space. Learn to use rsync and your life will be far more pleasant.

  • OpenSSH

    Thankfully, ssh is pretty ubiquitous these days. It seems to have mostly worked in its mission to eliminate telnet. But it has a few tricks that are worth knowing about.

    First, the agent. One of the nice things about ssh is that it doesn’t have to rely on sending passwords around. Instead, you can use public key authentication. However, even typing in your passphrase can get pretty tedious after a while for every connection. Enter the ssh-agent. Just stick eval `ssh-agent` in your startup scripts and then run ssh-add once. After that, you don’t get asked for your passphrase any more. The only caveat is that now you really need to lock your screen when you walk away from it.

    Next are the tunnels. Ssh is able to create network “tunnels” in and out of otherwise secure locations. This is very handy for creating ad-hoc networks. For example, I’m allowed to ssh into my work, but not to anything else. Yet, I can use RDP to connect to my workstation by running this command:

      % ssh -L3389:myworkstation:3389 firewall.mywork.com
      % rdesktop localhost
    

    That says: listen on port 3389, and any connections that come in, forward them on to myworkstation port 3389 from the other side of the ssh connection to firewall.mywork.com.

    If you’re on windows, check out PuTTY. It’s got all the features, but wrapped up in a nice GUI interface.

  • lsof / pfiles / sockstat

    Lsof (List Open Files) is one of the first diagnostic tools that I reach for when I need to understand something. The purpose is simple: it tells you what files (and network connections) a process has open. If you’re wondering where a process is logging to, this might be able to tell you. Conversely, it can also tell you which processes have a particular file open (usually a lock file).

    On Solaris, the pfiles command is similiar.

    On a related note, FreeBSD also has the very, very useful sockstat command, which lists all open sockets and what processes hold them open. The useful bit is that it does this without needing to be root (unlike Linux’s netstat -anp).

  • strace / truss / ktrace

    These are the second diagnostic tool that I reach for when something’s not right. Unix operating systems have a very clear distinction between userland and kernel, and this tool shows all the points where a program crosses between the two (makes a system call). If you really want to know how a program is interacting with its environment, these tools will tell you. It’s godo for answering questions like:

    • What files is this process opening and closing?
    • What connections to the network are being made?
    • What’s been read in by this program?
  • multitail

    A recent addition to my toolbox. It’s like tail -f, except that it looks at more than one file at once. It also does highlighting of search terms. Dead handy.

  • curl

    Most of the stuff I do these days involves the web. Curl is a fantastic little tool for inspecting the web from the command line. It covers all the protocols you need, and can dump out any information about the transaction. Want to issue a PUT request to an SSL server, verifying the certificate and specifing basic auth? It’s got you covered.

  • vim

    Everybody needs a good editor. Vim isn’t the only choice, but it’s pretty likely to be available wherever you go. And once you’ve started learning how to use it properly, you won’t go back. In particular, I can’t live without ^P and ^N for doing completion inside the file you’re editing.

  • sudo

    If you’re still using su, then you need help. Sudo allows you to dole out root access on a much more granular level and you get proper logging of who did what. If you haven’t looked at the manual recently, then check out sudo -e for editing a file as another user. It ensures that you get your regular editor (vim or Emacs) instead of the incredibly unhelpful ed that root probably defaults to.

  • subversion

    Everybody needs version control. If you’re editing files, stick them in subversion. You won’t regret it. Particularly when you need to see what those files looked like 6 months ago.

  • mutt

    Every now and again, you need to deal with mailbox files. Mutt is a great choice for that, thanks to its mini language for filtering mail. Need delete all mail over 10 days old sent by cron@somehost? Not a problem. Even if you don’t use it on a regular basis, it’s worth getting familiar with.

  • gdb

    Yes, this is a programmers tool. But it’s worth knowing a tiny amount about if you’re a sysadmin as well. What for? It lets you see why something dumped core. If you find a core file, then do file core to see what program left it behind and then gdb /path/to/program core. When you’re inside gdb, type in where and it will (most of the time) give you a stack trace, showing what it was doing at the time of the crash. This is normally a big help in trying to figure out what went wrong.

    You can also use gdb to find out what a running program is doing by specifing a PID instead of a corefile.

  • perl / python / ruby

    If you perform the same series of actions more than a couple of times, you should consider investing some time in automating the process. Shell scripts are handy, but can only go so far. Learning one of these languages will give you a really powerful ability to write your own sysadmin toolbox.

  • mediawiki

    Documentation. Everybody hates doing it. Why not make it as easy as possible? A wiki is the answer to that, and mediawiki is one of the better pieces of wiki software out there. It’s pretty simple to get going (although it does depend on MySQL).

    Remember: getting it documented is first priority. Once the information is in the wiki, it can be restructured later. So long as the information is there, it will be searchable (and hence useful).

Hmmm, that’s a bit more than the 10 they wanted. But it’s a large portion of my regular toolkit. Hopefully there’s something useful for other people in there as well…