|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|at.deny/cron.deny||nohup command||Enterprise Job schedulers||Cron Tips|
The idea of the at command is to facilitate "one time command scheduling". In this sense it is complementary to cron which usually is used to schedule periodic jobs. You to start to start a long job and then log off the system you can also use nohup. In Solaris and AIX nohup permits converting already running process to "nohup status" which is really nice. We will be taking about unix command, but at command also exists in Windows (with a different syntax).
At the same time at is quite different from cron: at command preserves the environment in which it was invoked, while cron does not (it executes command in its own "cron" environment, and you should not expect that PATH and other valuables are preserved from the account under which cron is running).
You can compile crontab into sequence of at command and use at exclusively. If you consolidate all crontabs on one server and compilation at the end of each scheduling day via ssh on target servers for the next day you actually will have a more flexible environment, somewhat similar to expensive Enterprise Job schedulers.TIPS:
at -f myjob now exit
at is a special version of cron and like cron it is controlled by two files that list users one per line similar to cron.allow and cron.deny and control the behavior of the command:
Some sysadmin hardlink those two files to cron files to avoid synchronization problem.
|You can hardlink at.allow to cron.allow and at.deny to cron.deny to avoid synchronization problem.|
The at command is part of the set of four commands that includes at, batch, atq, and atrm commands:
Syntax of Linux Gnu implementation is as follows:
at [-V] [-q queue] [-f file] [-mldbv] TIMEOptions:
at -c job [job...]
The most important ability of at command is the its ability to operate in relative time terms. There are several important relative time frames used:
The optional increment after time specification in at command permit to specify offset from the time. It should be a number preceded by a plus sign (+) with one of the following suffixes:
The spacing is quite flexible as long as there are no ambiguities. For example:
at 0815am Jan 24 at 8 :15amjan24 at now "+ 1day" at 5 pm FRIday at '17 utc+30minutes'
The singular forms are also accepted, for example
at now + 1 minute
The keyword next can be used as an equivalent to an increment + 1. For example the following two commands are equivalent:
at 2pm + 1 week at 2pm next week
The last two are equivalent commands.
One can also use at for periodic but dynamic rescheduling of jobs. In such case at can be specified inside the job with new, dynamic interval.
Simplified (and actually wrong as if interval is fixed crontab is a more appropriate vehicle for such work) example, can be something like a script named my.daily which we force to run every day by invoking at inside the script itself:
# my.daily # runs every day at now tomorrow < my.daily
... ... ...For large intervals (say more then an hour) this is a better implementation then using sleep inside the script as it release resources after execution
/usr/xpg4/bin/at [-c| -k| -s] [-m] [-f file] [-p project] [-q queuename] -t time
/usr/xpg4/bin/at [-c| -k| -s] [-m] [-f file] [-p project] [-q queuename] timespec…
/usr/xpg4/bin/at -l [-p project] [-q queuename] [at_job_id...]
/usr/xpg4/bin/at -r at_job_id. ..
/usr/xpg4/bin/batch [-p project]
Two "twins" at and batch are very similar with batch being alias to at with supplied "now" time of execution.
Commands of the forms:
/usr/bin/batch [-p project] /usr/xpg4/bin/batch [-p project]
are respectively equivalent to:
/usr/bin/at -q b [-p project] now /usr/xpg4/bin/at -q b -m [-p project] now
At the same time at is quite different animal than cron: "at" preserves the environment in which it was invoked, while cron does not (it executes command in its own "cron" environment, and you should not expect that PATH and other valuables will be preserved).
The at utility is pipable: it can reads commands from standard input and submit a job to be executed immediately (like in example below) or at a later time.
echo "perl myjob" | at now
The at-job is executed in a separate invocation of the shell, running in a separate process group with no controlling terminal, except that the environment variables, current working directory, file creation mask (see umask(1)), and system resource limits (for sh and ksh only, see ulimit(1)) in effect when the at utility is executed is retained and used when the at-job is executed.
When the at-job is submitted, the at_job_id and scheduled time are written to standard error. The at_job_id is an identifier that is a string consisting solely of alphanumeric characters and the period character. The at_job_id is assigned by the system when the job is scheduled such that it uniquely identifies a particular job.
User notification and the processing of the job's standard output and standard error are described under the -m option.
Like with cron two files that list users one per line and are similar to cron control files control the behavior of the command:
If that file does not exist, the file /usr/lib/cron/at.deny is
checked to determine if the user should be denied access to at.
! bad user (webservd) Fri Apr 21 14:47:49 2006
That can also happen with human accounts if password aging was turned on.
Apparently if the password expires cron jobs do not run.
The batch utility reads commands to be executed one after another and is equivalent to at now. The difference is that the queue used is a special at queue, that exists specifically for batch jobs. Execution of submitted jobs can be delayed by limits on the number of jobs allowed to run concurrently. See queuedefs(4).
If the -c, -k, or -s options are not specified, the SHELL environment variable by default determines which shell to use.
For /usr/xpg4/bin/at and /usr/xpg4/bin/batch, if SHELL is unset or NULL, /usr/xpg4/bin/sh is used.
For usr/bin/at and /usr/bin/batch, if SHELL is unset or NULL, /bin/sh is used.
The following options are supported:
If -m is not used, the job's standard output
and standard error is provided to the user by means of mail, unless they are
redirected elsewhere; if there is no such output to provide, the user is not
notified of the job's completion.
The following operands are supported:
In the "C" locale, the following describes the three parts of the time specification string. All of the values from the LC_TIME categories in the "C" locale are recognized in a case-insensitive manner.
If no date is given, today is assumed if the given
time is greater than the current time, and tomorrow is assumed
if it is less. If the given month is less than the current month (and no
year is given), next year is assumed.
at 2pm + 1 week at 2pm next week
The format of the at command line shown here is guaranteed only for the "C" locale. Other locales are not supported for midnight, noon, now, mon, abmon, day, abday, today, tomorrow, minutes, hours, days, weeks, months, years, and next.
Since the commands run in a separate shell invocation, running in a separate process group with no controlling terminal, open file descriptors, traps and priority inherited from the invoking environment are lost.
$ at -m 0730 tomorrow sort < file >outfile <EOT>
$ at now + 1 hour <<! diff file1 file2 2>&1 >outfile | mailx mygroup !
This sequence can be used at a terminal:
$ batch sort <file >outfile <EOT>Example 6 Redirecting Output
This sequence, which demonstrates redirecting standard error to a pipe, is useful in a command procedure (the sequence of output redirection specifications is significant):
$ batch <<! diff file1 file2 2>&1 >outfile | mailx mygroup !
|Bulletin||Latest||Past week||Past month||
Sometimes you may need to run a job just once, rather than regularly. For this you use the at command. The commands to be run are read from a file specified with the -f option, or from stdin if -f is not used. The -m option sends mail to the user even if there is no stdout from the command. The -v option displays the time at which the job will run before reading the job. The time is also displayed in the output.
Listing 5 shows an example of running the mycrontest.sh script that you used earlier. Listing 6 shows the output that is mailed back to the user after the job runs. Notice that it is somewhat more compact than the corresponding output from the cron job.
Listing 5. Using the at command
[ian@lyrebird ~]$ at -f mycrontest.sh -v 10:25 Sat Jul 7 10:25:00 2007 job 5 at Sat Jul 7 10:25:00 2007
Listing 6. Job output from at
From email@example.com Sat Jul 7 10:25:00 2007 Date: Sat, 7 Jul 2007 10:25:00 -0400 From: Ian Shields <firstname.lastname@example.org> Subject: Output from your job 5 To: email@example.com It is now 10:25:00 on Saturday
Time specifications can be quite complex. Listing 7 shows a few examples. See the man page for at or the file /usr/share/doc/at/timespec or a file such as /usr/share/doc/at-3.1.10/timespec, where 3.1.10 in this example is the version of the at package.
Listing 7. Time values with the at command
[ian@lyrebird ~]$ at -f mycrontest.sh 10pm tomorrow job 14 at Sun Jul 8 22:00:00 2007 [ian@lyrebird ~]$ at -f mycrontest.sh 2:00 tuesday job 15 at Tue Jul 10 02:00:00 2007 [ian@lyrebird ~]$ at -f mycrontest.sh 2:00 july 11 job 16 at Wed Jul 11 02:00:00 2007 [ian@lyrebird ~]$ at -f mycrontest.sh 2:00 next week job 17 at Sat Jul 14 02:00:00 2007
The at command also has a -q option. Increasing the queue increases the nice value for the job. There is also a batch command, which is similar to the at command except that jobs are run only when the system load is low enough. See the man pages for more details on these features.
Ok, I got it! The issue was within the pam.conf and we were missing the following line:
cron account required pam_projects.so.1
Thanks for the help!
After some research I found out that Solaris logs crontab messages to /var/cron/log (which is actually pretty predictable logging for Solaris). The log entries for the updating of the sunfreeware mirror looked something like this:
> CMD: /usr/local/bin/update-sunfreeware
> ftp 21022 c Fri Jul 30 06:00:00 2004
! bad user (ftp) Fri Jul 30 06:00:00 2004
So we are talking about a bad user here. Well actually the user is all there and running in /etc/passwd and /etc/shadow. But hey wait, the FTP account is locked. Well I found that normal behaviour, but guess what, crontab expects a password there, else the account is not good and is a bad user!
Top Visited Bulletin Latest Past week Past month Google Search
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : C++ Humor : ARE YOU A BBS ADDICT? : Object oriented programmers of all nations : C Humor : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor: Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : The Most Comprehensive Collection of Editor-related Humor : Microsoft plans to buy Catholic Church : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor : Best Russian Programmer Humor : Russian Musical Humor : The Perl Purity Test : Politically Incorrect Humor : GPL-related Humor : OFM Humor : IDS Humor : Real Programmers Humor : Scripting Humor : Web Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor :
The Last but not Least
|You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.|
The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: January 28, 2013