Using Joonla 3.7 I used to get a warning about the cron job not running because my provider does not allow me to run cron jobs.
I could run the cronjob manually by clicking on the warning message and all was fine to me.
After updating Joomla to 3.8.3 I cannot find the link to run the cron manually.
Can you please tell me if and how this can be done in the control-panel?
Related
I've got problem with heroku pg:backups capture --app myapp command.
Heroku CLI submits usage information back to Heroku. If you would like to disable this, set `skip_analytics: true` in /home/ubuntu/.heroku/config.json
heroku-cli: Updating to 4.99.0-e5f5ef4... done
heroku-cli: Updating CLI...heroku-cli: Updating to 5.11.8-f58f4fa... done
Starting backup of postgresql-spherical-5948... done
Use Ctrl-C at any time to stop monitoring progress; the backup will continue running.
Use heroku pg:backups:info to check progress.
Stop a running backup with heroku pg:backups:cancel.
Backing up DATABASE to b598... pending
Backing up DATABASE to b598... !
▸ MODULE_NOT_FOUND: Cannot find module 'bytes'
Does anybody have similar problem? This command is launched with deploy on CircleCI.
I started running into the same problem yesterday and was finally able to come up with a solution that is working for me.
For starters, it looks like bytes is a dependency of heroku-pg, which is the part of Heroku CLI that is being used for the backups command. It seems like the dependency is not being included or installed with the version of heroku-cli that is being used to run the backup command.
I tried CircleCI’s “Rebuild with SSH” to troubleshoot the issue, and encountered similar error messages when attempting the backup command there. While trying to reinstall heroku-cli using npm, I found that the npm and node versions were way behind what heroku-cli wanted, so maybe that is part of the problem? Anyway, reinstalling with npm only produced an even more broken Heroku CLI.
Finally I checked the build environment and it was set to Ubuntu 12.04 (Precise) which probably explains the way out of date npm/node packages. I changed it to Ubuntu 14.04 (Trusty) and pushed a new commit to CircleCI (A rebuild alone is not sufficient to change OS versions) and was able to successfully run the backup command that had been failing!
Solution: Set CircleCI build environment to Ubuntu 14.04
I have installed MAMP and have my php scripts that execute a shell script and Rscript on my mac. Now, If I need to run the same on linux cluster, how do I proceed?
I have a html page that helps me choose some options and run the shell script.
I would need the same html page but the shell script to run on a linux cluster instead of my mac. Any help would be appreciated as I am really struck.
I'm trying to set up CI on my local machine running on Mac. To do so I use Xubuntu virtual machine, Jenkins, and some simple selenium tests. tests on github
I get fresh install of Xubuntu, where I install Jenkins using official manual.
In Jenkins I installed some plugins(git, ruby, rake, rbenv).
In job config I use rbenv wrapper(2.1.0) with ignorance of os versions, also I use this gemlist:
bundler,rake,rspec,selenium-webdriver,capybara
and running that job with
rspec spec
And when I run this job I recieve something like that for every test:
Selenium::WebDriver::Error::WebDriverError:
unable to obtain stable firefox connection in 60 seconds (127.0.0.1:7055)
full output is here
it looks like jenkins user have no access to display to run/see firefox.
Anyone know how to make it work?
We ran into this at work recently and actually opted for Capybara and set the driver to poltergeist. This seemed better than trying to figure out how to run FF on our VM's.
That said, we were able to get a small test suite running by following the instructions here
Answer was not so simple as I think.
The problem is that jenkins service has no access to displays (when it installed via native package). Thats why when I try to start Firefox it's throw me a error. try:
$ sudo su - jenkins && firefox
So it's need access to display to start browser successfully.
This is how I done it:
first of all I used answer form here where I changed to my local user.
Then I installed xvfb plugin to Jenkins, and in my build job preset display to '0' - which is my actual user display. with that option all my tests would run 'headless' but on actual display.
This could be not the best way to solve my problem, but it definitely works for me.
I'm trying to setup a cron job on Openshift due to import emails in a Redmine application. Therefore, I prepared a minutely script like this:
#!/bin/bash
rake RAILS_ENV=production -f ${OPENSHIFT_REPO_DIR}/Rakefile redmine:email:receive_imap host=imap.googlemail.com port=993 ssl=1 username=xxx#artistii.com password=yyy ...
It runs without problems when launched by hand on a ssh connection. When run by cron, instead, rake could not be found.
Making some debugging, I found that the path is not the same as the login shell; and even if I used a full path for rake, ruby that is found is version 1.8 (not 1.9 as per the cartridge), and whenever I set the very same path as the shell, then libruby-1.9 is not found.
Following some other advice I tried to add the following line in place of setting a custom PATH:
source /usr/bin/rhcsh
but nevertheless rake is still not found. I also tries to use bundle exec.
What is the right way to set an environment for cron on Openshift so that it can run like a login shell?
You may need to cd to the directory where your bundle is installed first (where your Gemfile is) something like this maybe?
cd $OPENSHIFT_REPO_DIR && bundle exec rake .....
This is a bug in the cron cartridge. You can refer to this question in SO. It is actually a question with the Python cartridge and the cron cartridge. But it is the cron cartridge which will affect all. There is also a OpenShift Bug Report mentioned within.
The bug is as you have observed, the cron cartridge uses Ruby 1.8 instead of Ruby 1.9. Thus, the gems installed with Ruby 1.9 are not available to the cron cartridge using Ruby 1.8.
There is already a bugfix for this bug, you can refer to the OpenShift Bug Report. But not too sure if it is pushed out already.
Meanwhile, there is a temporary workaround, by exporting the PATH and LD_LIBRARY_PATH in the cron script. You can refer to the OpenShift Bug Report.
Hope this helps.
If you are using rvm, openshift may getting some problem to shift to default rvm.You can also try something like this so it will set rvm to default before running bundle and can also generate your cron log as well to get the exact status of your cron job:
https://rvm.io/rvm/install
use bundle exec to get rid from more than one version of rake
cd $OPENSHIFT_REPO_DIR && rvm gemset use "yourgemsetname" && RAILS_ENV=production bundle exec rake cron_job:cron_job --silent >> log/cron_log
I'm trying to setup an automated "build" server for my rails projects using Hudson CI. SO far it's able to run specs and do metrics on the code but I have 2 different projects dependent on 2 different versions of ruby. So i'm trying to use RVM to run multiple copies of ruby then switch back and forth in a pre-build step.
I found a couple posts like this one that try and explain how to make this work, but I'm not running a startup script for hudson, it starts on boot which is how it worked out of the box when i installed it via the debian instructions.
The problem seems to be that even though hudson runs under the "hudson" account and that account has rvm installed (and working) when it tries to run a shell based prebuild step to call rvm switch 1.8.7 it fails with the error "rvm: command not found"
Not sure what I'm doing wrong. Hudson is using SH as its shell but i also tried using bash. no luck.
Has anyone gotten this working before in this setup?
edit the "/etc/init.d/hudson" (!) and change the line:
SU=/bin/su
... change to:
SU="/bin/su -"
... and add rvm setup in the /home/hudson/.profile
I had the same symptoms as you.
After a couple of hours of headbanging, check your $HOME environment variable for Hudson (viewable at http://yourserver/hudson/systemInfo).
Under Ubuntu, the Tomcat 6 start script doesn't set $HOME. Somehow, Hudson inherited my $HOME instead!
I added HOME=$CATALINA_HOME to the /etc/init.d/tomcat6 script just under the rest of the ENV declarations, and now it all works. Very annoying issue, to be sure.