how to restart a gunicorn server without leaving vim

I’ve been using the gunicorn WSGI server lately while I work on my next project. gunicorn is fantastic, except for one tiny nuisance. I have to restart gunicorn as I change my app code. At the beginning, this meant I would switch over to the terminal where gunicorn was running. Then I’d kill the parent process by hitting CTRL+C, and then start it up again, by typing:

gunicorn crazyproject.webapp:make_application

Other frameworks often have a development mode that forks off a helper process that watches the source code folder. When some file changes, the helper tells the server to reload.

I’m not using any frameworks this time, so I don’t have that feature. I never really liked the fact that every time I saved a file, I would restart the server during development. Instead, in this case, I want to easily restart gunicorn, but only when I want to, and I don’t want to leave my editor.

It turned out to be pretty easy to do.

First I read in the excellent gunicorn docs how to tell gunicorn to reload my app:

How do I reload my application in Gunicorn?

You can gracefully reload by sending HUP signal to gunicorn:

$ kill -HUP masterpid

Next I added a –pid /tmp/gunicorn.pid option to the command that I use to start gunicorn, so that gunicorn would write the parent’s process ID into /tmp/gunicorn.pid.

Now any time I want gunicorn to reload, I can do this little command in a terminal window:

$ kill -HUP `cat /tmp/gunicorn.pid`

Those backticks around cat /tmp/gunicorn.pid tell the shell to do that part of the command first, and then feed the result into the rest of the command.

You can always use ! in vim to run some command-line program. If I had to explain the difference between vim and emacs, the one difference that is most interesting to me is that vim makes it super-easy to send buffer contents to other programs or read buffer contents from other programs, while the people behind emacs seem to think that any external dependency should ultimately be moved into emacs itself. I get the feeling that vim wants to be my text editor, but emacs wants to be my OS.

Anyhow, while I’m in vim, I run that command to restart like this:

: !kill -HUP `cat /tmp/gunicorn.pid`

After using that code for a while, and feeling confident it worked right, I mapped F12 in vim to do that action for me by adding this little thing to the end of my ~/.vimrc:

:map :!kill -HUP `cat /tmp/gunicorn.pid`

Now that means I hit F12 when I want to reload gunicorn.

How to connect to a wireless network from the Ubuntu command line

Why use a friendly GUI when there’s cryptic shell commands out there?

Phoenix Coffee offers free wireless access without an access key and they broadcast their ESSID. Here’s how I connect:

$ sudo iwlist eth1 scan # eth1 is my wireless card.
eth1 Scan completed :
Cell 01 - Address: 0A:1D:19:15:C2:C1
ESSID:"bestcoffee"
Mode:Master
Channel:5
Frequency:2.432 GHz (Channel 5)
Quality=88/100 Signal level=-44 dBm Noise level=-81 dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=0000003befa89182

That scan lists every available access point. The important piece of information to extract here is the ESSID. Now I set my wireless card up to connect to that ESSID:

$ sudo iwconfig eth1 essid "bestcoffee"

And finally, I tell my card to request an IP address from the router:

$ sudo dhclient eth1 # gimme an IP address plz!
There is already a pid file /var/run/dhclient.pid with pid 6911
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/eth1/00:1c:bf:96:7e:21
Sending on LPF/eth1/00:1c:bf:96:7e:21
Sending on Socket/fallback
DHCPREQUEST of 192.168.1.112 on eth1 to 255.255.255.255 port 67
DHCPACK of 192.168.1.112 from 192.168.1.1
bound to 192.168.1.112 -- renewal in 251284 seconds.

I can type these three commands way faster than waiting for the GUI to fire up. Here they are again, without all the output:

$ sudo iwlist eth1 scan
$ sudo iwconfig eth1 essid "bestcoffee"
$ sudo dhclient eth1

Sometimes, I need to connect to a network with a hidden ESSID. That’s just as easy. I just configure the ethernet card to connect to anything:

$ sudo iwconfig eth1 essid any # any is a keyword, not the name of an ESSID.

Finally, some networks require an access key. Sometimes, people can give you the human-friendly version, and you can type that in like this:

$ sudo iwconfig eth1 key s:password # translates to the hex for me.

Note the s: in front. That translates what I type into the hex jibberish.

Other times, people insist on giving you the goofy string of hex digits, so you can set it like this:

$ sudo iwconfig eth1 key ACDB-1234-1234-EFG2

Frustration with postfix and sending email to a script

I want to set up an email address that executes a script with every incoming email, so in my /etc/aliases, I did this:

runscript: |/usr/local/bin/email_reading_script.py

Then I rebuilt the postfix alias db with sudo postalias /etc/aliases, and then sent an email to runscript@localhost. That’s when the fun began. The script is run by nobody/nogroup, so it couldn’t log to my logging directory, because I require people to be in the adm unix group.

Then I created a user named runscript, and moved that | /usr/local/bin/email_reading_script.py line into a .forward file. I added adm to runscript’s unix groups.

AND STILL NO JOY.

I don’t know why, but when the script runs, the shell only seems to get the primary group. So, I kept getting permission-denied errors. I finally got stuff to work when I set adm to be the primary group for my runscript user. Now everything is OK.

This ate up the better part of the @#$@#$ing day. Grr.

If this didn’t work, I was going to install procmail and go down that route.

Am using ubuntu hardy heron.

My ten most-frequently-used shell commands

Here they are:
$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
80 cd
59 svn
49 bzr
40 sudo
35 vi
32 nosetests
26 l
15 rfcomm
14 screen
14 c

l is an alias for ls and c is an alias for clear. rfcomm is how I connect to my mobile phone over a virtual serial port via bluetooth.

I’m happy that vi and nosetests are right next to each other. It looks like I’m pretty good about rerunning my test cases after editing.

I got the idea for this post from this guy.

My .screenrc is a testament to obsession over meaningless details

Most every time I start a new screen session, I set up four windows using particular window names. After several hours of reading the screen man page and trying stuff out, I discovered how to automate the process. I added this section to my .screenrc:

screen -t ipython 0 /usr/bin/ipython -p matt
screen -t code 1 # This is where I use vi.
screen -t psql 2 /usr/bin/psql -U mydbusername mydb
screen -t irssi 3 /usr/bin/irssi

You can use the -c option when you start screen to specify a file other than $HOME/.screenrc. So I might write a bunch of different .screenrc config files and then I can choose what ever one I want. I can already imagine a .screenrc customized for doing python work, and another one customized for writing rants, and another one for doing sysadmin work.

A few other useful screen options:

  • screen -S sessionname will start a screen session and name it sessionname.
  • screen -ls will list all the screen sessions already running. Those session names are helpful in this case.
  • screen -r sessionname will attach a screen session that you specify.