From owner-freebsd-questions Fri May 22 02:24:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14746 for freebsd-questions-outgoing; Fri, 22 May 1998 02:24:06 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from lucy.bedford.net (lucy.bedford.net [206.99.145.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA14695 for ; Fri, 22 May 1998 02:23:58 -0700 (PDT) (envelope-from listread@lucy.bedford.net) Received: (from listread@localhost) by lucy.bedford.net (8.8.8/8.8.8) id FAA17487 for freebsd-questions@freebsd.org; Fri, 22 May 1998 05:16:37 -0400 (EDT) (envelope-from listread) Message-Id: <199805220916.FAA17487@lucy.bedford.net> Subject: /etc/crontab fishiness To: freebsd-questions@FreeBSD.ORG Date: Fri, 22 May 1998 05:16:36 -0400 (EDT) Reply-to: djv@bedford.net From: CyberPeasant X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The crontab(5) man page asserts that variables declared in a crontab, such as HOME=/var/log in /etc/crontab will be passed to the commands executed. In the case at least of /etc/crontab executing the supplied /etc/weekly script, this is not the case. Place "echo $HOME" in that script, and see "/root", not the expected "/var/log". Because of this, the updatedb script, further on, will fail with the error messages: shell-init: could not get current directory: \ getcwd: cannot access parent directories job-working-directory: could not get current directory: \ getcwd: cannot access parent directories Someone asked about these within the last few days. A generally correct answer was given, but this is the specific cause, I think: This error occurs because the /usr/libexec/locate.updatedb script is run later as user "nobody", and in many systems (mine, and I bet hers, who reported this problem), root's homedir has restricted permissions, in my case 600 or 700 depending on my mood. "nobody" can't get his bearings with these permissions, and the command fails. The fix is to allow world read/execute for /root (eh, when pigs have wings, maybe ;), or to cd to the HOME which the crontab suggests, but does not implement. Accomplish this by placing cd /var/log before this line in /etc/weekly: echo /usr/libexec/locate.updatedb | nice -5 su -fm nobody 2>&1 |\ fgrep -v 'Permission denied' The top of the file is a place before that line. There are other su's in there, and possibly also in /etc/daily and /etc/monthly, that may fail for similar reasons. This affects more systems than FreeBSD (Linux RH 4.1 is afflicted), but I have usually just hacked it by not using the su. Or by getting impatient, cd'ing to /etc and doing "sh weekly". Of course, in this condition, it /works OK/, since "nobody" can r-x /etc. Su'ing to "nobody" is a privacy/security measure when building locate.db in systems running with many human users. Dave -- Unix System 7: an improvement on all other Unix releases, previous and subsequent. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message