>>>>> On Sat, 8 Sep 2007 15:17:17 -0500, Kelly, Brian said: > > Martin, > > Thanks for the advice. I have an additional file in my /etc/env.d directory > that contains the PYTHONPATH. I've run env-update and source /etc/profile. > My profile.env, ld.so.conf and ld.so.cache files are up to date. > > I am not using su when checking the env variables. > > I changed my jobdef to run my test script before and after a job. The > difference being that I added the line "source /etc/profile" to the before > job. Sure enough the environment variables are set as I would expect. When > the post job runs, which does not contain the "source /etc/profile", it > reverts back to a different set of env variables. > > So at this point I am still unsure exactly how the bash environment is > initialized when Bacula calls my bash script? I guess, my linux inexperience > is showing through.
Ah, that explains it. Bash doesn't load any init files when running a non-interactive shell script, so you will either have to set up the environment in each script or set it in the script that starts Bacula (so it is inherited by the before/after job scripts). __Martin > > *********************************************************** > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Sat Sep 8 14:26:50 CDT 2007 > > MANPATH=/usr/local/share/man:/usr/share/man:/usr/share/binutils-data/x86_64- > pc-linux-gnu/2.16.1/man: > /usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man > HOSTNAME=baculad0 > SHELL=/bin/bash > TERM=screen > DEFAULTLEVEL=default > USER=root > PAGER=/usr/bin/less > CONFIG_PROTECT_MASK=/etc/terminfo /etc/revdep-rebuild > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/ > usr/x86_64-pc-linux-gnu/ > gcc-bin/4.1.2 > PWD=/ > EDITOR=/bin/nano > BOOTLEVEL=boot > CONSOLETYPE=pty > SVCNAME=bacula > HOME=/root > SHLVL=2 > PYTHONPATH=/usr/lib64/portage/pym:/prod/bacula/local/lib64/python2.4/site-pa > ckages:/prod/bacula/loca > l/lib/python2.4/site-packages > LESS=-R -M --shift 5 > GCC_SPECS= > CVS_RSH=ssh > LESSOPEN=|lesspipe.sh %s > INFOPATH=/usr/share/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.1 > /info:/usr/share/gcc-dat > a/x86_64-pc-linux-gnu/4.1.2/info > SOFTLEVEL=default > _=/bin/env > root > *********************************************************** > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Sat Sep 8 14:27:22 CDT 2007 > > SHELL=/bin/bash > TERM=screen > DEFAULTLEVEL=default > USER=root > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/sbin:/usr/loca > l/bin:/usr/sbin:/usr/bin > :/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2 > PWD=/ > BOOTLEVEL=boot > CONSOLETYPE=pty > SVCNAME=bacula > HOME=/root > SHLVL=2 > SOFTLEVEL=default > _=/bin/env > root > *********************************************************** > > -----Original Message----- > From: Martin Simmons [mailto:[EMAIL PROTECTED] > Sent: Friday, September 07, 2007 4:43 PM > To: Kelly, Brian > Cc: bacula-users@lists.sourceforge.net > Subject: Re: [Bacula-users] Bacula environment > >>>>> On Thu, 6 Sep 2007 20:53:17 -0500, Kelly, Brian said: > > > > I am running a post job python script that fails because python is > > unable to import some libraries. I am running bacula as root. When > > running the script manually as root there are no problems. Issuing the > > env command as root yields a correct PYTHONPATH variable: > > > > PYTHONPATH=/usr/lib64/portage/pym:/prod/bacula/local/lib64/python2.4/s > > ite-pa ckages:/prod/bacula/local/lib/python2.4/site-packages > > > > I wrote a small test script to determine what the environment > > variables look like when the director fires off a script as follows: > > > > #!/bin/bash > > echo "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" >> > > /prod/bacula/var/bacula-environment > > echo "" >> /prod/bacula/var/bacula-environment > > date >> /prod/bacula/var/bacula-environment > > echo "" >> /prod/bacula/var/bacula-environment > > /bin/env >> /prod/bacula/var/bacula-environment > > whoami >> /prod/bacula/var/bacula-environment > > echo "***********************************************************" >> > > /prod/bacula/var/bacula-environment > > > > This yields the following output: > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > Thu Sep 6 18:30:54 CDT 2007 > > > > SHELL=/bin/bash > > TERM=xterm > > DEFAULTLEVEL=default > > USER=root > > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/sbin:/us > > r/loca > > l/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/ > > gcc-bi > > n/4.1.2 > > PWD=/ > > BOOTLEVEL=boot > > CONSOLETYPE=pty > > SVCNAME=bacula > > HOME=/root > > SHLVL=2 > > SOFTLEVEL=default > > _=/bin/env > > root > > *********************************************************** > > > > Can anyone help me to understand why the the PYTHONPATH environment > > variable is missing when the director fires off my simple shell > > script? I'm not sure if I am doing something incorrectly within Bacula > > or if I've somehow configured my Linux distro incorrectly. > > > > Thanks in advance for any advice with this problem. If you need more > > information please let me know. > > > > Brian Kelly > > Where do you get PYTHONPATH normally? I can think of two possibilities: > > 1. You set it in your own non-root shell init files. Since Bacula runs the > script as root, it doesn't read your init files. When you tested env as > root, maybe you did this by ``su'' or ``su root'', which would cause your > environment to be inherited by the root shell. > > 2. Root sets PYTHONPATH in an init file that is not loaded by bash when > running a shell script, e.g. .bash_login. > > __Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
