Need to set up rvm environment prior to every cron job - rvm

I installed and configured RVM roughly following the pattern outlined in the first part of this set of instructions: http://blog.ninjahideout.com/posts/a-guide-to-a-nginx-passenger-and-rvm-server
Basically, this means there is no pre-build system ruby (all ruby installs are RVM-managed) and RVM is installed system-wide instead of attached to a particular user (files at /usr/local/rvm) so all users in the rvm group can access the same rubies with the same installed gems.
One issue with setting up the system this way is that the rvm environment must be set up in a shell session before ruby can be used. For all rvm users, I put this in their .bashrc: source "/usr/local/rvm/scripts/rvm". This works fine for ssh sessions.
The problem comes in play for cron jobs, which don't execute .bashrc. The rvm script above (/usr/local/rvm/scripts/rvm) is considerably more complicated than setting up a few environment variables, so I'd actually like to run this command prior to every job in the file.
Sure, I could do that manually, like so:
1 2 * * * source "/usr/local/rvm/scripts/rvm"; /do/some/cron/job/1
3 4 * * * source "/usr/local/rvm/scripts/rvm"; /do/some/cron/job/2
5 6 * * * source "/usr/local/rvm/scripts/rvm"; /do/some/cron/job/3
7 8 * * * source "/usr/local/rvm/scripts/rvm"; /do/some/cron/job/4
But I'd prefer to do something like this:
[execute] source "/usr/local/rvm/scripts/rvm"
1 2 * * * /do/some/cron/job/1
3 4 * * * /do/some/cron/job/2
5 6 * * * /do/some/cron/job/3
7 8 * * * /do/some/cron/job/4
Obviously, the above syntax doesn't work. But, is there some way to get this to work? The cron man pages and documentation were not of much help here. But is there some trick or standard way to achieve this?
If it matters, I'm running Ubuntu 10.10 (Maverick Meerkat).

Just do rvm cron setup
This lets rvm setup ruby cron settings. As a result the crontab gets populated with environment variable assignments.
Then crontab -e
Add your cron tasks (below the assignments), save and close and you are good to go!!

You don't need to write wrappers (following that logic, you might as well write a wrapper to the wrapper). Please keep things simple. All you need to do is configure your cron job to launch a bash shell, and make that bash shell load your environment.
The shebang line in your script should not refer directly to a ruby executable, but to rvm's ruby:
#!/usr/bin/env ruby
This instructs the script to load the environment and run ruby as we would on the command line with rvm loaded.
On many UNIX derived systems, crontabs can have a configuration section before the actual lines that define the jobs to be run. If this is the case, you would then specify:
SHELL=/path/to/bash
This will ensure that the cron job will be spawned from bash. Still, your environment is missing, so to instruct bash to load your environment, you will want to add to the configuration section the following:
BASH_ENV=/path/to/environment (typically .bash_profile or .bashrc)
HOME is automatically derived from the /etc/passwd line of the crontab owner, but you can override it.
HOME=/path/to/home
After this, a cron job might look like this:
15 14 1 * * $HOME/rvm_script.rb
What if your crontab doesn't support the configuration section? Well, you will have to give all the environment directives in one line, with the job itself. For example,
15 14 1 * * export BASH_ENV=/path/to/environment && /full/path/to/bash -c '/full/path/to/rvm_script.rb'
Full blog post on the subject

Crontab files generally only allow two types of things (plus comments and blank lines if you want to be pedantic):
Environment variable setting.
Command specifications.
And some crontabs don't even support setting environment variables (although I doubt you'll come across such a thing practice).
If you need to do more than set some environment variables then you're going to need to put your source "/usr/local/rvm/scripts/rvm" either in the cron specs as you have in your question or you'll need to wrap your cron jobs in a cron runner something like this:
#!/bin/sh
source "/usr/local/rvm/scripts/rvm"
exec $1
And then in the crontab:
1 2 * * * /path/rvm_cron_runner /do/some/cron/job/1
Six of one, half a dozen of the other.

If your cronjob is a straight ruby file, the docs say you can just use the built-in wrapper which will load up the correct ruby version and gemset:
1 0 * * * /usr/local/rvm/bin/ruby-1.9.2-p290#projectX /path/to/script.rb
You would still need to add this call to each line however.

Related

CRON job not setting up on linux

I have setup the corn command using crontab -e command.
MAILTO=""
* * * * * /usr/bin/php7.2 /var/www/vhosts/hostname/httpdocs/bin/magento cron:run --group="test"
I have created module to run CRON job automatically. But it is not working automatically.
Instead when I hit command php bin/magento cron:run it works.
I am surprised cron task is performing manually but not automatically.
My bad. It is working fine now.
The actual issue was with the user setting up the CRON job. I was setting the CRON job with root user. Later I set up the same CRON using developer user having ftp access and it worked perfectly.

Running a crontab job from locally stored script

Having trouble running a crontab psql backup job from a locally stored script. I added the job via crontab -e and when I used crontab -l, it shows up in the list of jobs. The script that it is supposed to run works fine, checked that, runs as it should and dumps the output on the designated s3 bucket when using ./backup.sh
This is what I set the job as:
59 23 * * 7 /Users/myusername/backup.sh
The job should run at 11:59PM every Sunday, but it doesn't. I can't figure out what the issue is (do I need to leave line breaks/spaces in between each job, or just after the very lost job in my crontab list?
Any help would be very much appreciated. Thanks.
Depending on your distribution, you might want to check logs for Cron service.
Non-exhaustive list of possible problem reasons:
Cron service is not running at all and hence is not starting any of the tasks;
Usually Cron passes your script a very limited set of environment variables, so your script might fail because of some missing environment. That will probably be reflected in cron daemon logs
What can you do
Cron service: if your distro uses systemd then try running systemctl status cron (or systemctl status crond?) to check if it is running.
Your script is started but fails: here are several things to try.
Try checking cron service logs, maybe with something like journalctl --unit cron or journalctl -f before the script should be started;
Check if there is a dead.letter file in your home directory containing output of the failed script. When Cron starts your script and the script outputs something (which is considered a problem), that output is mailed to you. If mailing is not properly configured then it usually goes to that file.
Put something like this in the beginning of your script:
(
date
id -a
set
echo
) >> /tmp/myscript.log
Then wait until cron runs your script and check if the file /tmp/myscript.log was created. Then try to run your script manually, replicating all the environment created by cron which you now know. I.e. unset all but the variables Cron leaves, and make sure id is correct.

Delete or reset Gitlab CI builds

Is it possible to delete old builds in Gitlab CI?
I tested a few things and have now about 20 builds that are useless (most are failed anyway).
It also shows stages that I don't have anymore which kinda clutters the Pipelines page and some of the uploaded artifacts are a bit big.
I wasn't able to find any documentation on this, only that disabling CI in the settings doesn't remove the builds.
Using Gitlab 8.10 Community (hosted by Gitlab.com)
There is currently no option in the GUI to completely get rid of a build other than expunge related data from the build. (The erase option in the build)
If you would have a local installation you could modify the database directly but I would advise caution. (I'll put the guide here for completeness sake)
Login to the GitLab database. If you use the default PostgreSQL :
sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
Check if there is a table ci_builds. For pSQL: \dt
Delete the builds with normal SQL. For example: DELETE FROM ci_builds WHERE id = 2
(Optional) If you want to cleanup a list of commits which triggered a build you need to midify the table ci_commits.

Is there a better way than this to run an SQL script through puppet?

Take a look at Get puppet build to fail when the contained SQL script fails execution
I was attempting to run a vagrant build which installs Oracle XE in an Ubuntu Virtualbox VM and then runs a an SQL script to initialize the Oracle Schema. The vagrant build is here : https://github.com/ajorpheus/vagrant-ubuntu-oracle-xe. The setup.sql is run as a part of the oracle module's init.pp (right at the bottom or search for 'oracle-script').
When running the SQL script as a part of the vagrant build, I see the following error:
notice: /Stage[main]/Oracle::Xe/Exec[oracle-script]/returns: Error 6 initializing SQL*Plus
notice: /Stage[main]/Oracle::Xe/Exec[oracle-script]/returns: SP2-0667: Message file sp1<lang>.msb not found
notice: /Stage[main]/Oracle::Xe/Exec[oracle-script]/returns: SP2-0750: You may need to set ORACLE_HOME to your Oracle software directory
There were two things that were instrumental in me finding a workaround for the problem:
As suggested in this answer, setting the logoutput attribute to true for the exec block under question immediately showed me the error, whereas before the exec was just failing silently.
It seemed strange that I was able to run the command (sqlplus system/manager#xe < /tmp/setup.sql) after manually logging in as the 'vagrant' user. That suggested that there was something missing in the environment. Therefore, I copied all ORACLE env. vars into the exec as seen on Line 211 here
That worked, however, setting up the env vars manually seems a bit brittle. Is there a better way to setup the ORACLE environment for the vagrant user? Or, is there a way to get puppet to setup the environment for the vagrant user similar to an interactive shell?
If some profile has been set up to give the user a working interactive shell, you should be able to pass your action through such a shell
command => 'bash -i -c "<actual command>"'
As an aside about logoutput, since you mentioned that - the documentation advises that "on_failure" is a sane default, as it will only bloat your output when there are actual errors to analyze. It is the actual default in the latests versions of Puppet.

Writing a crontab job that references a properties file

I am running Ubuntu Server 12.04. I am trying to set up a cron job to run every week. If I were to write this command in the command prompt, it would look like this:
name#computer:~/./runReport.sh weekly_ecc_name.properties
It works when run at command like the above
Now this is what I have for the cron job:
* * * * * /runReport.sh weekly_ecc_name.properties > errors.txt 2>&1
I'm having it run every minute until I get it working.
The error that it spits out is Error: Could not find or load main class blarg (which refers to the file that reads the properties file).
I am not quite sure how to write this so that it works. Thanks for your help.