0

When I run crontab -l on a new user that does not have any crons yet, the result is like this and the command fails and exits

no crontab for [user]

If I run crontab -e on a new user the result is as follows and the crontab editor opens.

no crontab for [user] - using an empty one

Where is it pulling the following verbage from?

# 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

Specifically what file holds these instructions.

I would like to run the commands like this:

[instructions file] > temp_file
[a cron job] >> temp_file
crontab temp_file
rm temp_file

However running this fails due to there being no cron file for the new user:

crontab -l > temp_file
[a cron job] >> temp_file
crontab temp_file
rm temp_file
1

The text actually appears to be built in to the crontab.c source code rather than read from a file at execution time:

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

        /* ignore the top few comments since we probably put them there.
         */

The variable add_help_text is non-zero if crontab fails to find an existing spool file for the user:

log_it(RealUser, Pid, "BEGIN EDIT", User);
(void) snprintf(n, MAX_FNAME, CRON_TAB(User));
if (!(f = fopen(n, "r"))) {
        if (errno != ENOENT) {
                fprintf(stderr, "%s/: fdopen: %s", n, strerror(errno));
                exit(ERROR_EXIT);
        }
        fprintf(stderr, "no crontab for %s - using an empty one\n",
                User);
        if (!(f = fopen("/dev/null", "r"))) {
                perror("/dev/null");
                exit(ERROR_EXIT);
        }
        add_help_text = 1;
}
  • +1 for the good finding. I thought so as well but didn't find the relevant source code. I thought fiddling around with the CRONTAB_NOHEADER environment variable could help, but was wrong. It's just for the DON'T EDIT header. – PerlDuck Apr 14 '18 at 19:27
0

It's built in to the executable:

strings $(type -p crontab) | less "+/Edit this file to introduce tasks to be run by cron"

No need to consult the source. I agree the source in the One True Document.

  • Well, sometimes strings returns garbled output and often the hardcoded text in a binary is just the last ressort if no external config file is found. – PerlDuck Apr 14 '18 at 20:11
  • @PerlDuck Careful inspection of strings output (run on an ELF binary) can show you all the files it may open, embedded texts, version strings, ... . The output isn't garbled, just some binary fields can also be seen as text. I'd also like examples of "often the hardcoded text in a binary is just the last resort". I've seen programs that write a missing config file with default values, copy a default file from somewhere else, ... – waltinator Apr 14 '18 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy