# Debugging with pstree

DevFeed: [Debugging with pstree](<https://devfeed.tech/articles/debugging-with-pstree-29445.md>)

Original publisher: [Read original article](<http://akaptur.github.com/blog/2014/09/21/debugging-with-pstree/>)

Published: 2014-09-22T00:46:00Z

Content type: tutorial

Language: en

Sources: [Allison Kaptur](<https://devfeed.tech/sources/allison-kaptur.md>)

Topics: [debugging](<https://devfeed.tech/topics/debugging.md>), [Bash](<https://devfeed.tech/topics/bash.md>), [Ruby](<https://devfeed.tech/topics/ruby.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>)

Tags: [bash](<https://devfeed.tech/tags/bash.md>), [command](<https://devfeed.tech/tags/command.md>), [database](<https://devfeed.tech/tags/database.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [terminal](<https://devfeed.tech/tags/terminal.md>)

## AI overview

A debugging account about a local PostgreSQL database restore failure after an outdated psql version and a PATH change. The article investigates why Ruby rake tasks could not find pg_restore and identifies that they were running under sh rather than bash.

## Source excerpt

I hit a very fun bug yesterday while trying to run a script that sends emails to certain subsets of Hacker Schoolers. When I tried to test the script locally, I discovered that one of the tables of the database, Batch, was missing from my local version. After briefly panicking and making sure that the actual site was still up, I could dig in. It turns out that my local version of psql was way out of date, and as of a few days ago we'd started using a data type that wasn't present in my old version. Because of that, creating that particular table failed when I pulled from the production database the night before. The failure was logged, but the output is so verbose that I didn't notice the problem. Both the diagnosis and the fix here were easy - I went back and read the logs, googled the data type that was raising an error, and then upgraded Postgres.app and psql. That's when the real trouble started. The new version of Postgres.app was placed in a new spot on the $PATH, as you'd expect, and the upgrade prompted me to change my .bashrc, which I did. But the rake tasks we use to manage local copies of the database errored out with this message: 1 2 $ pg_restore --verbose --clean --no-acl --no-owner -h localhost -U `whoami` -d hackerschool latest.dump sh: pg_restore: command not found This was pretty clearly a $PATH problem. I tried the usual things first, like sourcing my .bashrc in the terminal I was using, closing the terminal and opening a new one, etc. None of that worked. One thing that jumped out to me was the sh in the error message. That was an indicator that rake wasn't using bash as a shell - it was using sh - which means my .bashrc wasn't setting the environment. Reading the rake task showed that it was a thin wrapper around lots of system calls via Ruby's system("cmd here"). I added the line system("echo $PATH") and verified that the new location of pg_restore wasn't in it. At this point I found I had lots of questions about the execution context of the ra