Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!ut-emx!jwe
From: jwe@ut-emx.UUCP (John W. Eaton)
Newsgroups: comp.unix.ultrix
Subject: Re: DECsystem 3100 at atrun batch problem
Keywords: DECsystem 3100 at atrun batch Ultrix 3.1 (Rev. 14)
Message-ID: <32716@ut-emx.UUCP>
Date: 28 Jun 90 09:01:37 GMT
References: <439@beguine.UUCP> <32670@ut-emx.UUCP> <1818@tkou02.enet.dec.com>
Reply-To: jwe@emx.utexas.edu (John W. Eaton)
Organization: The University of Texas at Austin, Austin, Texas
Lines: 37

In article <32670@ut-emx.UUCP>, about jobs not being executed by the
Ultrix version of at(1), I wrote:

: Take a look at the Ultrix version of the man page for at(1) and look
: for the comments about the files /usr/lib/cron/at.{deny,allow}.

In article <1818@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com
Norman Diamond replied:

> That "answer" does not answer the problem.  If the deny (and/or
> allow) lists are not suitably established, then an ordinary user is
> prevented from even submitting a batch/at job.

Ooops, You're right.  Requests are met with a message something like
`at: Privilege denied'.

In any case, is this a DECsystem specific bug?  We are running Ultrix
3.1 (Rev. 11) on a VAXstation 3200 and `at' works as advertised.  It
seems very odd that it would somehow be machine specific...

Also, as someone else mentioned, the at.{deny,allow} are really in
/var/spool/at and not /usr/lib/cron.  (On our system, /usr/lib/cron is
just a symbolic link to /var/spool/at.)

> (I'm still not sure of the purpose though, since a user could always
> "nohup" anything that he can't "batch".)

I suppose it just makes it possible for cranky sysadmins to make it
slightly more difficult for users to create jobs that execute at
regular intervals...

--
John Eaton
jwe@emx.utexas.edu
Department of Chemical Engineering
The University of Texas at Austin
Austin, Texas  78712