2

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.

arturomp
  • 141
  • 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) –  Oct 09 '20 at 03:24

1 Answers1

2

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

arturomp
  • 141
  • 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. –  Oct 09 '20 at 04:50
  • @UncleBilly makes sense. what's the best practice in these cases for commands you need executed in non-interactive shells? – arturomp Oct 09 '20 at 05:00