[solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

orschiro · 2013-11-01 21:07:07

Hello there,

I have this very weird issue which apparently not many user encounter. At least I could not find any information about it.

My logs always show the following entry:

thinkpad systemd[1]: Ignoring invalid environment 'export LC_ALL=en_US.utf8': /opt/crashplan/bin/run.conf

What does cause the issue and what does it exactly mean?

It seems not be a problem of Crashplan itself since I am the only user of Crashplan experiencing this. So the problem must be on my system. However, I cannot figure out what is wrong with my locale settings. LC_ALL is not even set. Thus I cannot say where this export LC_ALL command comes from.

~ $ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME=de_DE.UTF-8
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Any ideas?

Last edited by orschiro (2014-01-15 15:06:13)

alphaniner · 2013-11-01 21:15:53

If nothing else:

find ~ /etc -type f -exec grep -Il "LC_ALL" {} \; 2>/dev/null

orschiro · 2013-11-01 21:18:46

Thanks. What does it do?

skottish · 2013-11-01 21:19:41

Accoring to the AUR page, you added it to your .bashrc.

orschiro · 2013-11-01 21:21:10

@skottish

True. Sorry I forgot to mention that. This proved to have been working but isn't any longer for whatever reasons.

But more important, what does this error essentially mean?

Last edited by orschiro (2013-11-01 21:21:37)

alphaniner · 2013-11-01 21:22:35

Are you unfamiliar with find and grep, or just lazy?

It searches all non-binary files in ~ and /etc for the string "LC_ALL".

jasonwryan · 2013-11-01 21:25:35

alphaniner wrote:

Are you unfamiliar with find and grep, or just lazy?

The latter. He has a long history of this sort of thing. Obviously, the last ban has worn off...

orschiro · 2013-11-01 21:31:06

alphaniner wrote:

Are you unfamiliar with find and grep, or just lazy?
It searches all non-binary files in ~ and /etc for the string "LC_ALL".

Just a bit irritated about the /dev/null part. I was afraid to delete something without knowing actually what.

[root@thinkpad ~]# find ~ /etc -type f -exec grep -Il "LC_ALL" {} \; 2>/dev/null
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxml2/2.8.0/libxml2-2.8.0/install-sh
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxml2/2.8.0/libxml2-2.8.0/config.status
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxml2/2.8.0/libxml2-2.8.0/libtool
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxml2/2.8.0/libxml2-2.8.0/configure
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxml2/2.8.0/libxml2-2.8.0/ChangeLog
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxml2/2.8.0/libxml2-2.8.0/ltmain.sh
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxslt/1.1.26/libxslt-1.1.26/config.guess
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxslt/1.1.26/libxslt-1.1.26/install-sh
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxslt/1.1.26/libxslt-1.1.26/config.status
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxslt/1.1.26/libxslt-1.1.26/libtool
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxslt/1.1.26/libxslt-1.1.26/configure
/root/.gem/ruby/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/tmp/x86_64-unknown-linux-gnu/ports/libxslt/1.1.26/libxslt-1.1.26/ltmain.sh
/root/.gem/ruby/2.0.0/gems/pygments.rb-0.5.2/vendor/pygments-main/tests/examplefiles/Makefile
/root/.gem/ruby/2.0.0/gems/pygments.rb-0.5.2/vendor/pygments-main/tests/examplefiles/ltmain.sh
/root/.gem/ruby/2.0.0/gems/pygments.rb-0.5.2/vendor/pygments-main/pygments/lexers/compiled.py
/etc/.git/hooks/pre-commit.sample
/etc/rc.d/crashplan

That was insightful. So essentially it comes from here I guess:

[root@thinkpad ~]# cat /etc/rc.d/crashplan 
#!/usr/bin/env bash

. /etc/rc.conf
. /etc/rc.d/functions

if [[ -f /etc/profile.d/jre.sh ]]; then
    . /etc/profile.d/jre.sh
elif [[ -f /etc/profile.d/openjdk6.sh ]]; then
    . /etc/profile.d/openjdk6.sh
fi

WD=/opt/crashplan
CRASHPLAN=$WD/bin/CrashPlanEngine
VARS=$WD/install.vars
CONFIG=$WD/bin/run.conf

test -f $VARS || exit 0
test -f $CONFIG || exit 0
test -f $CRASHPLAN || exit 0

. $VARS
. $CONFIG



if [[ ${LC_ALL} ]]; then
    LOCALE=`sed 's/\..*//g' <<< ${LC_ALL}`
    export LC_ALL="${LOCALE}.UTF-8"
elif [[ ${LC_CTYPE} ]]; then
    LOCALE=`sed 's/\..*//g' <<< ${LC_CTYPE}`
    export LC_CTYPE="${LOCALE}.UTF-8"
elif [[ ${LANG} ]]; then
    LOCALE=`sed 's/\..*//g' <<< ${LANG}`
    export LANG="${LOCALE}.UTF-8"
else
    export LANG="en_US.UTF-8"
fi

[[ `$CRASHPLAN status` != "CrashPlan Engine is stopped." ]] && PID=`$CRASHPLAN status | sed -r 's/CrashPlan Engine \(pid ([0-9]+)\).*/\1/'`

case "$1" in
    start)
	stat_busy "Starting CrashPlan Engine"
	PWD=`pwd`
	cd $WD
	[[ -z "$PID" ]] && nice -n 19 $CRASHPLAN start > /dev/null
	if [ $? -gt 0 ]; then
	    stat_fail
	else
	    add_daemon crashplan
	    stat_done
	fi
	cd $PWD
	;;
    stop)
	stat_busy "Stopping CrashPlan Engine"
	[[ ! -z "&PID" ]] && $CRASHPLAN stop &> /dev/null
	if [ $? -gt 0 ]; then
	    stat_fail
	else
	    rm_daemon crashplan
	    stat_done
	fi
	;;
    restart)
	$0 stop
	sleep 1
	$0 start
	;;
    status)
	$CRASHPLAN status
	;;
    *)
	echo "Usage: $0 <start|stop|restart|status>" >&2
	exit 3
	;;
esac

But why do only I have this error message then?

The latter. He has a long history of this sort of thing. Obviously, the last ban has warn off...

I don't agree with you for all my problems but this time I see your point. I could have done search on how both commands work together and whether the result will be harmful or not. I apologise for that and acknowledge my part-time laziness!

Last edited by orschiro (2013-11-01 21:36:38)

orschiro · 2014-01-15 15:06:02

Solved by adding export LC_ALL=en_US.UTF-8 to my xinitrc for correcting the invalid environment setting.

Arch Linux

#1 2013-11-01 21:07:07

[solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

#2 2013-11-01 21:15:53

Re: [solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

#3 2013-11-01 21:18:46

Re: [solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

#4 2013-11-01 21:19:41

Re: [solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

#5 2013-11-01 21:21:10

Re: [solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

#6 2013-11-01 21:22:35

Re: [solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

#7 2013-11-01 21:25:35

Re: [solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

#8 2013-11-01 21:31:06

Re: [solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

#9 2014-01-15 15:06:02

Re: [solved] Ignoring invalid environment 'export LC_ALL=en_US.utf8':

Board footer