{"id":241,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:00","modified_gmt":"2020-08-22T20:26:00","slug":"this-is-the-page-title-toplevel-76","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=241","title":{"rendered":"cron"},"content":{"rendered":"\ncron<\/title>\n<p>\ncron is a commonly confusing and misconfigured aspect of the <glossary>operating system<\/glossary>.\nTechnically, cron is just the clock daemon\n(<command>\/usr\/sbin\/cron<\/command> or perhaps <command>\/usr\/sbin\/crond<\/command>) that executes commands at specific\ntimes. However, a handful of configuration files and programs go into making up the cron package. Like\nmany system processes, cron never ends.\n<\/p>\n<question id=\"144\" text=\"Where is the information stored that cron uses to start jobs for each user?\" \/>\n<concept id=\"\" description=\"The controlling files for cron are the cron-tables or crontabs.\" \/>\n<p>\nThe controlling files for cron are the cron-tables or crontabs. The crontabs are often located in\n<directory>\/var\/spool\/cron\/crontab<\/directory>. However, on SUSE you will find\nthem in <file type=\"\">\/var\/spool\/cron\/tabs<\/file>.\nThe names of the files in this directory are the names of the users that\nsubmit the cron jobs.\n<\/p>\n<p>\nUnlike other <glossary>UNIX<\/glossary>\ndialects, the Linux cron <glossary>daemon<\/glossary>\ndoes not sleep until the next cron job is ready. Instead, when cron completes one job,\nit will keep checking once a minute for more jobs to run. Also, you should not\nedit the files directly. You can edit them with text\neditor like <command>vi<\/command>, though there is the potential for messing things up. Therefore, you should use the tool\nthat Linux provides: crontab. (see the <glossary>man-page<\/glossary>\nfor more details)\n<\/p>\n<question id=\"145\" text=\"What command is used to submit commands to cron?\" \/>\n<p>The <command>crontab<\/command> utility has several functions. It is the means by which files\ncontaining the cron jobs are submitted to the system. Second, it can list the\ncontents of your crontab. If you are root, it can also submit and list jobs for\n<i>any<\/i> user. The problem is that jobs cannot be submitted individually.\nUsing crontab, you must submit all of the jobs at the same time.\n<\/p>\n<question id=\"505\" text=\"What command would you use to display the crontab for the user jimmo?\" \/>\n<p>\nAt first, that might sound a little annoying. However, let’s take a look at the\nprocess of “adding” a job. To add a cron job, you must first list out\nthe contents of the existing crontab with the -l option. If you are root and\nwish to add something to another user’s crontab, use the -u option followed by\nthe user’s <glossary>logname<\/glossary>.\n Then redirect this crontab to a file, which you can then\nedit. (Note that on some systems crontab has -e (for “edit”), which\nwill do all the work for you. See the <glossary>man-page<\/glossary>\nfor more details.)\n<\/p>\n<task name=\"\">Add a cron-entry for the user jimmo.<\/task>\n<p>\n<ol>\n<li>login as the root user<\/li>\n<li>Issue the command\n<commandexample command=\"crontab\">crontab -l -u jimmo >\/tmp\/crontab.jimmo<\/commandexample>\n<\/li>\n<li>Edit the file \/tmp\/crontab.jimmo using <command>vi<command>.<\/li>\n<li>Append the following line to the bottom of the file:<br \/>\n15 10,14 * * 1-5 \/usr\/local\/bin\/home_backup.sh<\/li>\n<li>Save the file and exit <command>vi<\/command>.\n<li>Active the new cron file with the command:<br \/>\n<commandexample command=\"crontab\">crontab -u jimmo \/tmp\/crontab.jimmo<\/commandexample>\n<\/li>\n<\/ol>\n<\/p>\n<p>\nNote: the script <command>\/usr\/local\/bin\/home_backup.sh<command> was created as an exercise in the section <site id=\"\">Backing Up Your System<\/site>.\n<\/p>\n<p>\nAs we saw, to add an entry, you simply add a new line. Save\nthe file, get out of your editor, and run the <command>crontab<\/command> command again.\nThis time, omit the <keyinput>-l<\/keyinput> to list the file but include the name of the file as an argument\nas opposed to redirecting the output. The <command>crontab<\/command>\nutility can also accept input from <glossary>stdin<\/glossary>,\nso you could leave off the file name and <command>crontab<\/command> would allow you to input the cronjobs on the\n<glossary>command line<\/glossary>. Keep in mind that any previous crontab is removed no matter what method you use.\n<\/p>\n<p>\nI am not a big fan of this for safety reason. I know people who have done it and I\nhave done it in the past myself and something wierd happened in the middle of making the\nchanges (e.g. network connection dropped) and the old file was completed wiped out.\nSo, I have grown used to redirecting the output to a file and then adding that. This\nway, should something go wrong, I always have the file.\n<\/p>\n<concept id=\"130\" description=\"Cron cannot run commands more often than once a minute.\" \/>\n<question id=\"146\" text=\"You can set cron to run once every second.\" \/>\n<question id=\"\" type=\"mc\" text=\"What cron entry would run a job every Sunday at 10:30 PM?\" \/>\n<p>\nWell, we added the entry, but it probably doesn’t say much. So, let’s take a look at\nthe actual entry.\nDespite its appearance, each crontab entry consists of only six fields.\nThe first five represent the time the job should be executed and the sixth is\nthe actual command. The first five fields are separated by either a space or a\ntab and represent the following units, respectively:\n<\/p>\n<ul>\n<li>minutes (0-59)<\/li>\n<li>hour (0-23) <\/li>\n<li>day of the month (1-31) <\/li>\n<li>month of the year (1-12) <\/li>\n<li>day of the week (0-6, 0=Sunday) <\/li>\n<\/ul>\n<p>\nTo specify all\npossible values, use an asterisk (*). You can specify a single value simply by\nincluding that one value. For example, the second line in the previous example\nhas a value of 10 in the first field, meaning 10 minutes after the hour. Because\nall of the other four time fields are asterisks, this means that the command is\nrun every hour of every day at 10 minutes past the hour. <\/p>\n<p>\nRanges of values are composed of the first value, a dash, and the ending value. For example, the\nfourth line has a range (1-5) in the day of the week column, meaning that the\ncommand is only executed on days 1-5, Monday through Friday.\n<\/p>\n<p>\nTo specify\ndifferent values that are not within a range, separate the individual values by\na comma. In the fourth example, the hour field has the two values 10 and 14.\nThis means that the command is run at 10 a.m. and 2 p.m.\n<\/p>\n<p>\nNote that times are additive. Lets look at the example above:<\/p>\n<p>\n<filecontents>\n15 10,14 * * 1-5 \/usr\/local\/bin\/home_backup.sh\n<\/filecontents>\n<\/p>\n<p>\nThe command is run 15 minutes after hour 10 and 14 on, Monday through Friday. Assume we\nwanted it to only run on on the 1st and 15, but only of they were a weekday. You might be\ntempted to do something like this:\n<p>\n<filecontents>\n15 10,14 1,15 * 1-5 \/usr\/local\/bin\/home_backup.sh\n<\/filecontents>\n<\/p>\nIf either the first\n<em>or<\/em> the 15th were on a weekend, the command would <i>still<\/i> run because\nthe day of the month field would apply. This is because these are OR-conditions, not AND-conditions. However,\nthis does not mean that if the first is a Monday, the command is run twice.\n<\/p>\n<p>\nAs of this writing, cron cannot be configure to create complex conditions. If you need to\nschedule jobs of this nature, take a look at the\n<a href=\"http:\/\/jobscheduler.sourceforge.net\/\">Open Source Job Scheduler<\/a>.\n<\/p>\n<task name=\"\">Create a crontab entry to run a job every 10 minutes<\/task>\n<p>\nThe crontab entry can be\ndefined to run at different intervals than just <i>every<\/i> hour or <i>every\n<\/i>day<i>. <\/i>\nThe granularity can be specified, for example, to every two minutes or every\nthree hours without having to put each individual entry in the crontab.\n<\/p>\n<p>\nLets say we wanted to run the previous command not at 10 minutes after\nthe hour, but every ten minutes. We could make an entry that looked like\nthis:\n<\/p>\n<p>\n<filecontents>\n0,10,20,30,40,50 * 1,16 * 1-5 \/usr\/local\/bin\/command\n<\/filecontents>\n<\/p>\n<p>\nThis\nruns every 10 minutes: at the top of the hour (0 minutes after), 10 minutes after, 20 minutes\nafter, and so on. Although this works, it could be done simpler by creating an\nentry like this:\n<\/p>\n<p>\n<question id=\"\" type=\"mc\" text=\"What syntax would run a cronjob every 8 Minutes?\" \/>\n<filecontents>\n*\/10 * 1,16 * 1-5 \/usr\/local\/bin\/command\n<\/filecontents>\n<\/p>\n<p>\nThis syntax may be new to some administrators, but is still pretty straightforward.\nThe slash (\/) says that within the specific interval (in this case, every minute), run the command every so many\n“units”. In this example, the units are minutes, so we are saying to run the job every 10 minutes. Specifying it\nas “*\/5” would say to run it every 5 minutes.\n<\/p>\n<p>\n<ol>\n<li>login as the root user<\/li>\n<li>Issue the command\n<commandexample command=\"crontab\">crontab -l -u jimmo >\/tmp\/crontab.jimmo<\/commandexample>\n<\/li>\n<li>Edit the file \/tmp\/crontab.jimmo using <command>vi<command>.<\/li>\n<li>Append the following line to the bottom of the file:<br \/>\n*\/10 * * * * \/usr\/local\/bin\/command<\/li>\n<li>Save the file and exit <command>vi<\/command>.\n<li>Active the new cron file with the command:<br \/>\n<commandexample command=\"crontab\">crontab -u jimmo \/tmp\/crontab.jimmo<\/commandexample>\n<\/li>\n<\/ol>\n<task name=\"\">Create a crontab entry to only run during normal work hours<\/task>\n<p>\nWe can combine both intervals and range.For example,\nif the job was to run every 10 minutes, but only between 8 AM and 5 PM,\nMonday through Friday, that is normal work\nhours. As we mentioned above, a range is specified by the start and end values\nseparated by a dash, so from 8 AM to 5 PM, it would look like this:\n<\/p>\n<p>\n<filecontents>\n8-17\n<\/filecontents>\n<\/p>\n<p>\nNote that in this case are using a 24 hour clock, so 5 PM is 17.\n<\/p>\n<p>\n<ol>\n<li>login as the root user<\/li>\n<li>Issue the command\n<commandexample command=\"crontab\">crontab -l -u jimmo >\/tmp\/crontab.jimmo<\/commandexample>\n<\/li>\n<li>Edit the file \/tmp\/crontab.jimmo using <command>vi<command>.<\/li>\n<li>Append the following line to the bottom of the file:<br \/>\n*\/10 8-17 * * * 1-5 \/usr\/local\/bin\/command<\/li>\n<li>Save the file and exit <command>vi<\/command>.\n<li>Active the new cron file with the command:<br \/>\n<commandexample command=\"crontab\">crontab -u jimmo \/tmp\/crontab.jimmo<\/commandexample>\n<\/li>\n<\/ol>\n<\/p>\n<p>\nIn this example, the job runs every ten minutes (*\/10), but only from 8-17\n(8 AM to 5 PM) and only on weekdays (day 1 to day 5)\n<\/p>\n<p>\nWhat if you wanted it to run at these times, but only every three minutes?\nThe line might look like this:<\/p>\n<p>\n<filecontents>\n*\/3 8-17 * * * 1-5 \/usr\/local\/bin\/command\n<\/filecontents>\n<\/p>\n<p>\nOne really nice thing that a lot of Linux dialects do is allow you to\nspecify abbreviations for the days of the week and the months. Its a lot easier\nto remember that fri is for Friday instead of 5.\n<\/p>\n<p>\nWith the exception of\ncertain errors in the time fields, errors are not reported until cron runs the\ncommand. All error messages <em>and<\/em> output is mailed to the users. At least\nthat’s what the crontab <glossary>man-page<\/glossary>\nsays and that is basically true. However, as you\nsee in the previous examples, you are redirecting <glossary>stdout<\/glossary>\nto <device>\/dev\/null<\/device>. If you\nwanted to, you could also redirect <glossary>stderr<\/glossary>\nthere and you would never see whether there were any errors.\n<\/p>\n<p>\nOutput is mailed to the user because there is no\nreal <glossary>terminal<\/glossary>\non which the cronjobs are being executed. Therefore, there is no\nscreen to display the errors. Also, there is no keyboard to accept input. Does\nthat mean you cannot give input to a cron job? No. Think back to the discussion\non <glossary>shell<\/glossary>\nscripts. We can redefine <glossary>stdin<\/glossary>,\n<glossary>stdout<\/glossary> and\n<glossary>stderr<\/glossary>. This way they can\nall point to files and behave as we expect. <\/p>\n<p>\nKeep in mind that cron is not exact nor does it run in real-time.\nIt synchronizes itself to the top of each minute. On a busy system in\nwhich you lose clock ticks, jobs may not be executed until a couple minutes\nafter the scheduled time. In addition, there may be other processes with higher\npriorities that delay cron jobs. In some cases, (particularly on very busy systems)\njobs might end up being skipped if they are run every minute.\n<\/p>\n<question id=\"147\" text=\"The root user can configure system-wide cron jobs in which file?\" \/>\n<question id=\"148\" text=\"In \/etc\/crontab, what additional attribute can root provide in each entry?\" \/>\n<p class=\"subtitle\">Add a cron job to the system-wide cron table<\/p>\n<p>\nCron provides two ways of starting regular jobs. One is on a per-user basis, where the users themselves get to\nmanage their jobs. The second and newer method is the ability of the root user to add jobs to the global cron\ntable that run as a specific user. In this task, you will learn how to add jobs to the global cron table\n<file type=\"\">\/etc\/crontab<\/file>.\nThis file provides a mechanism for the root user to run jobs as a different user without having to\nactually switch users (for example, using <command>su<\/command>).\nThis file is typically only writable by root and in some cases, only root can read it (which is often necessary in high\nsecurity environments).\n<\/p>\nAlthough root usually can run all of the necessary commands, you can use this mechanism when\nyou don’t want to deal with changing permissions after root as run a command. For example,\nif your script creates a new file it will typically be owned by root and probably won’t be readable\nmy most users. However, if you run the script as the appropriate user, permissions are typically not\nan issue.\n<p>\nThe general syntax is the same as the standard crontabs,\nwith a couple of exceptions.\nThe first difference is the <glossary>header<\/glossary>, which you can see here\nin the default file:\n<p>\n<filecontents>\nSHELL=\/bin\/sh\nPATH=\/usr\/bin:\/usr\/sbin:\/sbin:\/bin:\/usr\/lib\/news\/bin\nMAILTO=root\n#\n# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly\n#\n59 * * * * root rm -f \/var\/spool\/cron\/lastrun\/cron.hourly\n14 0 * * * root rm -f \/var\/spool\/cron\/lastrun\/cron.daily\n29 0 * * 6 root rm -f \/var\/spool\/cron\/lastrun\/cron.weekly\n44 0 1 * * root rm -f \/var\/spool\/cron\/lastrun\/cron.monthly\n<\/filecontents>\n<p>\nThe SHELL <glossary>variable<\/glossary>\ndefines the <glossary>shell<\/glossary> under which each command will run. The PATH\nvariable is like the normal PATH environment <glossary>variable<\/glossary>\nand defines the <glossary>search path<\/glossary>.\n The MAILTO <glossary>variable<\/glossary>\nsays who should get email messages, which includes error messages and the\n<glossary>standard output<\/glossary> of the executed commands.\n<p>\nThe structure of the actual entries is pretty much the same with the exception\nof the <glossary>user name<\/glossary>\n(root in each case here). This way, the root user (or whoever\ncan edit \/etc\/crontab) can define which user executes the command. Keep in mind\nthat this can be a big <glossary>security<\/glossary>\nhole. If someone can write to this file, they\ncan create an entry that runs as root and therefore has complete control of the\nsystem.\n<\/p>\n<p>\nWe will assume that we want to start the script \/usr\/local\/bin\/backup.sh every day at exactly 4 AM as the user root.\n<p>\n<ol>\n<li>Login as as root<\/li>\n<li>Edit the file <command>\/etc\/crontab<\/command><\/li>\n<li>Add the following line at the bottom of the file:<br \/>\n<filecontents type=\"crontab\">0 4 * * * root \/usr\/local\/bin\/backup.sh<\/filecontents>\n<\/li>\n<li>Save the file and quit.\n<\/ol>\n<p>\nIn this example, we specific the minutes (0) and the hour (4) and we used an asterisk (wildcard) for the\nremaining entries. This effectively means every day of every month. We could have also used an asterisk for\nany of the values, as needed. If we had wanted the script to only be started on Sundays, the entry might\nhave looked like this:\n<\/p>\n<p>\n<filecontents type=\"crontab\">0 4 * * 0 root \/usr\/local\/bin\/backup.sh<\/filecontents>\n<\/p>\n<p>\nOr, if we had wanted another script to be started once a year, it might look like this:\n<\/p>\n<p>\n<filecontents type=\"crontab\">0 4 1 1 * root \/usr\/local\/bin\/backup.sh<\/filecontents>\n<\/p>\n<p>\nIf both the day of the month and day of the week are specified, cron will run the job when either fields matches.\nFor example, specifying “0 4 1 * 1” would mean the first of every month <b>and<\/b> every Monday.\n<\/p>\n<p>\nNote that we logged in as root in order to edit the<file type=\"crontab\">\/etc\/crontab<\/file> file, but that\nput no restrictions on the user we specified in the fifth field. Instead we could have specified a different\nusers. This mechanisms allows you to run jobs as specific users without giving that user privileges to\nstart cron-jobs on their own. That is the\ngoal of the next task.\n<\/p>\n<concept id=\"3\" description=\"Unwanted cron output can be redirected just like any other command.\" \/>\n<question id=\"\" type=\"tf\" text=\"Due to its special nature commands started by cron cannot be redirected like any other commands.\" \/>\n<p>\nNote that cron actually starts a shell before executing the respective command. As a result, basically anything applies\nthat would apply to any command issue from within a shell. For example, you can redirect\n<glossary>stdin<\/glossary>, <glossary>stdout, <\/glossary> and <glossary>stderr<\/glossary>. For example, to redirect stderr\nfor the previous command, it might look like this\n<\/p>\n<p>\n<filecontents type=\"crontab\">0 4 * * 0 root \/usr\/local\/bin\/backup.sh 2>\/tmp\/backup.errors<\/filecontents>\n<\/p>\n<p>\nOne thing I would like to\npoint out is that I do not advocate doing <glossary>redirection<\/glossary>\nin the command field of\nthe crontab. I personally like doing as little there as possible. Instead, I put the\n<glossary>absolute path<\/glossary>\nto a shell script. I can then test the crontab entry with\nsomething simple. Once that works, I can make changes to the shell script\nwithout having to resubmit the cronjob.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"Assume you wish to allow all user to submit 'sron' and 'at' jobs, except for the users in a single department. Where would the easiest place be to do this?\" \/>\n<task name=\"\">Allow the user jimmo to create cron entries<\/task>\n<p>\nAccess is permitted to the cron facility\nthrough two files, both in <directory>\/etc<\/directory>. If you have a file <file>cron.allow<\/file>,\nyou can specify which users are allowed to use cron. The <file>cron.deny<\/file> says who are specifically not\nallowed to use cron. If neither file exists, only the system users have access.\nHowever, if you want everyone to have access, create an entry <file>cron.deny<\/file> file. In\nother words, no one is denied access.\n<\/p>\n<p>\n<ol>\n<li>login as the root user<\/li>\n<li>Edit the file \/etc\/cron.allow<\/li>\n<li>Append the following line to the bottom of the file:<br \/>\njimmo<\/li>\n<li>Save the file and exit <command>vi<\/command>.\n<\/ol>\n<p>\nIf you have experience with other aspects of Linux, this mechanism may appear familiar, where the\nfile <file>SERVICE.allow<\/file> gives you permissions to access the respective service and\n<file>SERVICE.deny<\/file> prevents you from accessing it. So, to disable access to cron, you could issue\nthe command:\n<\/p>\n<commandexample>\necho ALL >>\/etc\/cron.deny\n<\/commandexample>\n<p>\nNote that if neither of this files exist, then all users can access cron. Also, should <file>cron.allow<\/file>\nexist, only the users listed will have access. This is essentially the same as having “ALL” in\n<file>cron.deny<\/file>\n<\/p>\n<p>\nSome Linux distributions store the files in \/var\/spool\/cron. So, to disallow access\nyou would edit the file \/var\/spool\/cron\/deny.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>cron cron is a commonly confusing and misconfigured aspect of the operating system. Technically, cron is just the clock daemon (\/usr\/sbin\/cron or perhaps \/usr\/sbin\/crond) that executes commands at specific times. However, a handful of configuration files and programs go into … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=241\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-241","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/241","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=241"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/241\/revisions"}],"predecessor-version":[{"id":535,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/241\/revisions\/535"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=241"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}