nigelm@ohm.york.ac.uk (Nigel Metheringham) (05/27/91)
Many thanks to all who replied to my earlier note on the at and batch commands in the system 5 universe not working correctly. We finally traced the problem, using a debug version of cron and about an hour and a half on the phone to MIPs doing some interactive debugging! The symptoms were that for any user other than root the at command apprently worked fine, but cron threw away the job rather than executing it. We found that the jobs entered into the at spool directory (/usr/spool/cron/atjobs) had the permissions set incorrectly when the user was not root. For root the permissions are:- % ls -l /usr/spool/cron/atjobs total 1 -r-Sr-Sr-- 1 root 616 May 27 09:04 675363600.a but for any other users the setuid/gid bits were not set - at least this happened on our machine, but on apprently identical machines at MIPs they did not see this. A piece of inspired guesswork lead us to suspect the kopt settings made in the startup scripts. We work in a BSD type environment, so we had uncommented all the settings for a BSD environment in /etc/init.d/set_kopts - the fatal setting is:- /etc/kopt set _riscos_group_parent 0 which causes the at command to leave off the setuid/gid bits on the spooled command file. We assume that cron then thinks that the command file is bogus and so deletes it - shame it doesn't log the event. MIPs are looking at a fix for the problem. Nigel. -- # Nigel Metheringham # EMail: nigelm@ohm.york.ac.uk # # System Administrator # Phone: +44 904 432374 # # Department of Electronics # Fax: +44 904 432335 # # University of York, Heslington, York, UK, YO1 5DD #