I tried to set cronjob on my server for ActiveCollab
I use this
*/5 * * * * php "/home/bbb/public_html/tasks/frequently.php" RnuFA > /dev/null
but it always returns error message :
Status: 301 Moved Permanently
Location: https://mywebsite.com/
Content-type: text/html
I've tried to execute the command through SSH and it worked properly.
Can someone help me telling what configuration on my server that need to be checked for this kind of issue?
Thank you
Official recommendation is to use cURL to trigger scheduled tasks, not executable PHP. Currently it is just a recommendation, but upcoming releases will stop shipping /tasks folder so you will have to use cURL.
There are many environments (more than we expected) where there is one PHP that web server uses to prepare the page, and another PHP that runs via command line interface (CLI). This causes all sort of problems, so we decided to use only way way of triggering tasks - via URL.
Bottom line - use cURL. Documentation is here:
https://activecollab.com/help/books/self-hosted-edition/scheduled-tasks-setup.html
Here are sample commands:
*/3 * * * * /usr/bin/curl -s -L "http://url/of/frequently?code=XyZty" > /dev/null
0 * * * * /usr/bin/curl -s -L "http://url/of/hourly?code=XyZty" > /dev/null
0 12 * * * /usr/bin/curl -s -L "http://url/of/daily?code=XyZty" > /dev/null
0 7 * * * /usr/bin/curl -s -L "http://url/of/paper?code=XyZty" > /dev/null
but make sure to check Administration > Scheduled Tasks page of your activeCollab for exact URLs that you need to trigger.
Related
At the moment scheduler tasks of EXT:direct_mail are failing. The cronjob gets the wrong URL.
http:///usr/www/users/myuser/myproject/current/typo3 which breaks setting up a draft mail with direct mail schedular.
["code"]=>
int(1436717322)
["message"]=>
string(96) "The parsedUri "http:///usr/www/users/myuser/myproject/current/typo3" appears to be malformed"
["file"]=>
string(90) "/usr/www/users/myuser/myproject/releases/48/Web/typo3/sysext/core/Classes/Http/Uri.php"
["line"]=>
Our cronjob:
* * * * * /usr/bin/php74 -d allow_url_fopen='on' -d allow_url_fopen='on /usr/www/users/myuser/myproject/current/typo3 scheduler:run > /dev/null 2>&1
The problem is partly because TYPO3 uses the HTTP_HOST variable to create absolute URLs. This is available by default when invoked via CLI. Then it can happen that the path on the server is used instead of the domain. It was finally solved by setting the cronjob like this:
* * * * * env HTTP_HOST=www.my-domain.com /usr/bin/php74 -d allow_url_fopen='on' /usr/home/username/public_html/myproject/current/typo3 scheduler:run > /dev/null 2>&1
This ensures that the HTTP_HOST variable is available.
I have written some PHP scripts that I am trying to run with cron jobs in VestaCP, but they don't seem to be running. I have tried to search for other threads on here and on the VestaCP forum that could help me identify the error, but have not found a solution.
Server system:
CentOs 7.4
Vesta 0.9.8-22
I have tested the PHP scripts by going to the links directly. They all work well. But the cron jobs are not running and I can't figure out why.
I have not been able to locate any error messages or logs generated by these cron jobs (even when I remove the "> /dev/null 2>&1"). But I might have been looking in the wrong places.
All of the cron jobs have been added through the VestaCP cron interface.
I have disabled exim, dovecot, clamd, and spamassassin. And I have turned off notifications in the cron panel. Not sure if that is related.
Copied from /var/spool/cron/admin [edited domain name]:
15 02 * * * sudo /usr/local/vesta/bin/v-update-sys-queue disk
10 00 * * * sudo /usr/local/vesta/bin/v-update-sys-queue traffic
30 03 * * * sudo /usr/local/vesta/bin/v-update-sys-queue webstats
*/5 * * * * sudo /usr/local/vesta/bin/v-update-sys-queue backup
10 05 * * * sudo /usr/local/vesta/bin/v-backup-users
20 00 * * * sudo /usr/local/vesta/bin/v-update-user-stats
*/5 * * * * sudo /usr/local/vesta/bin/v-update-sys-rrd
15 6 * * * sudo /usr/local/vesta/bin/v-update-sys-vesta-all
01 4 * * * sudo /usr/local/vesta/bin/v-update-letsencrypt-ssl
*/5 * * * * wget -q -O - "https://testing.example.com/cli/new-projects" > /dev/null 2>&1
*/5 * * * * wget -q -O - "https://example.com/cli/new-projects" > /dev/null 2>&1
30 10 * * * wget -q -O - "https://example.com/cli/project-expiration" > /dev/null 2>&1
*/5 * * * * sudo /usr/local/vesta/bin/v-update-sys-queue letsencrypt
0 10 * * * wget -q -O - "https://testing.example.com/cli/project-expiration" > /dev/null 2>&1
*/2 * * * * wget -q -O - "https://testing.example.com/cli/email-sender" > /dev/null 2>&1
*/2 * * * * wget -q -O - "https://example.com/cli/email-sender" > /dev/null 2>&1
I had the same problem in Ubuntu.
The problem was that the cron jobs created from VestaCP control panel is created for the user and although there is sudo at the beginning of the command, they are not run.
They seem to be called since I can see them on the /tmp/log/syslog file. It does not show any error though. But for some reason, the commands are not executed.
Here are few simple commands to check cron status.
Check if Cron service is running:
pgrep cron
if a number is returned the service is running else not
Check Cron status:
systemctl status cron
Check the current cron file:
crontab -l
Edit cronjob file:
crontab -e
One solution is to create the cron jobs for the root user from the terminal. I have not tried for other users. The cron jobs created for root user will run without a problem.
I need to setup simple cronejob to ping my website url every 2 minutes, what i did for now make no effect, can somebody help me write simple ping cronjob?
Here is what i have for now
2 * * * * /usr/bin/wget -O - -q -t 1 http://example.com/api/get.php?refresh=yes
This might help:
*/2 * * * * wget -q -O - "http://example.com/api/get.php?refresh=yes" >/dev/null 2>&1
Every 2 minutes (15 in the article), ping the specified file without
any output whatsoever. Just a silent ping to execute my script,
nothing more, nothing less.
Source: https://wp-mix.com/cron-notes-ping-external-url-with-no-output/
I need to create a new crontab job in a Redhat Linux environment. I have sudo access to that but I don't think I can do everything on that system--some higher level sys admins, for example, disable any firewall changes I make.
So here is my crontab command:
crontab e
and that brings up a screen like:
33 2 * * * /usr/bin/cu-firewall update > /dev/null 2>&1
30 1 * * * /root/update_atbi_website > /dev/null
0 4 * * * /home/prov356/scripts/opnforumbackup
I want to not send email and I have done it successfully in my local VM:
MAILTO=""
# execute 15 minute
*/15 * * * * perl /db_xenia/pl/get_usgs.pl
Question: If I were to append the above to the existing crontab info will it prevent sending of emails to the sys admin too? I don't want to get into trouble! Perhaps, I could append /dev/null after my Perl commands?
Thanks.
Never mind: Per #Basile's comment, I didn't need to be sudo. So I logged in as non-sudo and ran crontab -e; this time there were no sys admin entries. So I simply entered my own configs, saved, and the cronjob seems to be running fine.
Thanks.
Trying to add a new cronjob to my server using Plesk. I have two running already, but it's so long since I set them up that I can't remember why I did it the way I did. They work exactly as they should.
*/13* * * * &> /dev/null php -q httpdocs/forum/notifyreply.php
*/9 * * * * &> /dev/null php -q httpdocs/forum/notifytopic.php
However, when I add my new job using the same format, it doesn't seem to do anything. The script doesn't run and I get no e-mail notification to tell me that the script has run. The new job is as follows:
* * * * * &> /dev/null php -q httpdocs/crm/autoMessages/autoEmail.php
I'm running these on a Linux Virtual Server with Apache and using Plesk Control Panel. Hosting provider is 123-Reg.
Can anyone help?
Thanks!
UPDATE
So I've now removed the /dev/null line so I receive e-mail notifications and I'm getting the following error message:
/bin/sh: php: Permission denied
What I don't understand is why permission is being denied on this command but not on the other two...
Not sure what could have happened, but first thing I would do is to check if the permissions for the new php script are the same as what the old ones have. Do a ls -l on both httpdocs/forum/notifyreply.php and httpdocs/forum/notifytopic.php, and compare the permissions against what httpdocs/crm/autoMessages/autoEmail.php have.
You are not setting a User/Group for the cron command, better do it like this
* * * * * www-data www-data php -q httpdocs/crm/autoMessages/autoEmail.php > /dev/null 2>&1
(assuming that www-data is the correct User)
note that I put the error handling at the end.
Also, I think that you should use the full path; either you forgot to add a slash ( /httpdocs/.... ) , or do you have this script in the cron folder?