After trying for hours (and also trying God and Bluepill) I decided to ask my question here because I am completely clueless how to solve this issue.
I have a Rails app. I want to use Thin as my app server. I want to use Monit to monitor my Thin instances. I use RVM to manage my Ruby versions as my local user.
I have the following monit file set up that would assumably do what I want it to do, but doesn't:
check process thin-81
with pidfile /Users/Michael/Desktop/myapp/tmp/pids/thin.81.pid
start program = "/Users/Michael/.rvm/gems/ruby-1.9.2-p180/bin/thin start -c /Users/Michael/Desktop/myapp -e production -p 81 -d -P tmp/pids/thin.81.pid"
stop program = "/Users/Michael/.rvm/gems/ruby-1.9.2-p180/bin/thin stop -c /Users/Michael/Desktop/myapp -P tmp/pids/thin.81.pid"
if totalmem is greater than 150.0 MB for 2 cycles then restart
If I simply copy/paste the start program in to the command line (outside of Monit) it works. Same goes for the stop program to afterwards stop the Thin instance. Running it via Monit however, does not seem to work.
Running it in -v verbose mode yields the following:
monit: pidfile '/Users/Michael/Desktop/myapp/tmp/pids/thin.81.pid' does not exist
Which leads me to believe that Thin never initializes. Does Monit run as root or something? Cause if it does then it obviously won't have the correct gems installed since I'm using RVM and not the "system" Ruby. I am currently on OSX (but will deploy to Linux eventually) - does anyone know what the cause of this might be? And if Monit is run via root, how could I make it use RVM regardless? Or could I tell Monit to execute the start/stop programs as Michael:staff (I assume it would be on OSX?)
Any help is much appreciated!
monit clears out the environment and also doesn't run a shell for your command (let alone an interactive one). I find I have to do something like:
/usr/bin/bash -c 'export rvm_path=/home/foo/.rvm; . $rvm_path/scripts/rvm; cd my_ruby_app_path; $rvm_path/bin/rvm rvmrc load; ./my_ruby_app'
as the monit start command.
another option which I found in the RVM google group is as follows:
start program = "/bin/su - myuser -c '/path/to/myscript.rb start' "
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.
We need the path for su, otherwise, monitrc would not able to find the su executable.
A better way would be to use an RVM wrapper to create a custom executable for thin. It will create the correct environment variables to use the right ruby and gems, and then launch thin. Read more about it using it with god here : https://rvm.io/integration/god/. It should work the same with monit
To create the wrapper:
rvm wrapper ruby#gemset bootup thin
Then change start program and stop program to use the executable you just created.
Related
I have a WSL Ubuntu distro that I've set up so that when I login 4 services start working, including a web API that I can test via Swagger to verify it is up and working.
I'm at the point where what I want to do now is start WSL via a script - that is, launch my distro, have all of the services start, and do it from Python. The problem is I cannot even figure out the correct syntax to get WSL to start from PowerShell in a manner where my services start.
Side note: "services" != systemctl (or similar) calls, but just executing bash CLI commands from either my .bashrc or .profile at login.
I've put the commands to execute in .profile & .bashrc. I've configured it both for root execution and non-root user execution. I've taken the commands out of those 2 files and put it into a script in the Windows file system that I pass in on the start of wsl. And I've put that shell script in the WSL file system as well. Nothing seems to work, and sometimes the distro starts and then stops after about 30 seconds.
Some of the PS CLI commands I've tried:
Start-Job -ScriptBlock{ wsl -d distro -u root }
Start-Job -ScriptBlock{ wsl -d distro -u root 'bash -i -l -c /root/bin/start.sh'
Start-Job -ScriptBlock{ wsl -d distro -u root 'bash -i -l -c .\start.sh'
wsl -d distro -u root -- bash -i -l -c /root/bin/start.sh
wsl -d distro -u root -- bash -i -l -c .\start.sh
wsl -d distro -u root -- /root/bin/start.sh
Permutations of the above that I've tried: replace root with my default login, and turning all of the Start-Job bash options into a comma-separated list of single-quoted strings (Ex: 'bash', '-i', '-l', ... ). Nothing I launch from the CLI will allow me access to the web API that is supposed to be hosted on my distro.
Any advice on what to try next?
Not necessarily an answer here as much as troubleshooting tips which will hopefully lead to an answer:
First, most of the forms that you are using seem to be correct. The only ones that absolutely shouldn't work are those that attempt to run the script from the Windows filesystem.
Make sure that you have a shebang line starting your script. I'm assuming you do, but other readers may come across this as well. For the moment, try this form:
#!/usr/bin/env -S bash -li
That's going to have the same effect as the bash -li you tried -- It will source both both interactive startup files such as ~/.bashrc as well as login profiles such as ~/.bash_profile (and /etc/profile.d/*, etc.).
Note that preferably, you won't need the -li. Best practice would be to move anything necessary for the services over from the startup scripts to your start.sh script, and avoid parsing the profile and rc. I need to go update some of my answers, since I just realized I've been guilty of giving some potentially bad advice ...
Specifically, though, I'm wondering if your interactive Bash config has something truly, well, "interactive" in it that might be preventing the automatic running of the script itself. Again, best practice would be for ~/.bashrc to only hold configuration that is needed for interactive shell sessions.
Make sure the script is set as executable (chmod +x start.sh). Again, I'm assuming this is the case for you.
With a shebang line and an executable script, use something like:
wsl -d distro -u root -e /root/bin/start.sh
The -e tells WSL to launch the script directly. Since it has a shebang line, it will be parsed by Bash. Most of the other forms you use above actually run Bash twice - Once when launching WSL and another when it finds the shebang line in the script.
Try some basic troubleshooting for your script like:
Add set -x to the top (right under the shebang line) to turn on script debugging.
Add a ps -efH at the end to show the processes that are running when the script completes
If needed, resort to quick-and-dirty echo statements to show where things have progressed in the script.
I'm hopeful that the above will at least show you the problem, but if not, add the debugging info that you gain from this to your question, and we can troubleshoot further.
I have written a macOS Cocoa app using XCode 9.2.
The purpose of the app is as a wrapper to a set of shell commands so that users can run commands easily as required. The shell script allow the users to control a particular device driver for which the software is written by another party.
I have managed to get the app to invoke the shell command as root.
But there are some sub-commands that fail. The actual commands run are, and I think it is the 2nd "stop -a" that fails:
do shell script \"
cd '/Library/Application Support/ABC' ;
python '/Library/Application Support/ABC/abc.py' stop -d;
python '/Library/Application Support/ABC/abc.py' stop -a;
python '/Library/Application Support/ABC/abc.py' stop -g;
python '/Library/Application Support/ABC/abc.py' stop -t;\"
with administrator privileges
When I run the same commands in Terminal they work, either as discrete commands or in a shell script.
As a last resort I ran the app from the command line using
sudo ~/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug/appname.app/Contents/MacOS/appname
And this works perfectly.
So, it seems that when I run using the NSAppleScript framework, which correctly prompts me for the root password, there is still something amiss which causes the command failure. But when the whole app runs under sudo everything works.
So the solution appears to be to set the app to require Root privs. Is there a setting that can be set for the built project that would automatically set this such that the root password is requested on startup?
Seems to be working in that I do not get the error, but would still like some pointers on how to set an app to run as admin.
I have some ruby processes, and for development I've been using foreman to manage the processes, now in production I want to export the processes and run it in /etc/init.d directory.
Is there any tool that can help with that, by creating the scripts and the related PID to /var/run ? I tried to use foreman export feature to do so, but it didn't work to do that, since it can do something for inittab or upstart but not init.d.
Any help would be highly appreciated
mm it seems no tool to create that , foreman can export inittabs, upstart but not init.d, the only way is to modify the file :
/etc/init.d/skeleton
You will need to slightly modify it, and then :
chmod +x /etc/init.d/process_name
sudo update-rc.d process_name defaults
sudo /etc/init.d/process_name (start| stop| reload )
Done . :)
Another Answer could be with using https://github.com/ghazel/daemons gem .
require 'daemons'
require 'process'
Daemons.run('process.rb')
Once the script is done, just call it from your command line:
ruby process.rb run|start|stop|restart
This config will generate a "process.pid" file under "/var/run" and you can use monit to watch over the process by using this file.
My ruby is in /usr/local/bin. whenever can't find it, and setting PATH at the top of my cron file doesn't work either, I think because whenever is running the command inside of a new bash instance.
# this does not work
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin
# Begin Whenever generated tasks for: foo
0 * * * * /bin/bash -l -c 'cd /srv/foo/releases/20110429110637 && script/rails runner -e production '\''ActiveRecord::SessionStore::Session.destroy_recent(15)'\'''
# End Whenever generated tasks for: foo
How can I tell whenever where my ruby binary is? Making a symbolic link from /usr/bin seems messy to me, but I guess that might be the only option.
This question offers env :PATH, "..." in schedule.rb as a solution, but (a) I can't find any documentation of that feature anywhere in the docs (b) it doesn't seem to have solved the asker's problem (unfortunately it takes non-trivial turnaround time for me to just try it).
update actually it is in the bottom of this page, i'll try it now.
more info
I can't modify the cron command because it's generated by whenever
i verified that if I make a new bash shell with bash -l, /usr/bin/env finds ruby just fine
I just tried the exact command in cron, starting with /bin/bash, from the command line of that user, and it worked.
so, this is very mysterious...
The solution is to put this in schedule.rb:
env :PATH, ENV['PATH']
Here's a little guide I put together on the topic.
rewrite your crontab as
0 * * * * { PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin ; export PATH ;/bin/bash -l -c 'cd /srv/foo/releases/20110429110637 && script/rails runner -e production '\''ActiveRecord::SessionStore::Session.destroy_recent(15)'\''' ; }
Or you should try to figure out why your BASH shell is not picking the PATH=... that is almost certainly in your .profile or .bash_profile.
I hope this helps.
As John Bachir pointed out, you can do it via env. But let me add more input. I am deploying on AWS Opsworks. Unfortunately they do not have a ruby manager (RVM, Rbenv, etc) installed by default.
The first thing I needed to do was SSH into the instance and figure out which ruby I was using. This was easy enough by executing the which ruby command in a terminal.
$ which ruby
/usr/local/bin/ruby
Cron was using ruby located at /usr/bin/ruby. This needed to be changed.
In schedule.rb, I have:
set :env_path, ''
env :PATH, #env_path if #env_path.present?
In local, env_path doesn't need to be set. For most users, the only thing to do is execute whenever as such:
bundle exec whenever --set 'environment=development' --update-crontab
On a staging / production environment, ruby may be installed elsewhere. So running this may be more appropriate:
bundle exec whenever --set 'environment=staging&env_path=/usr/bin/local' --update-crontab
You will need to replace /usr/bin/local with the output of echo $PATH.
In Opsworks, however, I needed to create a custom Chef recipe that looked like:
node[:deploy].each do |application, deploy|
execute 'whenever' do
user 'deploy'
group 'nginx'
cwd "#{deploy[:deploy_to]}/current"
command "bundle exec whenever --set 'environment=#{deploy[:environment_variables][:RAILS_ENV]}&env_path=#{ENV['PATH']}' --update-crontab"
end
end
I hope the information here is clear enough.
I'm currently using Capistrano to deploy my web application which works like a charm.
In my new project I must execute a command from sudo /bin/bash shell.
Is it possible for Capistrano to login to the machine as user X, run sudo /bin/bash,
enter the password and then execute a command in the sudo shell? If yes, could you
please provived me with an example.
With regards
jakob
Is there a specific reason you need to be in a root shell rather than executing the command with sudo? If executing a command with sudo, you can simply sudo 'command' instead of run 'command'.
I did a little experimentation to try to get a root shell with capistrano without logging into the server directly as root, and wasn't able to make much progress.
If running with sudo won't work, please update your question to let us know why and maybe we can help you find a workaround for it.
Update:
After playing around a little more, I found that you can execute an individual command (or string of commands) in a root shell by doing something like sudo '/bin/bash -c "whoami"'. It's getting an interactive root shell that's tricky.