Best practices question: Superuser/Postgresql?
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 pgto 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
2 Replies
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.