Unix & Linux Asked by arturomp on November 26, 2020
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.
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)}[ 33[01;32m]u@h[ 33[00m]:[ 33[01;34m]w[ 33[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: wa]$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
Answered by arturomp on November 26, 2020
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP