10-14-2005, 04:54 AM
I'm trying to write a lottery program for a game and I've just got stuck.
I've got the players buying tickets ok but only problem is having the script know when it is. I'd like to have the script call a function every week at one or more specific dates (like Saturday at 7pm and/or Wednseday at 7pm) so a winning ticket can be chosen and the money handed out automatically.
Errr... use cron? Don't reinvent the wheel.
10-14-2005, 10:36 PM
Yep, cron job is the way to go: http://mkaz.com/ref/unix_cron.html
That's UNIX cron. Hosts nowadays are more likely to use vixie-cron. Here's my manpage (from vixie-cron-4.1-36.FC4):
cron - daemon to execute scheduled commands (ISC Cron V4.1)
cron [-l load_avg] [-n] [-p]
Cron should be started from /etc/rc or /etc/rc.local. It will return immediately, so you don’t
need to start it with ’&’. The -n option changes this default behavior causing it to run in
the foreground. This can be useful when starting it out of init.
Cron searches /var/spool/cron for crontab files which are named after accounts in /etc/passwd;
crontabs found are loaded into memory. Cron also searches for /etc/crontab and the files in
the /etc/cron.d directory, which are in a different format (see crontab(5)). Cron then wakes
up every minute, examining all stored crontabs, checking each command to see if it should be
run in the current minute. When executing commands, any output is mailed to the owner of the
crontab (or to the user named in the MAILTO environment variable in the crontab, if such
Additionally, cron checks each minute to see if its spool directory’s modtime (or the modtime
on /etc/crontab) has changed, and if it has, cron will then examine the modtime on all crontabs
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 when-
ever it changes a crontab.
Daylight Saving Time and other time changes
Local time changes of less than three hours, such as those caused by the start or end of Day-
light Saving Time, are handled specially. This only applies to jobs that run at a specific
time and jobs that are run with a granularity greater than one hour. Jobs that run more fre-
quently are scheduled normally.
If time has moved forward, those jobs that would have run in the interval that has been skipped
will be run immediately. Conversely, if time has moved backward, care is taken to avoid run-
ning jobs twice.
Time changes of more than 3 hours are considered to be corrections to the clock or timezone,
and the new time is used immediately.
PAM Access Control
On Red Hat systems, crond now supports access control with PAM - see pam(8). A PAM configura-
tion file for crond is installed in /etc/pam.d/crond . crond loads the PAM environment from
the pam_env module, but these can be overriden by settings in the crontab file.
On receipt of a SIGHUP, the cron daemon will close and reopen its log file. This is useful in
scripts which rotate and age log files. Naturally this is not relevant if cron was built to
In this version of cron , without the -p option, /etc/crontab must not be writable by any user
other than root, no crontab files may be links, or linked to by any other file, and no crontab
files may be executable, or be writable by any user other than their owner.
crontab(1), crontab(5), pam(8)
Paul Vixie <email@example.com>
crontab - maintain crontab files for individual users (ISC Cron V4.1)
crontab [-u user] file
crontab [-u user] [-l | -r | -e][-i]
Crontab is the program used to install, deinstall or list the tables used to drive the cron(8)
daemon in ISC Cron. Each user can have their own crontab, and though these are files in /var,
they are not intended to be edited directly.
If the cron.allow file exists, then you must be listed therein in order to be allowed to use
this command. If the cron.allow file does not exist but the cron.deny file does exist, then
you must not be listed in the cron.deny file in order to use this command. If neither of these
files exists, only the super user will be allowed to use this command.
If the -u option is given, it specifies the name of the user whose crontab is to be tweaked.
If this option is not given, crontab examines "your" crontab, i.e., the crontab of the person
executing the command. Note that su(8) can confuse crontab and that if you are running inside
of su(8) you should always use the -u option for safety’s sake.
The first form of this command is used to install a new crontab from some named file or stan-
dard input if the pseudo-filename ‘‘-’’ is given.
The -l option causes the current crontab to be displayed on standard output.
The -r option causes the current crontab to be removed.
The -e option is used to edit the current crontab using the editor specified by the VISUAL or
EDITOR environment variables. After you exit from the editor, the modified crontab will be
The -i option modifies the -r option to prompt the user for a ’y/Y’ response before actually
removing the crontab.
The crontab command conforms to IEEE Std1003.2-1992 (‘‘POSIX’’). This new command syntax dif-
fers from previous versions of Vixie Cron, as well as from the classic SVR3 syntax.
A fairly informative usage message appears if you run it with a bad command line.
Paul Vixie <firstname.lastname@example.org>
Powered by vBulletin® Version 4.2.1 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.