I couldn't get the "at" command to work on my new DUNIX 3.2d system.
Dr. Tom Blinn at DEC had the answer to my problem! I had accidentally
removed a needed ".proto" file in the /var/adm/cron directory.
His answer is very informative, so I reproduce it whole below.
-Phil Farrell, Computer Systems Manager
Stanford University School of Earth Sciences
farrell_at_pangea.stanford.edu
To: Phil Farrell <farrell_at_pangea.Stanford.EDU>
Subject: Re: Getting 'at' command to run under DUNIX 3.2d
Date: Fri, 26 Jul 96 09:33:08 -0400
From: "Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com>
>From the "at" reference page:
You can use at if your login name appears in the /usr/lib/cron/at.allow
file, if that file exists, or if there is no at.allow file and your name is
not in the /usr/lib/cron/at.deny file. The at.allow and at.deny files con-
tain one username per line. Note that /usr/lib/cron is symbolically linked
to /var/adm/cron.
If neither the at.allow nor the at.deny file exists, only someone with root
user authority can submit a job.
To allow global access to at, the system administrator can remove the
at.allow file and create a zero-length at.deny file.
If these files don't exist, that could be the source of the error message.
But it's not.
However, I have to admit that I am at a loss to explain exactly where the
message is coming from; I can't find any message string including the text
"protocol" that's directly associated with "at" or "cron". I think the
reason I was having trouble finding the error is that it's really called
a "prototype" file, not a "protocol" file. This took me a while to figure
out -- in the future, be sure you capture the EXACT error message, not an
approximation.
I do see this snippet of code that may be the culprit:
if((pfp = fopen(pname1,"r")) == NULL && (pfp=fopen(pname,"r"))==NULL)
atabort(MSGSTR(MS_NOPROTO, NOPROTO));
The values of pname and pname1 appear to be set up by this snippet of code:
sprintf(pname, "%s", PROTO);
sprintf(pname1, "%s.%c", PROTO, 'a'+jobtype);
which is run just before we call the copy() routine that contains the code
that looks like it produces the NOPROTO error.
When I look in the usr/sbin/cron header files, I find this definition:
grep PROTO *.h
#define PROTO "/var/adm/cron/.proto"
So what's happening here is that "at" is trying to read a file with the name
either /var/adm/cron/.proto or /var/adm/cron/.proto.{a-f} where the letter
at the end is determined by the "at" job type (see the reference pages).
On my system, the file /var/adm/cron/.proto exists. It was delivered as
part of my OSFBASE3xx subset as .new..proto into the directory, and moved
to .proto...proto and then into .proto by the subset configuration.
If you modified your system to remove all the .proto* files then you've
hosed your system. Some people do this because they don't know what the
files are for and think they can save space by removing them.
If you didn't do that, I don't know why the file didn't wind up where it
should be on the system. I have installed V3.2D on many systems and I can
not recall ever seeing the problem you report.
Tom
Dr. Thomas P. Blinn, UNIX Software Group, Digital Equipment Corporation
110 Spit Brook Road, MS ZKO3-2/U20 Nashua, New Hampshire 03062-2698
Technology Partnership Engineering Phone: (603) 881-0646
Internet: tpb_at_zk3.dec.com Digital's Easynet: alpha::tpb
Worry kills more people than work because more people worry than work.
My favorite palindrome is: Satan, oscillate my metallic sonatas.
-- Phil Agre, pagre_at_ucsd.edu
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else, living or dead, real or imagined.
Received on Fri Jul 26 1996 - 20:47:48 NZST