Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a script that runs at startup from rc.local in CentOS. This script contains a command to compile my erlang project using a third party build command called rebar. The rebar line fails to compile my project at startup, but if I then run it manually, the project compiles fine. I assume this is because the rebar command calls other commands without absolute paths.

How can I run a command at startup, but in a context that does not require absolute paths?

I don't want to have to patch this third party command (and deal with the inevitable bureaucracy that attends that mess) and/or keep my own parallel fork of the project just to maintain this one extra feature.

I'm also curious why I can't Google this. It seems like it must come up so often that people wish to use a command in rc.local which itself does not use all absolute path command calls. Moreover, I feel like the answer should be trivial, since I can login immediately after startup and run any command I like, as root, which is the user that rc.local runs as too! Isn't there a hook where you can run a script in the context of "yes, we really are booted up all the way now, let's run this script as a fully peer user on the system without any arbitrary limitations"?

This is not the first time I've run into this problem and I'd love to understand what's going on.


(I'm not going to wait 8 hours to answer my own question, so...)

Well, it looks like setting PATH works. I think I had got the impression that commands in rc.local and its children just aren't searched for in PATH, even after calling a bash script, but that's wrong. (@TiZon gave me a good clue.) The reason I got this impression is because every Google result told the questioner to use absolute paths in command calls, even though this is cumbersome for anything beyond trivial scripts or scripts that depend on third party commands that don't follow this rule. Instead, the answer is to call out to bash script with a proper shebang line, find out what your normal environment's PATH is by echoing it during a regular session, and then set the PATH in your startup bash script to the regular one.

Hopefully this answer will float up in Google and help some other poor lost souls.

share|improve this question
up vote 1 down vote accepted

Try putting /bin/bash in front of your command. You can't use relative paths because there is no environment to keep track of them. If you run everything in a bash-shell, bash will keep track of these things for you. Same goes for crontab

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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