[rvm] Best practice for monit + rvm?

[Chad Woolley]

The following trick works to get around the minimal cron environment

* * * * * myuser bash --login -c 'cd /path/to/myapp && ruby
./script/myscript.rb'

Unfortunately, this same trick doesn't work for monit:

start program = "/bin/bash --login -c '/path/to/myscript.rb start'"
as uid myuser and gid myuser

We also haven't been able to make it work with a wrapper script, or by
sourcing /home/myuser/.profile before running the script. Probably
missing something obvious, but not sure what.

Any tips from people who are successfully running scripts with rvm and
monit are welcome...

Thanks,
-- Chad

--
Please visit http://rvm.beginrescueend.com/ for documentation on rvm.
Please visit https://www.pivotaltracker.com/projects/26822 to see what is being worked on currently.

You received this message because you are subscribed to the Google
Groups "rvm (Ruby Version Manager)" group.
To post to this group, send email to rubyversi...@googlegroups.com
To unsubscribe from this group, send email to
rubyversionmana...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyversionmanager?hl=en

[Wayne E. Seguin]

The thing to remember about monit is that it *completely* clears the
environment on you. For example if you did 'env >> env.log' in the
monit scripts you'll likely see almost nothing in the env.

Can you provide the wrapper script you were using ?

[Greg]

What about calling the rubies directly in the script?

(ie /home/blarg/.rvm/rubies/ruby-1.9.2-head/bin/ruby )

[Wayne E. Seguin]

On Wed, May 5, 2010 at 12:49 PM, Greg <gr...@nokes.name> wrote:
> What about calling the rubies directly in the script?
>
> (ie /home/blarg/.rvm/rubies/ruby-1.9.2-head/bin/ruby )

This will work fine as long as your script does not require any
environment to be setup. Additionally it cannot require any gems as
the proper GEM_HOME env variable will not be set either.

~Wayne

[Chad Woolley]

On Wed, May 5, 2010 at 9:38 AM, Chad Woolley <thewoo...@gmail.com> wrote:
> Unfortunately, this same trick doesn't work for monit:
>
>  start program = "/bin/bash --login -c '/path/to/myscript.rb start'"
> as uid myuser and gid myuser

OK, we figured this out.

The problem is that monit does not set the $HOME environment variable.
So, when bash runs, it parses ~/.bash_profile , which runs rvm. RVM
then ends up setting $rvm_path to '/.rvm' (not '/home/myuser/.rvm' as
it should be). After that point, even if you re-parse .bash_profile
or .bashrc, RVM won't reset $rvm_path because it is already set.

We got around this by adding this in front of the RVM line in
.bash_profile and .bashrc: "export HOME=/home/myuser; if [[ ..."

So, it seems like this is something that RVM should handle. Maybe by
our including our hack as part of the RVM post-setup init-script-hack
instructions, or maybe by just raising a descriptive error if $HOME is
not set so people using monit can find the error easier than we did.
In any case, it doesn't seem right that RVM goes ahead and sets
$rvm_path to a bogus value if $HOME is not set.

[Wayne E. Seguin]

Another thing you could do along the same vein as /bin/bash --login...

Is, instead of doing 'as uid .. and gid..' , is to:

start program = "su - myuser -c '/path/to/myscript.rb start' "


~Wayne

[Chad Woolley]

On Wed, May 5, 2010 at 7:12 PM, Wayne E. Seguin <waynee...@gmail.com> wrote:
> Another thing you could do along the same vein as /bin/bash --login...
>
> Is, instead of doing 'as uid .. and gid..' , is to:
>
> start program = "su - myuser -c '/path/to/myscript.rb start' "

Ok. Don't have time to test it now, but I think this would have the
same problem with missing $HOME via monit, because su just invokes
bash anyway.

[Wayne E. Seguin]

'su - user' is actually a different construct than 'bash -l' with
'bash -l' you do inherit environment / user settings from the parent
whereas with 'su - user' it actually performs the task logged in as
the specified user so I believe that $HOME should be set in that case.

~Wayne

[Rick DeNatale]

On Thu, May 6, 2010 at 12:50 AM, Chad Woolley <thewoo...@gmail.com> wrote:
> On Wed, May 5, 2010 at 7:12 PM, Wayne E. Seguin <waynee...@gmail.com> wrote:
>> Another thing you could do along the same vein as /bin/bash --login...
>>
>> Is, instead of doing 'as uid .. and gid..' , is to:
>>
>> start program = "su - myuser -c '/path/to/myscript.rb start' "
>
> Ok.  Don't have time to test it now, but I think this would have the
> same problem with missing $HOME via monit, because su just invokes
> bash anyway.

That - after su is important, it causes su to simulate a login by the
named user.


--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

[Rick DeNatale]

On Thu, May 6, 2010 at 8:32 AM, Wayne E. Seguin <waynee...@gmail.com> wrote:
> 'su - user' is actually a different construct than 'bash -l' with
> 'bash -l' you do inherit environment / user settings from the parent
> whereas with 'su - user' it actually performs the task logged in as
> the specified user so I believe that $HOME should be set in that case.

and su - user runs the user's shell as a login shell, so if the
user's shell is bash, it will cause ~/.bash_profile to be run so the
environment variables should be the same as just after that user
logged in.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

[Chad Woolley]

On Wed, May 5, 2010 at 7:12 PM, Wayne E. Seguin <waynee...@gmail.com> wrote:
> Another thing you could do along the same vein as /bin/bash --login...
>
> Is, instead of doing 'as uid .. and gid..' , is to:
>
> start program = "su - myuser -c '/path/to/myscript.rb start' "

To confirm and close this thread, the above works perfectly.