tmorris@athena.sph.unc.edu (Thomas P. Morris) (06/27/90)
Hi. We have a DECsystem 3100 running Ultrix 3.1 (Rev. 14), and I've run into a problem with at, atrun, and batch. The atrun command is set up within /etc/crontab to be run every 5 minutes. Perusing the accounting with the 'lastcomm' command shows that atrun is indeed being run every 5 minutes. Jobs submitted via the batch command do not appear to be getting released. Load average on this machine almost =never= exceeds something like "load average: 1.05, 0.80, 0.20" or something like that, and is often something like "0.06, 0.00, 0.00". And =still= jobs submitted via 'batch' are not getting released. Does this sound familiar to anyone out there? Patches? Bug fixes? Thanks in advance. -------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health Internet: tmorris@athena.sph.unc.edu Computing and Information Services Internet: tom@zeus.sph.unc.edu --------------------------------------------------------------------------
jwe@ut-emx.UUCP (John W. Eaton) (06/28/90)
In article <439@beguine.UUCP> tmorris@athena.sph.unc.edu (Thomas P. Morris) writes: : We have a DECsystem 3100 running Ultrix 3.1 (Rev. 14), and : I've run into a problem with at, atrun, and batch. : : The atrun command is set up within /etc/crontab to be run every 5 : minutes. Perusing the accounting with the 'lastcomm' command shows : that atrun is indeed being run every 5 minutes. : Jobs submitted via the batch command do not appear to be getting : released. Load average on this machine [is small]. 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}. Apparently DEC wants you to be able control the use of this utility on a user by user basis, with the default set so that only root has access. -- John Eaton jwe@emx.utexas.edu Department of Chemical Engineering The University of Texas at Austin Austin, Texas 78712
diamond@tkou02.enet.dec.com (diamond@tkovoa) (06/28/90)
In article <32670@ut-emx.UUCP> jwe@emx.utexas.edu (John W. Eaton) writes: >In article <439@beguine.UUCP> tmorris@athena.sph.unc.edu >(Thomas P. Morris) writes: >: Jobs submitted via the batch command do not appear to be getting >: released. Load average on this machine [is small]. >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}. 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. This "feature" seems to work on the systems our group uses. (I'm still not sure of the purpose though, since a user could always "nohup" anything that he can't "batch".) The problem is that jobs in the batch/at queue do not get executed. Even when we use "at" instead of "batch", they don't get executed. The "atrun" command is more like an "atnoop". At least, this is the problem our group has. We don't have sources here. I plan to submit an SPR eventually. However, if anyone else knows the solution, I'd be glad to be corrected. -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com This is me speaking. If you want to hear the company speak, you need DECtalk.
tmorris@athena.sph.unc.edu (Thomas P. Morris) (06/28/90)
In my original posting, I wrote: Jobs subsmitted via the batch command do not appear to be getting released. Load average on this machine [is small]. In article <32670@ut-emx.UUCP> jwe@emx.utexas.edu (John W. Eaton) writes: >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}. I should have mentioned in my original posting that I =have= an empty at.deny file, and do =not= have an at.allow file, which according to the man page will allow all accounts/users to use batch. Hmmmm. Maybe I ought to try to use the explicit at.allow entries. Anybody else have any suggestions? Thanks in Advance. Tom Morris
jwe@ut-emx.UUCP (John W. Eaton) (06/28/90)
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
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (06/28/90)
In article <1818@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >The problem is that jobs in the batch/at queue do not get executed. >Even when we use "at" instead of "batch", they don't get executed. >The "atrun" command is more like an "atnoop". Sounds like you're missing the "atrun" entry in crontab. Look at /etc/crontab...there should be an entry something like 0,15,30,45 * * * * /usr/lib/atrun If that's not there, then both at and batch will do nothing. at works fine for me on our DECstation 3100's. On the other hand, I just tried batch and it doesn't seem to be doing anything (I did remember to wait for atrun to run). -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University