Whenever: bundle: command not found

Created on 2 Jul 2014  路  21Comments  路  Source: javan/whenever

env :PATH, ENV['PATH']
env :GEM_PATH, ENV['GEM_PATH']

I found a lot of issues solved environment problem like bundle: command not found using the solutions above.

I don't know why it works. Does it means that whenever do not load environment variable by default? env :FOO, ENV['FOO'] seems not smart, I wonder if such feature can be built in the gem?

Most helpful comment

Wow.

Just to make things clear, it is plain Ubuntu, I'm not using any ruby version manager and Ruby is installed from the packages.

Whenever includes bundler support in default configuration so it generates following crontab entry:

# Begin Whenever generated tasks for: project
0 0 * * * /bin/bash -l -c 'cd /home/user/project/releases/20141113151148 && RAILS_ENV=production bundle exec rake cron:task --silent'
# End Whenever generated tasks for: project

So far, it is just plain ubuntu, plain ruby, nothing but whenever executed inside bundler, ok?

And it does not work. Because cron is executed with PATH=/usr/bin:/bin and installed gems are in /usr/local/bin/. So it fails. bash --login is useless because the PATH stays the same.

Do you really want to claim, that this is not broken default behaviour?

To make it work you just have to change your crontab to include PATH or you have to set the env in whenever.

All 21 comments

+1, encountered this also. Would be great if the gem can load the $PATH by default.

Same thing here. Cron starts with PATH=/usr/bin:/bin and can't find the bundle.
This is default setting. So default whenever + default ubuntu does not work together.

This is rather critical.

To be clear, this is not an issue with Whenever. Whenever's job is to write crontab entries and it is succeeding in doing so. You would be running into the same class of issues had you crafted the entries by hand.

Yes. If I would write those faulty definitions by hand they would not work. Whenever generates not working entries.

That entirely depends on _your_ environment. Not everyone is using a Ruby version manager or Bundler, but even most who do don't have this issue. The fact that your machine is configured in such a way that it can't find Bundler is certainly not an issue with Whenever.

Wow.

Just to make things clear, it is plain Ubuntu, I'm not using any ruby version manager and Ruby is installed from the packages.

Whenever includes bundler support in default configuration so it generates following crontab entry:

# Begin Whenever generated tasks for: project
0 0 * * * /bin/bash -l -c 'cd /home/user/project/releases/20141113151148 && RAILS_ENV=production bundle exec rake cron:task --silent'
# End Whenever generated tasks for: project

So far, it is just plain ubuntu, plain ruby, nothing but whenever executed inside bundler, ok?

And it does not work. Because cron is executed with PATH=/usr/bin:/bin and installed gems are in /usr/local/bin/. So it fails. bash --login is useless because the PATH stays the same.

Do you really want to claim, that this is not broken default behaviour?

To make it work you just have to change your crontab to include PATH or you have to set the env in whenever.

The --login option is used so your user's environment is loaded automatically without needing to define a PATH in your crontab.

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

Is your PATH set in one of those files?

Ubuntu sets the path in /etc/environment. By default it is not set anywhere in user profile.

I just tried on fresh ubuntu image and running bash --login -c env produces the same path as without login.

Ok, so your original problem is that when the cron jobs run, /usr/local/bin/ is not in your PATH so bundle isn't found, right? In what file is /usr/local/bin/ added to your PATH?

It is OS default set in /etc/environment. Nothing is added or changed.

It is annoying that cron is ignoring this OS default, but I guess there is not chance that it will change as it is like this probably for last 20 years.

You can easily reproduce it by setting the PATH in your shell.

I think the best option is to check the path of bundle when generating the job template and generate the entry with absolute path to bundle.

How about adding /usr/local/bin/ to your PATH in .bash_profile?

That can cause a whole lot of different issues, like stop loading .profile. Why I would need to change my user environment, which works perfectly by default?

I totally understand that whenever can't cover every possible environment configuration. But covering default case where gems are installed in /usr/local/bin and cron has just /usr/bin:/bin is worth.

Whenever checks if the project is using Gemfile so it also can check where is the bundler.
Or prefixing the current PATH to the generated commands for reproducibility.

Another way would be to change the current bundler detection. It just checks for 'Gemfile'.
If it would check for ENV variable BUNDLE_BIN_PATH it could actually use that to execute bundler later.

Forget about PATH settings in cron files. Setting the PATH does not work.

Set the path to bundle explicitly in your config/schedule.rb

set :bundle_command, "/usr/local/bin/bundle"

Try adding env :PATH, ENV['PATH'] to the top of your schedule.rb file.

@kostyakch working fine thank

@mikz I've run into this exact situation, and I'm agreeing that it's not directly the fault of Whenever. If nothing else, the documentation _should_ be improved to point this scenario out, as it does lead one down to a bit of a rabbit hole.

Thanks! @kostyakch

If U want,I think U can edit crontab directly with crontab -e.
See the $PATH ,$GEM_PATH with echo $PATH,echo $GEM_PATH.

thanks @kostyakch work fine for me too =D

Was this page helpful?
0 / 5 - 0 ratings