Runnin chruby-exec as root in a cron job causes 'stdin: is not a tty' error mails to be sent

[64kramsystem]

I have an Ubuntu 14.04 Server system with chruby 0.3.9 set up, for two users - root and myuser. Both have the standard .bashrc and .profile; myuser has been created using adduser. On top of their respective .bashrc I've added source /usr/local/share/chruby/chruby.sh.

chruby-exec works as expected; when I use it to run scripts via cron though, while the scripts run fine, I get an error system mail with 'stdin: is not a tty'.

I've read the page https://github.com/postmodern/chruby/wiki/Cron, and my setup is as specified; the following is a sample of the crontab:

SHELL=/bin/bash
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/local/bin

  *     *     *     *     *      root    chruby-exec 1.9.3-p547 -- /tmp/test.rb      > /dev/null
  *     *     *     *     *      myuser  chruby-exec 1.9.3-p547 -- /tmp/test.rb      > /dev/null
  *     *     *     *     *      root    /tmp/test.rb      > /dev/null

And this is the /tmp/test.rb file content (it does nothing):

#!/usr/bin/env ruby

Only the first job causes the error mail to be sent. Interestingly, the second job (which runs as myuser) doesn't cause the error email to be sent.

Is this a bug, or I am missing something? The configuration changes are minimal (as specified), and the shell init files are the standard provided with the O/S.

[postmodern]

chruby-exec does try to determine if it's running in an interactive terminal. If it's working for myuser but not root, I'm going to guess that root has some special bash configuration, or myuser's error emails are going somewhere else.

A workaround solution would be to simply not use chruby in production. You almost NEVER need a ruby switcher in production.

[skull-squadron]

The issue is running a interactive profile without a tty.

Either:

1. Change startup scripts to not run interactive things, i.e., mesg n. Quick hack: mesg n 2>/dev/null
2. (Might/not work) Modify chruby-exe to run $SHELL -l instead of $SHELL -i

Problem solved.

For production, use packages&|(chef|puppet) or perhaps something like habitat or GNU stow as per postmodern.