Hi, I am trying to be a good new sysadmin and follow best practices but I am getting pretty frustrated.

I made a new account on my Linode so that I don't have to login as root every time. However, this has begun to give me a series of headaches while trying to implement a Postgresql database server so I can experiment with building and deploying Clojure applications.

When I type in the command `initdb pg`to initialize my database, it can't find initdb. So I add /usr/lib/postgresql/9.1/bin to my $PATH and `initdb` works, no problem.

BUT: When I go to activate the server via `postgres -D pg &`, it dies on a fatal error message related to denied write permissions. Okay, still no big deal- I'll just use `sudo` in front of that command.

But when I `sudo` (I'm running Ubuntu 10.10 Oneiric btw), the $PATH variable is changed (a security feature to prevent accidentally running trojans as root). Previously I've used `sudo -i` to circumvent this and use the normal $PATH variable.

But my system is giving me all kind of weirdness of this step: For example, this time around when I try to run `sudo -i postgres -D pg &` my system simply returns a "postgres: command not found" message (even though sometimes it echoes `[1] 7895` like a process/job was started up?

Last time I tried this, it would seem to be working okay until I typed anything (even just a carraige return) into the terminal, in which case I would get a message indicicating that the exit of the postgres process.

What the heck is going on here and how can I get this running smoothly? Am I barking up the wrong tree with all this `sudo -i` business, or is there a better way to approach this?

Thanks for your time,

Nathan

Don't know if I would call this a "best practice," but 90% of the time when I need to do things as root my first step is sudo su -. This runs a login shell as root, with the environment ($PATH, etc.) set up accordingly. This does lose traceability, since any commands you run in the new shell will not be logged by sudo.

When you run a job in the background (what & does), the shell prints the job number and PID. When the job exits, the shell waits until the next time it is asked to display a prompt, then it will precede the prompt display with the job number, exit status (if >0), and command line of the exiting process. The fact that it does not immediately notify you that the job exited is normal behavior.

Just wanted to add that set -b will cause bash (and other POSIX-conforming shells) to asynchronously notify you of job completion rather than waiting until the next prompt is to be printed.