Forum OpenACS Q&A: wrong PATH for postgres following installation doc -PLS HLP

I'm installing oacs.4.6.3 following the docs at

At point 3 (Set up postgres's environment variables); I follow the direction but when checking env I get:
postgres@yasha:~$ env

Am I doing something wrong?
Thank for any help.

Found the solution.

for a reason or another .bashrc wasn't run when login.

I had the same problem on Debian.
I modified .bash_profile rather than .bashrc and seems to work better. If I modifiy .bashrc and I log out and then back in as user postgres, .bashrc doesn't seem to be called in for some reason, but .bash_profile does. All this is happening in Debian Woody.
.bashrc is used by non-login shells.  Your .bash_profile (login shell setup) must explicitly source .bashrc.

Something like this at the top of .bash_profile help, usually:

# source .bashrc if one exists
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

We should put this in the install docs.
Actually, current doc is ok -- .bashrc will be sourced by bash automatically when nsd runs as user nsadmin (but not as a login shell).

The ambuguity comes from the fact that with the changes applied to .bashrc only, and no sourcing of it in .bash_profile, yet checking the environment when logging in as nsadmin (running bash as login shell) -- changes don't get reflected.

Adding that single line to .bash_profile never hurts, and we should probably add that to the docs -- with or without it when nsd is started things will suddenly just work.

Another thing to add to docs could be a reference to bash(1) man page, as well as references to any other useful manual pages.

All the environment changes could also be made in nsd-postgres or nsd-oracle shell scripts (if they are still included in docs, not sure about it), as long as they are exported.

Posted by Andrew Piskorski on
Putting some of those environment variables in the postgres's users login scripts is just plain wrong anyway. As I've mentioned before, these are system-wide settings that you probably want be default in some system-wide place. See my Oracle install notes - the issue should be the same for PostgreSQL.

What you really want is a file called /etc/ or something like that. It should be something like this:

# $Id:,v 1.2 2002/12/24 07:03:13 atp Exp $
# Single central place for setting all PostgreSQL environment variables.
# Source this from /etc/profile.
#, 2002/12/06 14:03 EST

# For Debian PostgreSQL package:

## For locally installed from source PostgreSQL:

. /etc/postgresql/postgresql.env

Then do this in an appropriate spot in your system-wide /etc/profile:

for script in  /etc/  /etc/
  if [ -e "$script" ]
    . "$script"

Posted by Malte Sussdorff on
Amen to that. For the record, SuSE uses /etc/profile.d/ for storing these kind of files and it is fairly usefull (as all files get sourced at system start AFAIK). Who is going to add this to the documentation ?


Isn't it only _wrong_ until you have two versions of postgresql running? I liked your suggestion when you made it a while ago for Oracle install, but then I immediately installed two different copies of pg.

It seems that if you want to get technical about things, environment variables should be set per process, whenever a process is started up, or restarted.

How about this -- core environment should be setup in user's non-login shell, especially if this is a daemon-like user (as the case of postgres -- it owns a service).

However, each instance of a service (e.g. eache separate postmaster process or aolserver proces -- whatever) should include 'tweaking' of environment as and when required.

For example, you may want to run 2 Pg's, listening on different ports (could be set as a env. variable and used in postmaster.conf), using different PG_DATA.  Yet they both may be the same Pg version, hence use the same libe (PG_LIB) and binaries (PG_BIN or whatever), ahve access to the same system binaries (PATH), etc.

Tom, no, it is not. I haven't had to do that myself yet, but I've thought about it. For two PostgreSQL installs - or two Oracle isntances, it's the same situation - you want essentially two versions of that script, one for each instance (or pass in a parameter to the script saying which instance you want, whatever).

Clients using one instance or another source the appropriate script. Your only decision to make, is if one instance should be the default - if so, source that instance's from /etc/profile, and not the other. If you don't want any default instance, then source neither script from /etc/profile - now in order to use the database, each client must take a explicit action. But that action is just sourcing the script. This is way I said to put the settings into, not directly into /etc/profile.

Having two instances changes nothing important - these are still system-wide settings that should be in a system-wide place. What you want to avoid is having the exact same settings hard-coded into lots of different places - put each in one place only, whenever feasible.

Posted by Andrew Piskorski on
Oh, Red Hat seems to have /etc/profile.d/ as well, I didn't know about that. Debian does not though. Ah, it is used via a little loop at the end of /etc/profile:
for i in /etc/profile.d/*.sh ; do
    if [ -r "$i" ]; then
        . $i
unset i
So that's good, there's no magic going on behind the scenes, it is just good old /etc/profile doing the work. Very simple.

(I guess nobody in the Linux world worries about /bin/sh vs. /bin/bash differences anymore, since most Linux distributions use bash for everything. That "; then" syntax won't work in sh, like you sometimes find on Solaris...)

Thanks Andrew, I knew you had a good, I mean very good, explanation!