HPR4637: UNIX Curio #6 - at and batch

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. I would imagine that most users of UNIX-like systems have heard of cron —certainly any system administrator should have. Briefly, cron is a way of running a job repeatedly based on the time and date; for example, a job could run every hour, at 5:00am every Tuesday, or the 3rd of every month. It is commonly used for administrative or maintenance tasks that should be done on a regular schedule, such as checking for software updates, rotating log files, or updating the database for the locate command. As well-known as cron is, there is a similar utility that very few seem to be aware of: at . This is the word "at", and has nothing to do with the at symbol "@". An at job is very much like a cron job, except that an at job only runs one time. A job is submitted by running at timespec 1 , where timespec is the time and date the job is to be run. The linked POSIX specification page describes acceptable formats for timespec ; some examples are " now ", " 14:00 ", " noon tomorrow ", " 14:00 + 3 months ", and " 14:00 January 19, 2038 ". The utility then waits on standard input for you to enter a set of commands to be run in the job. You end input by typing Control-D to mark the end of text. (As an alternative to typing in the job, you could instead use the "<" symbol to redirect standard input to come from a file containing the commands you want to run.) When the specified time arrives, the job will be run. That is the theory, anyway, but some things may interfere. The normal configuration for some implementations only checks for due at jobs every five minutes, so there can be a delay before a job is actually run. Also, if the system isn't running, obviously it can't execute any jobs. When it comes back up, typically it will check for any pending at jobs that are currently or past due and run those. It is best to think about an at job being run no earlier than the time it was scheduled for, and probably soon after, provided the system is up. The POSIX standard doesn't specify anything about when jobs are actually run, just that they are scheduled for a particular date and time. The user does not need to be logged in for a job to run—if the job outputs anything to standard output or standard error, that text will be e-mailed to the user, presuming the system is set up to send mail. This is often true for a server, which might be running a Mail Transfer Agent like sendmail , postfix , or exim , but many desktops are not. If nothing is output to standard output or standard error, or if that output is redirected to a file, then mail will not be sent on job completion. This behavior can be changed with the -m option; in that case, mail will always be sent when the job finishes whether or not there is any output. The batch command is very similar 2 —POSIX specifies it as being equivalent to at now with two differences. First, jobs are put into a different queue, and second, mail is always sent when a job completes as if the -m option was used with at . In practice, however, certain aspects of the behavior of batch depend on the implementation. On the large majority of systems I investigated 3,4,5,6,7,8 , but not all 9 , batch jobs will only be run when the system load level drops below a certain point. This can typically be configured by the administrator but has a default value—the manual pages for a couple systems don't actually list a default value and just say batch jobs will run "when system load levels permit". Basing execution on the load level makes sense if the batch utility is seen as a way of running potentially resource-intensive jobs when the system is not being heavily used. However, this behav