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): RHNsatellite(EN)-3.2-RHI (2004-03-11T15:06) as I have no cheap way of accessing our intranet here, I did not check if this error persists in the most current version. How reproducible: Always 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 context. Expected Results: Telling the user about 'crontab -e' Additional info: Text suggestion: [...] To do this, edit the crontab as root. crontab -e 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 crontab -l Really nice would be a little box that tells the user about $EDITOR like follows. 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: export EDITOR=gedit 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 necessary.
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 of satellite-sync?
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 a num- ber of upward-compatible extensions. Each line has five time and date fields, followed by a user name if this is the system crontab file, followed by a command. Commands are executed by cron(8) when the ...
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 <cturner> To: Clay Murphy <cmurphy> CC: Mihai Ibanescu <misa>, Chris MacLeod <cmacleod>, Todd Warner <taw> References: <40C4C549.8000300> 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. Chip Clay Murphy <cmurphy> 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? > > Thanks, > -Clay
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
People, 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 until then. RU PCFE
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. ***
Golden!
*** Bug 123741 has been marked as a duplicate of this bug. ***