1

With both

SHELL=/bin/bash
BASH_ENV=/home/ubuntu/.bashrc

set on AWS Ubuntu 20.04.1 LTS crontab, .bashrc isn't sourced. I ran into this with the error /bin/bash: python: command not found. python is only available within an environment whose command is made available in .bashrc. In my cronjob, I activate the environment and then I call python. (As I debugged, I realized the environment wasn't being activated, either, confirming the fact that .bashrc wasn't being read.)

I've made sure with ps -p $$ that SHELL=/bin/bash is actually running bash instead of what would be sh (given that BASH_ENV is not effective in sh). I also made sure that the BASH_ENV variable is properly set by running echo $BASH_ENV in one of the cronjobs. It's just not being sourced.

I've run these exact same cronjobs in crontab an another, non-AWS machine and they worked fine. I've already reviewed many related questions (1, 2, 3, 4), but everything that I've done seems according to expectations.

Another thing I tried in the AWS machine is to invert the order of SHELL and BASH_ENV with no results:

BASH_ENV=/home/ubuntu/.bashrc
SHELL=/bin/bash

I know I can source .bashrc before every cronjob. I'd rather set it up once to avoid mistakes due to individual-cronjob editing in the future and because I'd rather edit one single line than however many cronjobs in the future if I have to set this up in another machine as well. At the same time, I did try prepending source ~/.bashrc, source /home/ubuntu/.bashrc, . ~/.bashrc and . /home/ubuntu/.bashrc and they didn't have the desired effect.

  • I suggest you debug it by adding a xargs -0 echo </proc/$$/cmdline; realpath /proc/$$/exe; set command to your crontab, and checking its output. Keep in mind that bash will ignore BASH_ENV when it's called as sh (i.e. its first argument is sh or -sh) – user414777 Oct 9 '20 at 3:24
0

Figured out that the AWS ~/.bashrc file has the following code at the start, which doesn't run the rest of ~/.bashrc script if the shell is not interactive (and cronjobs use non-interactive shells):

# If not running interactively, don't do anything
case $- in
   *i*) ;;
     *) return;;
esac

Should've read the whole preexisting AWS ~/.bashrc file before using it. As Uncle Billy mentioned in the comments, some distributions have this

in order to avoid loading all the interactive stuff (completion, functions, aliases) when the .bashrc is sourced when bash is executed to run a non-interactive command via ssh.

Given my previous experiences, it made the usual (maybe not best) practice of just appending commands to ~/.bashrc confusing.

It's unclear to me if the rest of the file may have adverse effects for non-interactive shells, but I don't think it would add too much overhead. This is the original content of the ~/.bashrc file:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
    # We have color support; assume it's compliant with Ecma-48
    # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
    # a case would tend to support setf rather than setaf.)
    color_prompt=yes
    else
    color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands.  Use like so:
#   sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi
  • 1
    That's not only an AWS thing. The .bashrc of most distros is like that, in order to avoid loading all the interactive stuff (completion, functions, aliases) when the .bashrc is sourced when bash is executed to run a non-interactive command via ssh. – Uncle Billy Oct 9 '20 at 4:50
  • @UncleBilly makes sense. what's the best practice in these cases for commands you need executed in non-interactive shells? – arturomp Oct 9 '20 at 5:00

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.