3

A few hours ago I just created a fresh VPS environment and right on the start did crontab -e, pasted my cronjobs from a file, and saved.

I did crontab -e a few minutes ago and saw that the file name is:

/tmp/crontab.MSK8I2/crontab

enter image description here

Why is that? Thx,

1 Answers1

4

Running crontab -e edits users' crontabs (rather than the system crontab /etc/crontab). If you run sudo crontab -e, this edits the root account's user crontab (which is not the same as /etc/crontab). The root account's user crontab is usable, but is often not what system administrators wish to edit.

When you run crontab -e, the crontab utility copies the particular user-specific crontab file being edited to a temporary file. This is the intended and correct behavior. Assuming you make changes to the temporary file in the editor, crontab then automatically writes those changes back to the crontab file after you finish editing.

Braiam has explained some details as to why and how this is done in "Cron, crontab -e reads the wrong file" on Unix.SE:

That's the default behavior. crontab -e would copy the crontab file to the temporary directory, then use the editor listed in VISUAL or EDITOR environment variables to open this file, when saving, it would then try to copy the file to the original location. This is an atomic operation.

The reasons behind this are varied, from preventing two users to edit the same file at the same time to have a sanity/syntax check before writing the original file.

Ah, the crontab -e also do not trim the file in any way, unless you use Debian.

The screenshot in your question shows something very much like this, which is the default commented text of a user crontab in Ubuntu:

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command

In contrast, a default system crontab (/etc/crontab) in Ubuntu looks like this:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

As siloko explains in "Crontab -e opens new file each time I run it," and as discussed in the default system crontab's leading comments (shown above), one way the systemwide crontab /etc/crontab differs from the per-user crontabs is that each entry contains a field that specifies what user runs the command. The example above has root for each of the three commands, but you can cause commands to be run as other users by specifying their usernames in that field.

Although I cannot be sure, my guess is that your are trying to edit the system crontab rather than root's (or anyone else's) user crontab.

Further reading:

Eliah Kagan
  • 117,780
  • Given this, if I do cat << CTABINJECT >> /etc/crontab ...content... CTABINJECT I could inject data to the systems' global cron directly (which effects all users) ? –  Jan 01 '17 at 06:37
  • @Benia That specific command, at least as it's displayed in your comment, doesn't look like it would work, since it lacks newlines around the contents of the here document. But if you're asking if it's possible to append lines to the end of /etc/crontab, which if well-formed will then be run by the cron daemon, then the answer is yes. Of course, like other ways of editing /etc/crontab, it will only succeed if done as root; as revealed by ls -l /etc/crontab, the system crontab is owned by root with permissions 644. – Eliah Kagan Jan 01 '17 at 06:48
  • Hi, sure, I will do it with newlines. Yes I will do it as root. This is something very important for me to do as part of a script. I would thank you dearly Eliah if you would add an appendix on this to the end of the question. In great plea. –  Jan 01 '17 at 06:50
  • @Benia I'm glad to have been of help. I'm not sure what you mean by an appendix on this, though. What is it you hope I might add? If you think this answer would benefit from a short statement about how well-formed lines appended to the end of /etc/crontab cause additional commands to be run by the cron daemon, I could add that, or you could even submit a short edit to this post. However, if you're asking for information on how to write crontab entries, I recommend How do I set up a Cron job? (I'm adding that now) and the other resources linked in my answer. – Eliah Kagan Jan 01 '17 at 07:01
  • I thank you again for everything and have accepted the answer. Indeed by appendix I mean to a statement about how to properly append ready-from-file cron directives, into /etc/crontab. –  Jan 01 '17 at 07:08