Trouble-shooting Cron Problems FreeBSD5.4
After building a new FreeBSD5.4 system, I have done something bad to it. When cron runs jobs in /etc/crontab as operator, it seems as if that 6TH field in /etc/crontab is being interpreted as a command rather than the user ID it is supposed to run under. I keep getting messages like: From:[EMAIL PROTECTED] (Cron Daemon) Subject: Cron [EMAIL PROTECTED] root newsyslog root: not found Comparing this system with another properly-functioning 5.4 system has, as of yet, shown nothing unusual. If I become root and manually run the job in question, it runs without a complaint. The crontab file on the problem system is an exact copy of the crontab file on the working system. Both crons appear to be running with the same flags as in 465 ?? Ss 3:24.39 /usr/sbin/cron -s Any suggestions as to what I should look at next? Both systems' crons are showing the same environments if I make them run the env command. Many thanks. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Network Operations Group ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble-shooting Cron Problems FreeBSD5.4
On Tuesday 31 October 2006 12:08, Martin McCormick wrote: After building a new FreeBSD5.4 system, I have done something bad to it. When cron runs jobs in /etc/crontab as operator, it seems as if that 6TH field in /etc/crontab is being interpreted as a command rather than the user ID it is supposed to run under. I keep getting messages like: From:[EMAIL PROTECTED] (Cron Daemon) Subject: Cron [EMAIL PROTECTED] rootnewsyslog root: not found Comparing this system with another properly-functioning 5.4 system has, as of yet, shown nothing unusual. If I become root and manually run the job in question, it runs without a complaint. The crontab file on the problem system is an exact copy of the crontab file on the working system. Both crons appear to be running with the same flags as in 465 ?? Ss 3:24.39 /usr/sbin/cron -s Any suggestions as to what I should look at next? Both systems' crons are showing the same environments if I make them run the env command. Many thanks. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Network Operations Group ___ freebsd-questions@freebsd.org mailing list Martin, Post the offending line or even all of /etc/crontab lane ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble-shooting Cron Problems FreeBSD5.4
In the last episode (Oct 31), Martin McCormick said: After building a new FreeBSD5.4 system, I have done something bad to it. When cron runs jobs in /etc/crontab as operator, it seems as if that 6TH field in /etc/crontab is being interpreted as a command rather than the user ID it is supposed to run under. I keep getting messages like: 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). From:[EMAIL PROTECTED] (Cron Daemon) Subject: Cron [EMAIL PROTECTED] rootnewsyslog operator won't be able to run newsyslog anyway, since it can't write to /var/log and can't send signals to syslogd (which runs as root). You'll probably want to move those lines back to the system crontab. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble-shooting Cron Problems FreeBSD5.4
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
