Red Hat Bugzilla – Bug 125505
tell users to use 'crontab -e'
Last modified: 2009-08-19 23:05:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
section '8.4. Automating Synchronization' tells the user about cron
editing in a convulted way.
We support 'crontab -e' on RHEL 2.1 and should tell users about it.
Version-Release number of selected component (if applicable):
as I have no cheap way of accessing our intranet here, I did not check
if this error persists in the most current version.
Steps to Reproduce:
1. read section 8.4
2. follow the steps
Actual Results: user is told to redirect to a file, edit said file
and reimport, this is not elegant.
Whatsmore, IMHO the word 'root' should not be put in, even in that
Expected Results: Telling the user about 'crontab -e'
To do this, edit the crontab as root.
Add the satellite-sync job to the list. For instance, the following
item sets the synchronization to occur every night at 11:10 p.m. and
have the resulting changes emailed to the traceback mail recipient:
10 23 * * * /usr/sbin/satellite-sync --email
When you save and quit in the editor, the crontab is activated. You
can verify the crontab with
Really nice would be a little box that tells the user about $EDITOR
The editor that is used by 'crontab -e' is by default vi. If you set
the variable EDITOR, another editor can be used. For example:
will use gedit to edit the crontab. This affects all programs that use
the variable EDITOR.
one more thing, the crontab line should read
10 23 * * * /usr/sbin/satellite-sync --email >/dev/null 2>/dev/null
Otherwise the user gets 2 e-mails, one from cron (which is hard to
read due to the printed hash marks) and one from the --email flag.
Yes, these two could be different recipients, but in most cases they
will not be.
Probably best to explain wht the redirection of stdout and stderr is
satellite-sync should only do the hashmark thing if stdout is a tty;
otherwise it shouldn't print them for the reason you point out
will --email report any tracebacks and such encountered in the running
Alright, I've merged Patrick's suggestions with those made by Chip in
a separate email (see below). In short, I suggest using crontab -e to
add a random sync job, like so:
0 1 * * * root perl -le 'sleep rand 9000' && satellite-sync --email
Also, I included Patrick's note about changing text editors. I left
the --email option as it stands since we're not sure we want to
redirect its output.
You guys holler if I got this wrong. Otherwise, I'm aligning this bug
to the 340 release, setting it to QA_READY and mentioning that it
kinda negates the fix for bug 123741.
Clay, that line of crontab is not valid in crontab -e.
crontab -e uses the user's crontab (i.e. root's) as opposed to
/etc/crontab. Therefore, 'root' should be taken out.
from 'man 5 crontab':
The format of a cron command is very much the V7 standard, with
ber of upward-compatible extensions. Each line has five time
fields, followed by a user name if this is the system
followed by a command. Commands are executed by cron(8)
Thanks for the catch, Mihai. I know I already said to edit the crontab
as root, but in my ignorance and haste, I assumed this inclusion was
part of the instruction for perl.
Regardless, 'root' has been removed from that line. For completeness,
I'm pasting in the email I got from Chip on this subject, since I said
I would in my last comment:
-------- Original Message --------
Subject: Re: Sat-sync cron timing
Date: Tue, 08 Jun 2004 22:35:58 -0400
From: Chip Turner <firstname.lastname@example.org>
To: Clay Murphy <email@example.com>
CC: Mihai Ibanescu <firstname.lastname@example.org>, Chris MacLeod
<email@example.com>, Todd Warner <firstname.lastname@example.org>
Tell users to use 'crontab -e' not edit crontab directly.
It would be nice to tell users to do this:
perl -le 'sleep rand 3600' && satellite-sync --email
That gives a one hour random factor to when it runs and helps protect
our servers. Even better is to add a simple --random-delay param to
satellite-sync that will do a little sleep before the rest of it
runs. That way we can tell people to invoke it that way.
Instead of editing crontab or using crontab -e, we could provide users
with a sample cron.d script like this and tell them to put it in
/etc/cron.d if they want nightly sync:
0 1 * * * root perl -le 'sleep rand 9000 && satellite-sync --email
That will run between 1am and 3:30am local box time randomly each
night. Generally extension software (like ours) should drop files in
/etc/cron.d instead of editing crontab or having users manually add
crontabs. We could even put that sample crontab in /usr/share/docs
somewhere as an example or whatnot.
Clay Murphy <email@example.com> writes:
> Howdy gents,
> Todd suggested I write you. I'm trying to address bug 123741 opened by
> Andrew Anderson to resolve conflicts between automated satellite-sync
> jobs and cron.daily. See the attached log of my talk with Todd.
> As a result, I've written and emphasized a note in the Automating
> Synchronization section of the Sat. Install Guide section that says
> not to set up sync cron jobs for the top of the hour. Do you have
> anything else to offer?
the discrepency here is that /etc/cron.d files have the user to run as
following the five 'when' columns, whereas /etc/crontab and a user's
crontab have assumed owners.
if we provide a sample on the file system, it should be in the cron.d
format so someone can just copy it into place (w/o having to edit
other system files). if we only provide reference in the help files,
then either is fine
I agree with Chip in that we really should provide a drop in for cron.d
Until then, the docs fix as in comment #3 (without 'root' of course)
looks good to me, but I still thinks we should include comment #1
Should I open separate bugs for:
a) a not printing hash marks switch to satellite-sync (that would
help when using screen as well)?
b) a --randomize <minutes> flag to satellite-sync?
As I am on site until next Thursday, responses on my side may be slow
Created attachment 101023 [details]
mbox with a cron e-mail and a traceback report email
To Chip: attached is a mbox with 2 messages, the first is the e-mail that was
generate when not redirecting stdout and stderr to /dev/null. The second is a
report where the sat did traceback (the proxy it uses was down), so we can
really redirect to /dev/null. I did replace the machine name in the e-mails
with the string PRIVACY as this is a customer machine.
todd, attached is a script that lets you see if something is a tty or
not. run it to test its output, doing things like test-tty.py <
/dev/null, test-tty.py | cat, etc. should be sufficient for satsync
Created attachment 101025 [details]
simple script showing how to detect if a file descriptor is attached to a tty
Alright, I don't know what the results of the rest of the discussion
will be, but Patrick convinced me; I've added his stdout and stderr
redirection and explained in the subsequent paragraph this prevents
duplicating a more easily read message from satellite-sync.
Also, I'm copying Todd on this bug since I don't know if he's
explicitly involved with it yet.
Also see bug 131442
*** Bug 131442 has been marked as a duplicate of this bug. ***
*** Bug 123741 has been marked as a duplicate of this bug. ***