Hey, I have this problem, that scripts started at boot time from rc.local don't have environment variables (defined at /etc/profile.d/*) set at the time of their startup. What should I do ?

"su - lisak -c /opt/atlassian-jira-enterprise-4.1.1-standalone/bin/startup.sh"

"su - lisak -c /opt/aaa2/at-22/bin/startup.sh"


The scripts at /etc/profile.d/* are executed in their own shells rather than sourced so the environment variables they set are not available anyway.What variables do you need? Can you make use of /etc/environment? Can you write the variables into a file in a var=value format from the appropriate scripts and source that file in your rc.local scripts?

This is from the Bash man page. You may find it helpful.

When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following com‐ mand were executed: if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi but the value of the PATH variable is not used to search for the file name.

The Bourne shell similarly uses the ENV variable.

  • I don't want to do such workarounds, if I do this often I wouldn't do anything but administration :-) – lisak Jun 13 '10 at 17:36
  • /etc/profile and /etc/profile.d/* are accessed for each login shell...and I'm starting the script by su, which doesn't start a login shell I suppose... – lisak Jun 13 '10 at 17:45
  • I meant that you should add code that automates the creation of the variable-holding file. Anyway, I was think about this backwards. rc.local is run at boot time, but the files in profile.d are executed at user login time. You're trying to mix two different worlds - system boot and user login. – Paused until further notice. Jun 13 '10 at 20:01
  • I know that the proper way of doing it would be via /etc/bashrc which is loaded for each interactive shell start. .. btw those $BASH_ENV or $ENV are not visible to users, are they....root doesn't see them...is it something under the hood ? – lisak Jun 14 '10 at 0:54
  • Those variables aren't set by default. You set them, for example, in a script that calls another or on the command line of a call to a script. BASH_ENV=foo /path/to/bar (on one line, this sets the variable for the environment of "bar"). – Paused until further notice. Jun 14 '10 at 1:41

Quote from the su manpage (Slackware 13.1):

       -, -l, --login
       Provide an environment similar to what the user would expect had
       the user logged in directly.

       When - is used, it must be specified as the last su option. The
       other forms (-l and --login) do not have this restriction.

In your example, you don't specify - as the last su option. Try doing that or using an alternate argument.

  • you are maybe right, but I can't figure out how it would look like... su - lisak -c /opt/aaa2/at-22/bin/startup.sh is the only order of arguments that is actually possible – lisak Jun 13 '10 at 17:32
  • Btw where do you get this manpage from, the mine doesn't mention anything you pasted – lisak Jun 13 '10 at 17:35
  • I just typed man su in Slackware 13.1 – halp Jun 14 '10 at 13:21

I think the best solution is to source /etc/profile.d/*.sh or run /etc/profile from rc.local cause I don't want to duplicate configuration for boot time scripts and scripts started from login shell...

NOTE: I don't know what might be the consequences of running /etc/profile from rc.local ...so the best way would be sourcing them at rc.local from /etc/profile.d/*.sh

AKA: for file in /etc/profile.d/*; do source $file; done

ALTERNATIVE: echo ". /etc/profile" >> $HOME/.bashrc - for single user

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.