Solved Service (rc.d) Requiring bash

I have a running Redmine instance in a jail (which is based on Ruby, argh). The instance depends on rbenv, as I needed to decouple the dependencies for Redmine from system packages.

Things work fine in rc.local, but I wanted to do them in a proper way, and write a custom rc.d script. For reference this is the working command:

Code:
cd /srv/redmine && PATH=/usr/local/bin:$PATH /root/.rbenv/shims/bundle exec rails server webrick -d -b 192.168.7.2 -e production

I just started to write the script, so it is still WIP. However, at the current stage I have issues with getting rbenv to find bash. I tried to add /usr/local/bin to PATH from within the script, but this does not work. Whenever I try to start it, I get the message env: bash: No such file or directory (resulting from the shebang in the rbenv script).

When I run the rc.d script with sh -x it works fine.

Right now I just symlinked bash to /usr/bin/bash which is a viable workaround, but I realize it is not the proper way to do things.

Any ideas how I could let rbenv find bash in /usr/local/bin from the rc.d script?
 
The devel/rbenv port should have a so-called "shebang fix" that fixes issues like this. That will automatically translate any #!/bin/bash to something appropriate on FreeBSD.

 
It could be that /root/.rbenv/shims/bundle is setting its own PATH effectively making your PATH settings useless. I don't know what "bundle" is but are you able to run PATH=/usr/local/bin:$PATH /root/.rbenv/shims/bundle echo $PATH command ? Or alike version (including exec) that would test that.
 
as I needed to decouple the dependencies for Redmine from system packages.
Can't you simply run bundle install in the Redmine directory? That would install the gems in a bundle directory inside the RoR application, keeping it completely separate from the system's Ruby gems. That's how we deploy our RoR applications. The applications are typically run via www/rubygem-passenger, we don't use Webrick.
 
bundle looks like a small wrapper script around rbenv:

Bash:
#!/usr/bin/env bash
set -e
[ -n "$RBENV_DEBUG" ] && set -x

program="${0##*/}"
if [ "$program" = "ruby" ]; then
  for arg; do
    case "$arg" in
    -e* | -- ) break ;;
    */* )
      if [ -f "$arg" ]; then
        export RBENV_DIR="${arg%/*}"
        break
      fi
      ;;
    esac
  done
fi

export RBENV_ROOT="/root/.rbenv"
exec "/usr/local/bin/rbenv" exec "$program" "$@"

I echoed PATH inside the script and it does not look like it would be modified (kind of obvious after reading the script). I tried to change the shebang (just for debugging purposes) to the real path to bash, and also modified the shebang in the rbenv script, but unfortunately this did not solve my issue.

I must be missing something, and I do not know how to debug from here as execution with sh -x is working fine.
 
Can't you simply run bundle install in the Redmine directory? That would install the gems in a bundle directory inside the RoR application, keeping it completely separate from the system's Ruby gems. That's how we deploy our RoR applications. The applications are typically run via www/rubygem-passenger, we don't use Webrick.
This might be the way to go in the end, if I cannot fix my current issue. Thanks for the input.
 
bundle looks like a small wrapper script around rbenv:
Ok, then the same I mentioned _could apply to rbenv. In other words somewhere along the execution your PATH gets dropped and hence not finding bash in, for it, non standard /usr/local/bin directory.
 
Ok, then the same I mentioned _could apply to rbenv. In other words somewhere along the execution your PATH gets dropped and hence not finding bash in, for it, non standard /usr/local/bin directory.
Thanks for the hint, I did just a quick grep and rbenv indeed shuffles around with the path which then leads to side-effects where the wrong binaries / scripts are picked up. It looks like there is nothing I can do about it.

So I basically improved the service by writing its own rc.d script, just to degrade the setup by creating a symlink in a system location. Not sure if this is an improvement, but I certainly learned many new things along the way :D

I want to keep the setup minimal, and I still have some house-keeping to do, because the jail does not connect to the outside world (just to the host), which did not really bother me, but I am not sure if I want to configure ports inside the jail as it is fairly minimal right now and I like it that way.

I will mark the thread as solved as the root cause was identified, even if I still do not have a nice solution.
 
Back
Top