wtm@uhura.neoucom.EDU (Bill Mayhew) (06/05/90)
Hi. I can't get at(1) to work correctly for regular users on my system which is running Sys V 3.2.1. Root seems to be able to submit at jobs. I checked permissions on the files in /usr/lib/cron, and everything seems fine. I have no at.allow file, and the size of at.deny is zero. at(1) builds files in /usr/spool/cron/atjobs with permissions of -r-Sr-lr--. That seems to agree the permissions set by our HP System 9000 running HP/UX. The user sumbitted at jobs fail with diagnostic mail sent to the user complaining "bad ulimit". If the at job runs after the user has logged out, the mail appears to come from LOGIN instead of teh user. Anybody know a fix or workaround? ==Bill== -- Bill Mayhew Northeastern Ohio Universities College of Medicine Rootstown, OH 44272-9995 USA 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm
oc@vmp.com (Orlan Cannon) (06/05/90)
In article <1990Jun05.021452.22612@uhura.neoucom.EDU>, wtm@uhura.neoucom.EDU (Bill Mayhew) writes: > > The user sumbitted at jobs fail with diagnostic mail sent to the > user complaining "bad ulimit". What happens here is that "at" jobs are run by "cron". And cron is running with the ulimit that was in effect when cron was started, probably at system boot time. When you create an "at" job, it builds a file that includes your environment and other things, such as your ulimit. If your ulimit is higher than cron's, it will fail. The answer is to put a higher ulimit into effect in your bootup script before it starts cron. As to why the default ulimit is so low... that's another story entirely... -- Orlan Cannon oc@vmp.com Video Marketing & Publications, Inc. ...!uunet!vmp!oc Oradell, NJ 07649 (800) 627-4551