I use Ubuntu 16.04 and try to execute directly on Bash:

sudo cat << EOF | at 'now + 1 minute'
echo "hello"

I get:

warning: commands will be executed using /bin/sh job 6 
at Wed Dec 28 03:01:00 2016
Can't signal atd (permission denied)

So, given there is no permission to run the command, the phrase hello won't be echoed on Bash.

If I use sudo, why would the permission be denied? Unlike cd which isn't a utility but a build-in shell command, at (as well as cat) are utilities hence sudo should apply them.

You might know why at can't be used?


TL;DR: Move sudo across the pipe (|) to the at command itself.

You haven't really been running at as root.

You ran cat as root (sudo cat ...), and piped the output of cat to at, but you did not run the at command itself as root.

On many systems, some non-root users are permitted to run at jobs. However, if that's not what you want, your system is configured the way you like, and you intend to run this particular at job as root, then you can solve the problem by running at as root instead of cat. (Either way, you do not need to run cat as root in this situation.)

To do that, put sudo before at instead of cat:

cat << EOF | sudo at 'now + 1 minute'

Optional details:

Currently you have:

sudo cat << EOF | at 'now + 1 minute'
echo "hello"

That runs cat as root with sudo, passing echo "hello" to it (with here-document syntax). The cat command's standard output is piped to the command at 'now + 1 minute', which is not run as root. Therefore at attempts to schedule the job as the non-root user who ran it (you).

If you want the at job to run as root, you can fix this problem by changing it to:

cat << EOF | sudo at 'now + 1 minute'
echo "hello"

If you later configure a non-root user account that you're using to be permitted to run at jobs, then you would run neither command as root:

cat << EOF | at 'now + 1 minute'
echo "hello"
  • Hi Eliah. Now it seems to be okay. No errors. Yet, after a minute the phrase "hello" won't be printed on bash... I don't know why because in contrast, sleep 1m && echo "hello" will be printed just fine... – JohnDoea Dec 28 '16 at 1:42
  • 3
    @Benia Output from at jobs doesn't go to the terminal where you ran at. As far as at could know, that terminal might not be appropriate for such use (or not exist) at the time the command runs. Instead, the output is mailed to you. But in Ubuntu -- unlike Debian -- no mail transfer agent is set up by default, so you don't receive the output at all. Do you need standard output from at jobs to go to your terminal, or is this just for testing? Either way, do any of these answers help? – Eliah Kagan Dec 28 '16 at 1:50
  • Indeed, I need the stdout in the terminal (the one I type commands to when the timeout ends). Given I prefer not use cron for this, only the answer by Keith Reynolds seems in the direction of what I need, but I don't have much knowledge about printing output in such case and might be wrong. – JohnDoea Dec 28 '16 at 1:59
  • I would thank you dearly again Eliah if you would add a small appendix on the end of the answer about how to "pop" into the terminal, the stdout of the commands executed after at (even if the session was terminated from any reason). – JohnDoea Dec 28 '16 at 2:08
  • @Benia Regarding your comment about needing stdout in the terminal: Are you using this strictly as a way to make things happen in your terminal at a later time while using it interactively? Do you know that your terminal will be open and that you will want to receive the output on it? If so, then are you sure you need to use at? Is running a subshell as a background job with & -- (sleep 1m && echo "hello")& -- sufficient for your needs? (You could replace 1m with something like 5s for testing, of course.) – Eliah Kagan Dec 28 '16 at 2:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.