Date: Tue, 31 Oct 2006 13:49:24 -0600 From: Martin McCormick <martin@dc.cis.okstate.edu> To: freebsd-questions@freebsd.org Subject: Re: Trouble-shooting Cron Problems FreeBSD5.4 Message-ID: <200610311949.k9VJnOVN003318@dc.cis.okstate.edu>
next in thread | raw e-mail | index | archive | help
Dan Nelson writes: > The "operator" user has no access to /etc/crontab. You have probably > copied entries from the system crontab (i.e. /etc/crontab) into a > user's crontab. The system crontab has the extra "user" column, where > user crontabs don't (since they always run as the user). > Thank you. That is exactly what happened. I checked the working system by doing crontab -e -u operator and there was no crontab there at all. I then went to the ailing system and, voila, there was the copy of /etc/crontab complete with all its comment lines. I remember being confused at one stage about /etc/crontab because of the line \# /etc/crontab - root's crontab for FreeBSD After all, the root user also has a crontab file with the normal user fields (minus the special 6TH field). Somewhere along the way, I probably typed either crontab -u operator crontab from /etc or did a crontab -e -u operator and joined /etc/crontab in to the new table. Remember the saying that goes, "Nothing can be made foolproof because fools are so ingenious?" That pretty well says it all. I am not sure how I figured it might need to go in the operator account, but that's where it wound up. I am sure that solves the problem. I'll know in 15 minutes when the next newsyslog command fires and I don't get the squawk.:-) Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Network Operations Group
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610311949.k9VJnOVN003318>