I have set up cron jobs for my SugarCRM as requested by Sugar:
But when we look at last runs it does not seem to work or show anything.
I am using this for email reminders, mail check and also scheduled campaign run.
Is command-line php on your system installed and the executable in whatever PATH that cronjob is using?
If not make sure to specify the full path, e.g. /usr/bin/php or /usr/local/bin/php are common.
Also based on your operating system/distribution the php command line executable may have a different name, e.g. php5.
Make sure to use the web-process user's crontab or execute php with sudo -u webprocessusername, so that the cronjob will be executed with the correct permissions.Running the cronjob as different user or even root is usually not a good idea.
To see potential error messages replace > /dev/null e.g. with > /tmp/sugarcron.log or > /path/to/webfolder/sugarcron.txt and check the file after a minute.
Further info on the SugarCRM Knowledge Base:
Introduction to Cron Jobs
Troubleshooting Cron and Schedulers
Related
I have installed this extension to assist me in my cron jobs omnilight/yii2-scheduling. The extension has good documentation that is why I settled on it amidst all the other cron-jobs extensions available for yii2. However, I am stack at some place that I need assistance. There is a place where I am asked to put a single line of code on the crontab:
* * * * * php /path/to/yii yii schedule/run --scheduleFile=#console/config/schedule.php 1>> /dev/null 2>&1
However, I am not sure where to place it, i.e. where is the crontab in yii2? anyone who has used this extension and is able to get it running to assist me here.
Maybe a little later but you must put that in the crontab, a cron is :
cron is a Unix, solaris, Linux utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon
and the crontab is where are stored all this crons. To edit this file you must use in terminal:
crontab -e
Put that line here. Save and you are ready to go.
I have a gentoo Linux system and a strange behavior of crontab. As root user, and as I understand the documentation, the command
crontab -l
lists all crontab jobs defined for the current user, root (There are no cronjobs defined for any other used). All listed cronjobs are also defined in the file /etc/cronjob.
However, there are two more crontab files located in /etc/cron.d, which define a cronjob each:
/etc/cron.d/testcron1
/etc/cron.d/testcron2
Although not listed with crontab -l, the cronjob defined in the file /etc/cron.d/testcron1 is executed. The other cronjob defined in the file /etc/cron.d/testcron2 is NOT executed.
This all does not make sense, so I have two questions:
Why does crontab -l list not all cronjobs?
Must the cronjobs in /etc/cron.d be registered somewhere, or is a restart of a daemon/service required? Why is the one started, and not the other one (the executable works fine, though).
The command crontab is used to maintain/manage crontab files for individual users. These files are usually located in /var/spool/cron/crontabs.
If crontab -l dose not show any cron jobs then this user currently has no individual cron jobs. This dose not mean that there are no cron jobs in /etc/cron* taht will run with the privileges of this user. crontab will not operate on the files in /etc/cron*. It is a tool for only managing individual (per user) cron jobs held in /var/spool/cron/crontabs.
Now lets see how the different cron jobs get executed.
Form the manpage of the cron daemon we can read:
cron searches its spool area (/var/spool/cron/crontabs) for crontab files (which are named after accounts in /etc/passwd); ...
cron also reads /etc/crontab, which is in a slightly different format (see crontab(5)).
as well as:
Additionally, in Debian, cron reads the files in the /etc/cron.d directory. cron treats the files in /etc/cron.d as in the same way as the /etc/crontab file...
(I think this applies to gentoo as well...)
About restarting we can read:
cron then wakes up every minute, examining all stored crontabs, checking each command to see if it should be run in the current minute...
Additionally, cron checks each minute to see if its spool directory's modtime (or the modtime on the /etc/crontab file) has changed, and if it has, cron will then examine the modtime on all crontabs files and reload those which have changed. Thus cron need not be restarted whenever a crontab file is modified. Note
that the crontab(1) command updates the modtime of the spool directory whenever it changes a crontab.
So the crontab command is for user specific corn jobs while the files in /etc/cron* are more for system cron jobs.
No manual triggering is needed to activate a new cron job.
I'm trying to add a cron job on my server, that is hosting here http://partisscan.bugs3.com/.
The provider for that is serversfree http://www.serversfree.com.
It is realy good but i can't make a cron job. I want my php file http://partisscan.bugs3.com/scan.php to be started every minute(maybe latter less often but for start). So i added a cron job in a cron job manager under control panel but it's not working.
my cron job is:
1 * * * * php -f /home/u798416153/scan.php
However it's not working:S
any ideas?
There are many possible reasons for not working.
Regarding the file:
Executing permissions of the file.
Owner of the file.
Regarding the crontab:
To which user does this crontab correspond the line you posted?
Does it have to be executed by root or any other user? If it is not root, you have to make sure that the user is not in /etc/cron.d/deny.
I am really new to Linux and I apologize if this is rudimentary, but I have Google'd to find examples with no clarity and I am confused. (the question relates to a server running CentOs 6)
My questions are:
I am not sure what is the default directory that I should store a .sh file in so that a cron job can run it.
Is the syntax and sequence of my code in .sh file below correct?.
I have tested the TSQL and its fine.
#! SQL="DELETE FROM messages WHERE date < DATE_SUB(CURDATE(), INTERVAL 7 DAY)"
MYSQL_USER="root"
MYSQL_PASS="xxxxxx"
MYSQL_DB="mydb"
I understand that the cron should contain this to do it on a daily basis:
0 0 * * *
But I am just having some apprehension of how to put it all together so I don't screw things up. A full example or explanation or a reference link would be greatly appreciated.
I believe that cron will execute the script from whichever directory it is in, given that:
the file has execution permission for the user that cron runs as (usually root if job is configured in the system-wide crontab)
the cron line specifies the full path to the script
So, if your script is /opt/script.sh, specifying this in cron:
0 0 * * * /opt/script.sh
will execute script.sh each day in 12:00am.
Please note that if this is the system-wide crontab (/etc/crontab) it should also include a username as which to execute the command:
0 0 * * * username /opt/script.sh
Also, something to make sure when working with cron is to either use full paths when calling external commands from the script or to set up the PATH variable (either in the script itself or on the crontab file). This is needed because usually the environment in which cron jobs are run is pretty restricted.
Another thing to have in mind is that if any output is generated by a cron job this output is sent via mail to the user executing the cron. So to have some feedback from the script you have to either set up the system so that the mail message ends up in a mailbox which is read by a human being or the script sends all of it's output to a log file or syslog.
I have this executable that queries a remote server for a command, executes it on the local machine and returns the stdout (and also possibly stderr) from it back to the server.
This executable runs just fine if called from the command line (as root), but I found it's failing for some commands when executed automatically by the cron job.
What are the differences in terms of environment (users, stdin, stdout, etc.) I should expect when scheduling this executable to run periodically using crontab?
Thanks!
The most important difference is that files like .bashrc etc. are not executed before cron jobs, so a lot of environment variables that you normaly have in the command line will be missing. So if your program doesn't work in the cron job, embedd it in a script that sets all the necessary environment variables.
Regarding input and output, there is obviously no user interaction for cron jobs, so the programs should not expect input (if they do, provide it from an input file or directly in the script), and any output should be redirected into a log file.
This executable runs just fine if called from the command line (as root), but I found it's failing for some commands when executed automatically by the cron job.
In cron jobs you can specify what user to run the script as, for example:
0 0 * * * www-data /usr/bin/php /var/www/foo/do_work.php
I am specifying to run 'do_work.php' as www-data everyday... This file would be located in /etc/cron.d/
Also, you should probably check the UID that cron uses for running the tasks, especially if it's a 'global' /etc/crontab job, not a user-level one. Could be that some permissions are lacking if the job is running from 'nobody' or 'cron'.
Mainly
Current working directory - you cannot guarantee what this is going to be from cron. It may be $HOME, but don't count on it
Environment variables - most that you have setup for normal logins will NOT be set, so things which require environment variables to have specific values may fail. This notably includes $PATH.
stdin / stdout / stderr will not be a tty, so some programs will behave differently because of this (stdout and err will probably be a temp file; stdin will probably be null)
But essentially you can't rely on much
User ID, group id and supplementary groups should be set as per a normal login for the owner of the cron job