[13436] in Athena Bugs
sun4 [7.7R]: {/srvd,}/usr/spool/cron/crontabs/root
daemon@ATHENA.MIT.EDU (jweiss@MIT.EDU)
Thu Apr 20 21:26:52 1995
From: jweiss@MIT.EDU
Date: Thu, 20 Apr 1995 21:26:40 -0400
To: bugs@MIT.EDU
Cc: jweiss@MIT.EDU, mhbraun@MIT.EDU
Let me preface this with the comment that there may not be a bug here,
but I don't think this could be a whole lot more counter-intuitive if
we tried.
System name: the-other-woman
Type and version: SPARC/Classic 7.7R
Display type: cgthree
: What were you trying to do?
I was trying to figure out why my machine stopped cleaning
/tmp and /usr/tmp.
: What went wrong?
Well it turns out that /etc/athena/clean_tmp_areas wasn't
being run from cron.
: OK, so where'd it go, it's still there on public machines?
Hmmm, where'd I put that crontab file anyhow? Ah, there it
is, /usr/spool/cron/crontabs/root. Well let's see if we can answer
your question... Lemme take a quick look at the version on the srvd
to make sure I didn't do anything really stupid while editing it or
something. Nope, the version on the srvd
(/srvd/usr/spool/cron/crontabs/root) is the same as the one I have on
local disk (/usr/spool/cron/crontabs/root), modulo the single line
I've added. Ok good, I didn't think I was that much of a bonehead.
So, where was I? Oh, right, where @i(did) that clean_tmp_areas line
go. Well, you know the private script I run whenever I run mkserv,
does blow away root's crontab and start over, and I do start with the
version that is on the srvd, so I guess it makes some sense that I
don't have it, since it isn't in the copy on the srvd.
Don't worry, I know what you're going to ask next. So, if it isn't in
the version on the srvd, where did the public workstations get it
from? Ah, we're finally getting to the meat of the matter. Excuse me
while I roll my chair down to the public sun next to me for a
moment.... OK, I'm back. A quick examination shows that
/usr/spool/cron/crontabs/root and /srvd/usr/spool/cron/crontabs/root
are completely unrelated on a public sun. Let me repeat that, just in
case you didn't catch it the first time...A quick examination shows
that /usr/spool/cron/crontabs/root and
/srvd/usr/spool/cron/crontabs/root are completely unrelated on a
public sun. I think we've identified my problem here. Silly me, I
made the assumption that /foo and /srvd/foo would always be the same
(or symlinked) with the exception of things like rc.conf and nodename
which are host dependent.
: But wait, you haven't told me where the public workstations get the
: clean_tmp_areas line from, you've only explained how you lost, because
: you didn't test one of your assumptions.
I'm sorry, you're right. Since I tend to update my
workstation by hand, I remember that it usually says "Updating root's
crontab (old crontab is in /tmp/crontab.old)", I wonder if this update
installs the clean_tmp_areas line. Hmmm, lemme look at
/srvd/update_ws. Hmm nothing there, it does run
/srvd/usr/athena/lib/update/do_update tho, that looks promising. Ah,
yes here's the code, case we're on a SPARC, echo that warning about
updating the crontab. yup, next line... copy the crontab to /tmp just
like we said, good. next line... Ah, here it is the culprit
(/srvd/usr/athena/lib/update/do_update line 216) we're copying
/srvd/etc/crontab.root.add to /var/spool/cron/crontabs/root.
: Wait, wait, wait. I can read filenames, that file was called
crontab.root.add, you meant it was added to
/var/spool/cron/crontabs/root, right?
Nope, copied, blowing away what's there.
: So where's this add-ing done?
It isn't, the .add suffix is just there as a diversion, I guess.
: Oh.
: I suppose this is where I'm supposed to ask what was supposed to happen.
Probably.
: Oh alright, but my head hurts right now.
Mine too
: What should have happened?
We shouldn't be copying files from places like /srvd/etc/cron.d to
/usr/spool/cron/crontabs/root when we could have just put it in
/srvd//usr/spool/cron/crontabs/root in the first place. I don't even
think there are any good arguments about not mucking with the base OS
that really apply here.
: Ok, I guess that makes sense, got any aspirin?
Generic brand Ibuprophen OK?
: Yeah
Yup, right here.
: Thanks
No problem.
And Matt, since you took my .private script, you've got a crontab that
probably isn't the one you want.
