I have a script run from a non-privileged users' crontab that invokes some commands using sudo. Except it doesn't. The script runs fine but the sudo'ed commands silently fail.

  • The script runs perfectly from a shell as the user in question.

  • Sudo does not require a password. The user in question has (root) NOPASSWD: ALL access granted in /etc/sudoers.

  • Cron is running and executing the script. Adding a simple date > /tmp/log produces output at the right time.

  • It's not a permissions problem. Again the script does get executed, just not the sudo'ed commands.

  • It's not a path problem. Running env from inside the script being run shows the correct $PATH variable that includes the path to sudo. Running it using a full path doesn't help. The command being executed is being given the full path name.

  • Trying to capture the output of the sudo command including STDERR doesn't show anything useful. Adding sudo echo test 2>&1 > /tmp/log to the script produces a blank log.

  • The sudo binary itself executes fine and recognizes that it has permissions even when run from cron inside the script. Adding sudo -l > /tmp/log to the script produces the output:

    User ec2-user may run the following commands on this host:
    (root) NOPASSWD: ALL

Examining the exit code of the command using $? shows it is returning an error (exit code: 1), but no error seems to be produced. A command as simple as /usr/bin/sudo /bin/echo test returns the same error code.

What else could be going on?

This is a recently created virtual machine running the latest Amazon Linux AMI. The crontab belongs to the user ec2-user and the sudoers file is the distribution default.

  • 1
    I was going to talk about a solution but then I read The user in question has (root) NOPASSWD: ALL access granted in /etc/sudoers and my brain started screaming too loud to keep reading. – Shadur Sep 25 '12 at 12:05
  • @Shadur: Talk to the hand. That isn't my way of setting up a machine either, but these machines come this way out of the box. Even through the machine is yours, you don't get a root password, your key as the owner of the box goes into the ec2-user account which has (as noted) full sudo access. You don't get a password for ec2-user either unless you set one, it's a key only login. – Caleb Sep 25 '12 at 12:12
  • 1
    Then the first thing I'd recommend you do is set up a separate user with restricted sudo rights /only/ for the commands you need in the script and disabling their login ability completely. – Shadur Sep 25 '12 at 12:27
  • if you have root, and you want the cron job to run as root, then why put it in ec2-user's crontab? wouldn't root's crontab be more appropriate? or /etc/crontab? – cas Sep 25 '12 at 12:33
  • 1
    @Shadur: I would do that in a heartbeat if it was a desktop system or even a multi-use server that was ever going to get logged into, but honestly considering the entire system is instantiated, configured, run and administered through a one time setup script and then shut off, only to have a new one launched using the same script, I don't think it makes a dime of difference whether whether I isolate the cron job from the admin user or not. – Caleb Sep 25 '12 at 12:41

sudo has some special options in its permissions file, one of which allows a restriction on its usage to shells that are are running inside a TTY, which cron is not.

Some distros including the Amazon Linux AMI have this enabled by default. The /etc/sudoers file will look something like this:

# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
#         You have to run "ssh -t hostname sudo <cmd>".
Defaults    requiretty

# Refuse to run if unable to disable echo on the tty. This setting should also be
# changed in order to be able to use sudo without a tty. See requiretty above.
Defaults   !visiblepw

If you had captured output to STDERR at the level of the shell script rather than the sudo command itself, you would have seem a message something like this:

sorry, you must have a tty to run sudo

The solution is to allow sudo to execute in non TTY environments either by removing or commenting out these options:

#Defaults    requiretty
#Defaults   !visiblepw
  • 1
    I can confirm that CentOS does have these restrictions in place. – aeu Aug 12 '19 at 19:31
  • It looks like requiretty was added in CentOS 7, so while this wasn't required with CentOS 6, it is with CentOS 7+. In my experience, sudo commands from the cron work on CentOS 6 even if the Defaults !visiblepw is turned on/not commented out. – kevinmicke Dec 3 '19 at 19:09

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.