Description of problem: The problem could be demonstrated by the following program running by root. useradd -m foo echo foo >/etc/at.allow cat <<EOF >/home/foo/at #!/bin/sh echo "echo bar >/tmp/bar" | at now EOF chmod 777 /home/foo/at su foo -c /home/foo/at ls -l /tmp/bar At does not schedule the job, and it is confusing that at does not show any warning or error message. ls: cannot access /tmp/bar: No such file or directory It has the same problem with sudo. It works with a login shell. su foo -l -c /home/foo/at Version-Release number of selected component (if applicable): at-3.1.10-25.fc10.x86_64 How reproducible: always Steps to Reproduce: See above. Actual results: ls: cannot access /tmp/bar: No such file or directory Expected results: /tmp/bar exists.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The job is in queue and it is scheduled. In foo's mail you can find failure of job. The error message is quite abstract, but I suppose this is correct shell behaviour. foo doesn't have environment settings, so it can't run the command. After '-l' is used, than some enviroment variables for user are set.