locale.conf causes bash infinite nesting [Solved]

wpkzz · 2020-04-01 22:43:32

Okey, so, long story short: I made a locale.conf to set up my keyboard and primary languagues as Spanish. The contest of the file are as follows:

LANG="es_ES.UTF-8"
LC_ALL="es_ES.UTF-8"
LC_COLLATE="C"
LC_TIME="es_ES.UTF-8"

Everytime i log in bash complains that the permissions are wrong. The permissions of the file are:

-rw-r--r-- 1 root root 385 mar 30 16:23 locale.conf

So, experimenting, I did a

 chmod a+rwx

on the file, and next time I logg in,
bash enters a infinite nesting, and it reaches "level to high (1000)" error, and then gets stuck until it cannot do anything else,
efectively blocking the system.
My question is twofold:
1) What are the right permissions on locale.conf, or bash, to be able to use such a config file?
2) What causes locale.conf to produce an infinite nesting on the bash execution, as user or also as root?

The second one is the one that intrigues me the most.

Thanks,
wpkzz

Last edited by wpkzz (2020-04-28 15:52:15)

seth · 2020-04-02 07:22:10

/etc/locale.conf is typically 644, I'm not aware of bash testing its permissions and setting it 777 doesn't get me some loop either.

I assume the cause is rather in some sourced script or your ~/.bashrc, ~/.bash_profile or ~/.bash_login or ~/.profile
locale.conf is usually (supposingly: only) sourced by /etc/profile.d/locale.sh which is provided by https://www.archlinux.org/packages/core … ilesystem/ and doesn't test permissions etc.

You can "set -x" at the top of ~/.bashrc and (if present) ~/.bash_profile to monitor what's going on (nb. that the next intance of bash will print a lot of debug text)

wpkzz · 2020-04-02 16:37:40

Well, /etc/locale.conf is 644 and that is when bash complaints on the first instance, after logging in. My .bash_profile only contains the next line:

[[ -f ~/.bashrc ]] && . ~/.bashrc

My .bashrc is a bit longer, but it is mostly alias and some colors for the shell:

# Test for an interactive shell.  There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
	# Shell is non-interactive.  Be done now!
	return
fi


# Put your fun stuff here.

PATH=$PATH:./:/home/karel/bashscripts:/home/karel/MachotesParaTudo:
export PATH

export BROWSER='/usr/bin/firefox'

PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \W \$\[\033[00m\] "
export PS1


alias emc='emacsclient -c' 
alias emt='emacsclient -t'
alias ipnb='ipython notebook'
alias jprn='jupyter notebook'
alias ls='ls --color=auto'

fortune | cowsay

man() {
    LESS_TERMCAP_md=$'\e[01;31m' \
    LESS_TERMCAP_me=$'\e[0m' \
    LESS_TERMCAP_se=$'\e[0m' \
    LESS_TERMCAP_so=$'\e[01;44;33m' \
    LESS_TERMCAP_ue=$'\e[0m' \
    LESS_TERMCAP_us=$'\e[01;32m' \
    command man "$@"
}

I do not see how this could get into the locale.conf and make it an infinite nesting of bashes...

jasonwryan · 2020-04-02 18:40:14

Your PATH invocation is broken: the first sourced dir is (./). And why is it in your .bashrc and not .profile or .bash_profile?

seth · 2020-04-02 20:52:52

You should™ not source bashrc in bash_profile.
Since those files do not explain the hassle w/ locale.conf, what about the other profile scripts (/etc/profile*, ~/.profile)?

What happens if you run "bash --noprofile" and from there source the scripts in /etc/profile.d/ ?

wpkzz · 2020-04-04 05:10:08

Why shouldn't I source bashrc in bash_profile? I have had that configuration lagging from other times before Arch, and actually ( I didn't write it ) the ~/.bash_profile starts with this comment:

# /etc/skel/.bash_profile
# This file is sourced by bash for login shells.  The following line
# runs your .bashrc and is recommended by the bash info pages.
[[ -f ~/.bashrc ]] && . ~/.bashrc

I do not have a ~/.profile file.
The general /etc/profile is as follows:

# /etc/profile

# Set our umask
umask 022

# Append our default paths
appendpath () {
    case ":$PATH:" in
        *:"$1":*)
            ;;
        *)
            PATH="${PATH:+$PATH:}$1"
    esac
}

appendpath '/usr/local/sbin'
appendpath '/usr/local/bin'
appendpath '/usr/bin'
unset appendpath

export PATH

# Load profiles from /etc/profile.d
if test -d /etc/profile.d/; then
	for profile in /etc/profile.d/*.sh; do
		test -r "$profile" && . "$profile"
	done
	unset profile
fi

# Source global bash config
if test "$PS1" && test "$BASH" && test -z ${POSIXLY_CORRECT+x} && test -r /etc/bash.bashrc; then
	. /etc/bash.bashrc
fi

# Termcap is outdated, old, and crusty, kill it.
unset TERMCAP

# Man is much better than us at figuring this out
unset MANPATH

As for the PATH variable in my .bashrc, I did set that way. ¿Why is broken? I actually like it when bash searches for a command first in the working directory. It helps me with my work scripts. ¿Is that wrong? ¿What are the risks of declaring the actual directoy as PATH ? Also, ¿is it wrong to set such things in .bashrc instead of .bash_profile and why?

seth · 2020-04-04 06:40:55

/etc/profile is stock and before we go over the pros and cons of either sourcing rc files in login shells or adding "." to the $PATH, we're still missing out on /etc/profile.d scripts

Everytime i log in bash complains that the permissions are wrong.

Also please post the exact error message and specify whether this indeed only hold for login shells or also for subsequent bash intances (ie. when you run "bash" out of a running bash or just and xterm in a GUI shell)

The contest of the file are as follows

Also upload the actual file somewhere, in case there's stray control chars in it or whatever.

eschwartz · 2020-04-05 05:29:24

seth wrote:

/etc/profile is stock and before we go over the pros and cons of either sourcing rc files in login shells or adding "." to the $PATH, we're still missing out on /etc/profile.d scripts

Actually, we should just avoid throwing in completely random red herrings, since you are absolutely supposed to source .bashrc in .bash_profile -- but not the other way around. The one time when .bash_profile is read, .bashrc *isn't* read, and therefore if you do not source .bashrc from .bash_profile, your initial interactive shell will be missing basically your entire user configuration (all except the things which you define to set once at login, and never again -- which is generally only your $PATH manipulation).

wpkzz wrote:

As for the PATH variable in my .bashrc, I did set that way. ¿Why is broken? I actually like it when bash searches for a command first in the working directory. It helps me with my work scripts. ¿Is that wrong? ¿What are the risks of declaring the actual directoy as PATH ? Also, ¿is it wrong to set such things in .bashrc instead of .bash_profile and why?

It's considered exceedingly bad practice, and you're not supposed to want this. Programs which set such a PATH as part of their runtime are considered to have huge security holes.

Imagine if you clone some github repository to look at it, then cd into the repo and run `ls` inside it. If there is a script called "ls" in the repo, it will be executed instead of /bin/ls, and that script may do anything it wants, most likely something you didn't intend. Running scripts from the current directory should *never* be done unless explicitly specified as `./ls`.

Is it that hard to run work scripts as `./scriptname.sh` instead of `scriptname.sh`?

...

As for the actual issue, I note you still have not tried the suggestion to add `set -x` and see where in the shell initialization it complains about file permissions. Please do so.

Also you may be able to duplicate the issue without logging out and in, by just running bash as such:

bash -x --login

seth · 2020-04-05 07:24:52

we should just avoid throwing in completely random red herrings

I don't think that I suggested a relation to the issue at hand at any point. Sorry if some statements were misunderstandable or misleading.

you are absolutely supposed to source .bashrc in .bash_profile

I don't want to lead this discussion here, but well…

You're pointing out correctly the only situation where this might be relevant anyway.
The point is that the *vast* majority of users will not face this condition ever (because bash isn't their login shell, they run VTEs in a graphical environment)
As this thread illustrates, it's however perfectly possible to screw your bashrc with fancyness to the degree where it essentially breaks the usage of bash - at which point you might face the requirement to log into a non-graphical session to get a working shell to fix stuff…

It's a risk/reward thing and while certainly justified æons ago, when an interactive login bash was the regular case, the ratio has drastically flipped nowadays.
But I'm happy to hear arguments for the other side, so change my mind.
(We might need a mod to cut this off)

eschwartz · 2020-04-05 15:53:36

seth wrote:

You're pointing out correctly the only situation where this might be relevant anyway.
The point is that the *vast* majority of users will not face this condition ever (because bash isn't their login shell, they run VTEs in a graphical environment)

If they don't run an interactive login shell, what is the problem? As quoted (and in the stock /etc/skel/.bashrc shipped by core/bash and any other distro's skeleton files):

# Test for an interactive shell.  There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
	# Shell is non-interactive.  Be done now!
	return
fi

Though Arch's stock version is more succinct:

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

seth wrote:

As this thread illustrates, it's however perfectly possible to screw your bashrc with fancyness to the degree where it essentially breaks the usage of bash - at which point you might face the requirement to log into a non-graphical session to get a working shell to fix stuff…
It's a risk/reward thing and while certainly justified æons ago, when an interactive login bash was the regular case, the ratio has drastically flipped nowadays.
But I'm happy to hear arguments for the other side, so change my mind.
(We might need a mod to cut this off)

The risk here is that any possible circumstance where you'd want to login to a shell, including ssh or the tty, you would need to `exec bash` in order to get anything done.

The reward is nonexistent. Attempted login to a graphical session would actually be the thing which works, not the thing which doesn't work, since .bashrc would return early, and you could open a shell by configuring your probably-vte terminal to use a different (non-bash) interpreter such as /bin/sh, or use ALT+F2 to execute a command line such as `$terminal -e 'bash --noprofile --norc'`, or login as root or another debug user.

All this shooting yourself in the foot only to not even solve the problem, where the problem only manifests in the pretty unlikely case your .bashrc is so broken you cannot even start a shell, seems very unjustified to me.

Most importantly, you went and said "You should™ not source bashrc in bash_profile." without any details whatsoever, going against well-established practice without any rationale, acting as though it were common knowledge why one should not do so. Even if I didn't disagree with your entire premise from beginning to end, I would have an issue with the way you said it. Of such things is cargo-culting born.

wpkzz · 2020-04-06 17:53:21

Thanks team: here are the develpments so far:
The message at login is as follows:

Last login: Sun Apr 5 11:50:27 on tty1
-bash: /etc/locale.conf: Permission denied

Okey, eschwartz, I guess that I trust too much what I could unzip from anyplace, but you are right: I just took of that "./" PATH outta my PATH.

As for running

bash -x --login

that doesn't give me the error.
So it seems me that it is only the logging in where the problem arises. Curiously, I do have the LANG and keyboard right anyway.
On the other side, I do know a lot of people who like to use bash or fish as logging shells, mostly arch-ers or gentoo-ers.
I even read about one guy who used Julia as shell interpreter and another who used emacs...

Last edited by wpkzz (2020-04-06 17:53:56)

seth · 2020-04-08 13:04:03

Do you use some sort of autologin?
Do you get the error for "bash -lxi"?
Also the "-x" invocation should™ get you a bunch of debug output. Sure you didn't just miss the error in that wall of text?

What most likely happes is that something™ tries to execute the file.
The error probably doesn't disappear for "chmod a+rw /etc/locale.conf" ?
This can easily happen if ". /etc/locale.conf" turned into "/etc/locale.conf"

wpkzz · 2020-04-11 01:46:28

Thanks for the Patiente:

No, i do not use some sort™ of autologin. No, I do not get the error with "bash -lxi". I copied the text to a file, cat and grep it and it did not appear.
It just appears on first login.
When I "chmod a+rw /etc/locale.conf" then is when it gets WORSE. That is what I described on the first post: the infinite loop nesting bashes.

Sorry, what is "-x"... I do not see it on the man pages...

Last edited by wpkzz (2020-04-11 01:49:57)

seth · 2020-04-11 05:47:13

When I "chmod a+rw /etc/locale.conf" then is when it gets WORSE. That is what I described on the first post: the infinite loop nesting bashes.

OP wrote:

So, experimenting, I did a
chmod a+rwx
on the file, and next time I logg in, bash enters a infinite nesting

"chmod a+rwx" sets the file [r]eadable, [w]ritable and e[x]ecutable to [a]ll (you can actually omit that) which is why you shall free r/w access but not allow execution to see whether the execution bit is the crucial element that causes the nesting and also leads to the original permission error (because something™ tries to execute the file)

"bash -x" turns the debugging mode on, just running "bash -x" should already produce quite some output leading "+ "

wpkzz · 2020-04-15 00:23:29

Thanks for the explanations, seth. The file, both in "-rw-rw-rw-" and in "-rw-r--r--" modes causes the permission problem. If it has a "x" executable, then it produces the infinite nesting of bashes problem. Ah, I just tested it logging in as root, and also for root gives the problem... it seems that bash, and bash itself, is the one who has permission problems...

Last edited by wpkzz (2020-04-15 00:24:25)

seth · 2020-04-15 05:53:34

Bash doesn't have a permission problem. It means some of the global scripts tries to execute the file.
Add "set -x" at the top of /etc/profile (but below the shebang) and provoke the error message (root login) to see what context generates it.

You're not supposed to execute that file at all and it will cause the execution of another bas instance (as interpreter) which in this context and under the same conditions that causes the first execution will execute locale.conf again which will call another bash interpreter under the same conditions which will … hence the infinite nesting.

wpkzz · 2020-04-17 01:51:28

Okey yeah, a lot of output and if there was a warning or error I couldn't see it. I have to remember how to scroll in tty1 or redirect the output so that it gets into a file. But on first inspection I do not seem to have seen the error. On a curious but irrelated note, (trying to scroll) i discovered that CTRL+ALT+PGDOWN produces my computer to restart outside X11...is that normal?

seth · 2020-04-17 06:05:49

Sure you didn't hit ctrl+alt+del?
It's [ctrl+]shift+pgup/down.

Make it

exec 2>>/tmp/weird_login_error.log
set -x

to redirect errors into a file on /tmp that you can then inspect and grep later.

wpkzz · 2020-04-17 16:16:38

Oh, yeah... I tried something similar but I guess my sintaxis was not right. First, I discovered that framebuffer scrolling was disabled, so I set it to 32k.
I can scroll now with shift and pgup/down but it still not enough to catch the error. Then I read a sugestion similar to what you told me but slightly different. I read that I can
separate debug from error messages with

BASH_XTRACEFD=3

,
so I put these lines in /etc/profile

set -x
BASH_XTRACEFD=3

and at the end of the file

exec 3>/tmp/bashinit.log

but that just creates an empty file.
So, it seems that I have to put it before the "set -x", no?
I'll try it that way, both with "3" and "2" out-variables.

Thanks seth.

wpkzz · 2020-04-22 16:25:38

Okey, I modified the /etc/profile to the order that seth suggested, and it got very bad. BASH_XTRACEFD=3 complaints that it is an invalid code. That is for starting. And then the prompt doesn't appear. It just hangs in blank. No messages, no anything. I discovered that to get around it, I had to log in in certain tty, and then in another log in as another user. As an example, I log in as myself in tty1, and as root in tty2. Then the second login complaints that /tmp/bashinit.log and /tmp/basherror.log are locked by use by my user, and then it goes to display the prompt. The other is still hanging, and the files in question never appear. So it still being weirldy annoying but not disfunctional.

seth · 2020-04-22 20:45:48

I don't think I suggested BASH_XTRACEFD…

exec 3>/tmp/bashinit.log
BASH_XTRACEFD=3
set -x

Should™ work, though.
Everything else rather not (esp. not if exec 3… is the last command)

wpkzz · 2020-04-26 02:19:26

Well, I managed to do that, but it was a bad idea, since the error gets in a separate file and is out of context. Is better to have all messages in the same file. Anyhow I discovered that the hanging is a normal reaction when you direct all output to other files, so I still had to make the following circus: log as myself, wait until it gets hang, go to another tty, log as root, then *move* the files to another directory, since tmp gets erased at reboot, and then reedit /etc/profile, and then log in again, get to the forums, and post.
So, I cannot make who the culprit is, I inspected the files with less and my eyes, and the cause still seems to be hidden. The relevant parts I think, are the next lines:

+ for profile in /etc/profile.d/*.sh
+ test -r /etc/profile.d/locale.sh
+ . /etc/profile.d/locale.sh
++ '[' -z '' ']'
++ '[' -n '' ']'
++ '[' -n /home/karel ']'
++ '[' -r /home/karel/.config/locale.conf ']'
++ '[' -r /etc/locale.conf ']'
++ . /etc/locale.conf
+++ /etc/locale.conf
-bash: /etc/locale.conf: Permission denied
+++ LANG=es_ES.UTF-8
+++ LC_ALL=es_ES.UTF-8
+++ LC_COLLATE=C
+++ LC_TIME=es_ES.UTF-8
++ LANG=es_ES.UTF-8
++ export LANG LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION

The error line is marked with the minus or dash.
The file /etc/profile/locale.sh does exist, but the /home/karel/.config/locale.conf doesn't.
The languagues are correctly set, those are the ones that I like.

Thanks for the patiente,

eschwartz · 2020-04-26 04:41:46

++ . /etc/locale.conf
+++ /etc/locale.conf
-bash: /etc/locale.conf: Permission denied

I may be missing something here, but... did anyone ever ask you what are the contents of the file /etc/locale.conf ?

An infinite nesting error implies that something is trying to run itself, which should point the finger at /etc/locale.conf itself, because it is the thing being run and therefore it itself might logically be trying to recursively execute itself.

Now, here's the thing: profile.d will try to *source* this file, sourcing does not check for chmod +x permissions and only tries, once, to read the value of various LANG or LC_* variables from there. This is what I expect to see in such context:

$ set -x; . /etc/locale.conf
+ set -x
+ . /etc/locale.conf
++ LANG=en_US.UTF-8

One plus sign indicates I am in the toplevel context of the bash interpreter (not a script in my case, manually typed commands). The first toplevel context it does is set -x; the second toplevel context is sourcing /etc/locale.conf, at this point it switches to two plus signs, and displays logging for things happening in the /etc/locale.conf context, which is one thing and that thing is setting LANG.

In your case, after entering the "source the /etc/locale.conf" context, the first thing it tries to do is *execute* /etc/locale.conf, and get a permission denied.

$ /etc/locale.conf
+ /etc/locale.conf
bash: /etc/locale.conf: Permission denied

So, I would expect exactly this outcome if the contents of the file /etc/locale.conf are "/etc/locale.conf".

Of course, if the file is executable, then you get very odd issues.

Have you at some point done something like (as root):

# echo "/etc/locale.conf" > /etc/locale.conf

Last edited by eschwartz (2020-04-26 06:38:07)

seth · 2020-04-26 06:13:44

The initial post has

I made a locale.conf to set up my keyboard and primary languagues as Spanish. The contest of the file are as follows:
LANG="es_ES.UTF-8"
LC_ALL="es_ES.UTF-8"
LC_COLLATE="C"
LC_TIME="es_ES.UTF-8"

Though the error log indeed *strongly* suggests that this isn't true and that the file simply heads its uncommented path…

eschwartz · 2020-04-26 06:42:55

Oh... indeed...

Specifically, the logged xtrace output is:

++ . /etc/locale.conf
+++ /etc/locale.conf
-bash: /etc/locale.conf: Permission denied
+++ LANG=es_ES.UTF-8
+++ LC_ALL=es_ES.UTF-8
+++ LC_COLLATE=C
+++ LC_TIME=es_ES.UTF-8

So I'm guessing the filename itself got prepended and the OP looked at the file with e.g. `cat` and completely ignored the first line which didn't match their expectations. Some mental filtering was probably involved. Actually posting the command plus output in the form:

$ command
some output
more output

instead of being clever and only posting the output itself, would have revealed this. I do not understand why this pervasive problem exists, whenever anyone asks for help they always try to be clever and only show the output *they* think is needed.

Arch Linux

#1 2020-04-01 22:43:32

locale.conf causes bash infinite nesting [Solved]

#2 2020-04-02 07:22:10

Re: locale.conf causes bash infinite nesting [Solved]

#3 2020-04-02 16:37:40

Re: locale.conf causes bash infinite nesting [Solved]

#4 2020-04-02 18:40:14

Re: locale.conf causes bash infinite nesting [Solved]

#5 2020-04-02 20:52:52

Re: locale.conf causes bash infinite nesting [Solved]

#6 2020-04-04 05:10:08

Re: locale.conf causes bash infinite nesting [Solved]

#7 2020-04-04 06:40:55

Re: locale.conf causes bash infinite nesting [Solved]

#8 2020-04-05 05:29:24

Re: locale.conf causes bash infinite nesting [Solved]

#9 2020-04-05 07:24:52

Re: locale.conf causes bash infinite nesting [Solved]

#10 2020-04-05 15:53:36

Re: locale.conf causes bash infinite nesting [Solved]

#11 2020-04-06 17:53:21

Re: locale.conf causes bash infinite nesting [Solved]

#12 2020-04-08 13:04:03

Re: locale.conf causes bash infinite nesting [Solved]

#13 2020-04-11 01:46:28

Re: locale.conf causes bash infinite nesting [Solved]

#14 2020-04-11 05:47:13

Re: locale.conf causes bash infinite nesting [Solved]

#15 2020-04-15 00:23:29

Re: locale.conf causes bash infinite nesting [Solved]

#16 2020-04-15 05:53:34

Re: locale.conf causes bash infinite nesting [Solved]

#17 2020-04-17 01:51:28

Re: locale.conf causes bash infinite nesting [Solved]

#18 2020-04-17 06:05:49

Re: locale.conf causes bash infinite nesting [Solved]

#19 2020-04-17 16:16:38

Re: locale.conf causes bash infinite nesting [Solved]

#20 2020-04-22 16:25:38

Re: locale.conf causes bash infinite nesting [Solved]

#21 2020-04-22 20:45:48

Re: locale.conf causes bash infinite nesting [Solved]

#22 2020-04-26 02:19:26

Re: locale.conf causes bash infinite nesting [Solved]

#23 2020-04-26 04:41:46

Re: locale.conf causes bash infinite nesting [Solved]

#24 2020-04-26 06:13:44

Re: locale.conf causes bash infinite nesting [Solved]

#25 2020-04-26 06:42:55

Re: locale.conf causes bash infinite nesting [Solved]

Board footer