At
m (Reverted edits by DavidYoung (talk) to last revision by Jimbo) |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 18: | Line 18: | ||
If all you want to do is force a job started from the shell into the background, you can do that without using '''at''' simply by adding an ampersand to the end of your command line - for example: | If all you want to do is force a job started from the shell into the background, you can do that without using '''at''' simply by adding an ampersand to the end of your command line - for example: | ||
| − | ph34r#''' cvsup /usr/share/examples/cvsup/ports-supfile | + | ph34r#''' cvsup /usr/share/examples/cvsup/ports-supfile &''' |
| + | |||
| + | However, if started that way the job is still a [[child process]] of your shell, and thus will die a sudden death if you choose to log out before it is done. | ||
| + | |||
| + | '''at''', on the other hand, will work as a tool to fire up a job without it being a child process of the shell: | ||
| + | |||
| + | ph34r# '''at now''' | ||
| + | '''echo test > /home/jimbo/test.txt''' | ||
| + | '''^D''' ''(user pressed control-D)'' | ||
| + | Job 14 will be executed using /bin/sh | ||
| + | ph34r# '''atq''' | ||
| + | Date Owner Queue Job# | ||
| + | Fri Feb 29 12:01:00 EST 2008 root c 14 | ||
| + | ph34r# '''date''' | ||
| + | Fri Feb 29 12:01:29 EST 2008 | ||
| + | |||
| + | OK, the job is in the queue - but it won't actually run until 12:05, since [[cron]] only fires up [[atrun]] once every 5 minutes. What if we don't want to wait? We can just run [[atrun]] manually! (Note: [[atrun]] probably will not be in your PATH, so you'll need to specify the full path to run it.) | ||
| + | |||
| + | ph34r# '''/usr/libexec/atrun''' | ||
| + | ph34r# '''atq''' | ||
| + | ph34r# '''date''' | ||
| + | Fri Feb 29 12:01:53 EST 2008 | ||
| + | ph34r# '''cat /home/jimbo/test.txt''' | ||
| + | test | ||
| + | ph34r# | ||
| + | |||
| + | As we can see, the job popped out of the queue and ran successfully when we fired up [[atrun]] manually. Knowing how to do this can save you a lot of frustration when you want to queue long running jobs up and make sure they're actually running before you close your shell and go somewhere else. | ||
| + | |||
| + | Access to either [[cron]] or the '''at''' scheduler may be open to all users or restricted only to certain users at the system administrator's discretion. | ||
| + | |||
| + | [[Category:System Commands]] | ||
Latest revision as of 16:30, 25 August 2012
The at scheduler is used to schedule a job for one-time-only running at a later date. For comparison, the cron scheduler is used to schedule jobs for repeated execution at regular intervals. One very handy use of the at scheduler is to schedule lengthy jobs to run in the background immediately - that way even if you need to (or are forced to) close your shell session, your job will continue running.
The basic syntax of at is to type at followed by a time (specified in POSIX time format) you wish your new job to be executed. Examples would be "at now" to run the job immediately, "at 0400" to run the job at 4 AM today, or "at 200409282300" to run the job at 11:00 PM on September 28th of 2004. Once this is done, you enter interactive mode, and any further commands you type will be part of the at job scheduled. Once you're done entering in commands to be scheduled, you press CTRL-D (aka the eof character) and the scheduler tells you what your job number is and what shell it will be executed with (typically /bin/sh by default).
ph34r# at now cvsup /usr/share/examples/cvsup/ports-supfile [user presses CTRL-D] Job 3 will be executed using /bin/sh ph34r#
You may also use the -f option to specify a file that contains the list of commands you wish to process - for example:
ph34r# echo "cvsup /usr/share/examples/cvsup/ports-supfile" > at-job.txt ph34r# at -f at-job.txt now Job 5 will be executed using /bin/sh ph34r#
If all you want to do is force a job started from the shell into the background, you can do that without using at simply by adding an ampersand to the end of your command line - for example:
ph34r# cvsup /usr/share/examples/cvsup/ports-supfile &
However, if started that way the job is still a child process of your shell, and thus will die a sudden death if you choose to log out before it is done.
at, on the other hand, will work as a tool to fire up a job without it being a child process of the shell:
ph34r# at now echo test > /home/jimbo/test.txt ^D (user pressed control-D) Job 14 will be executed using /bin/sh ph34r# atq Date Owner Queue Job# Fri Feb 29 12:01:00 EST 2008 root c 14 ph34r# date Fri Feb 29 12:01:29 EST 2008
OK, the job is in the queue - but it won't actually run until 12:05, since cron only fires up atrun once every 5 minutes. What if we don't want to wait? We can just run atrun manually! (Note: atrun probably will not be in your PATH, so you'll need to specify the full path to run it.)
ph34r# /usr/libexec/atrun ph34r# atq ph34r# date Fri Feb 29 12:01:53 EST 2008 ph34r# cat /home/jimbo/test.txt test ph34r#
As we can see, the job popped out of the queue and ran successfully when we fired up atrun manually. Knowing how to do this can save you a lot of frustration when you want to queue long running jobs up and make sure they're actually running before you close your shell and go somewhere else.
Access to either cron or the at scheduler may be open to all users or restricted only to certain users at the system administrator's discretion.
