Seems you have something broken in the sequence of scripts which run when logging in; specifically one which calls sed
You could either debug your .bashrc and .bash_profile scripts (and anything else that gets called by them) to try to locate where /usr/bin/sed is being called and correct it (and it may well be off in some other script elsewhere on your system - not necessarily within ~), or you could try changing your default login shell to something other than bash, so that those bash scripts are not called and you at least get the ability to log into the desktop, whereupon you have a better environment for debugging the issue.
chsh -l to list what shells you have installed
chsh -s to set the login shell.
If you only have bash available, it might be worthwhile installing fish, or your alternative shell of choice from the tty you’re in now, just to get you started.
For a quick check, you could have a look in journalctl for the current boot to see if there are any pointers in there to the script with the offending line.
Hi Steve, thanks for replying!
Idk how to debug the .bashrc, but according to my search I ran bash -x got returned this:
-bash: /usr/bin/sed: Argument list too long
-bash: /usr/bin/bash: Argument list too long
-bash: /usr/bin/sed: Argument list too long
I’m open for a better solution than mine.
Try this to prepend the name of the shell script to the start of each line of output, whilst invoking bash with script echoing turned on (-x) and emulating a login shell (-l)
PS4='+ ${BASH_SOURCE}:${LINENO}: ' bash -x -l
Does it indicate which scripts throw out the “argument list too long” messages?
You can determine whether the error is is some system component or user configuration by creating a “test-user” login to see if the error occurs with a default user configuration.
Hi Steve,
I tried to run your script in TTY, but still got the same messages in my previous reply. I do not know what I did wrong.
Hi George,
I tried to run sudo adduser test or sudo useradd test script, I have got the same message but with sudo instead of bash.
You should have had quite a lot of output, as your login bash scripts… for example, here’s the last screenful of output from my system starting a login bash shell with line tracing on:
++ /etc/bashrc:54: shopt -q login_shell
+ /home/steve/.bash_profile:4: '[' -f /home/steve/.bashrc ']'
+ /home/steve/.bash_profile:5: . /home/steve/.bashrc
++ /home/steve/.bashrc:4: '[' -f /etc/bashrc ']'
++ /home/steve/.bashrc:5: . /etc/bashrc
+++ /etc/bashrc:12: '[' -z Y ']'
++ /home/steve/.bashrc:9: [[ /home/steve/.local/bin:/home/steve/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin =~ /home/steve/\.local/bin:/home/steve/bin: ]]
++ /home/steve/.bashrc:10: PATH=/home/steve/.local/bin:/home/steve/bin:/home/steve/.local/bin:/home/steve/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin
++ /home/steve/.bashrc:12: export PATH
++ /home/steve/.bashrc:18: '[' -d /home/steve/.bashrc.d ']'
++ /home/steve/.bashrc:25: unset rc
++ /home/steve/.bashrc:26: . /home/steve/.cargo/env
+++ /home/steve/.cargo/env:4: case ":${PATH}:" in
++ /home/steve/.bashrc:28: source /home/steve/.config/broot/launcher/bash/br
++ /home/steve/.bashrc:31: export PATH=/home/steve/.local/bin:/home/steve/bin:/home/steve/.local/bin:/home/steve/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin
++ /home/steve/.bashrc:31: PATH=/home/steve/.local/bin:/home/steve/bin:/home/steve/.local/bin:/home/steve/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin
+ /home/steve/.bash_profile:9: . /home/steve/.cargo/env
++ /home/steve/.cargo/env:4: case ":${PATH}:" in
+ /home/steve/.bash_profile:11: source /home/steve/.config/broot/launcher/bash/br
+ /home/steve/.bash_profile:14: export PATH=/home/steve/.local/bin:/home/steve/bin:/home/steve/.local/bin:/home/steve/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin
+ /home/steve/.bash_profile:14: PATH=/home/steve/.local/bin:/home/steve/bin:/home/steve/.local/bin:/home/steve/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin:/home/steve/.lmstudio/bin
++ :0: autojump_add_to_database
++ /usr/share/autojump/autojump.bash:2: [[ -f /home/steve/.local/share/autojump/errors.log ]]
++ :0: __systemd_osc_context_precmdline
++ /etc/profile.d/80-systemd-osc-context.sh:2: local systemd_exitstatus=0 systemd_signal
++ /etc/profile.d/80-systemd-osc-context.sh:5: '[' -n '' ']'
++ /etc/profile.d/80-systemd-osc-context.sh:16: '[' -z '' ']'
++ /etc/profile.d/80-systemd-osc-context.sh:17: read -r systemd_osc_context_shell_id
+++ /etc/profile.d/80-systemd-osc-context.sh:1: __systemd_osc_context_common
+++ /etc/profile.d/80-systemd-osc-context.sh:2: '[' -f /etc/machine-id ']'
+++ /etc/profile.d/80-systemd-osc-context.sh:3: printf ';machineid=%.36s' 60e6926ef6e148f2a81930f078796b11
+++ /etc/profile.d/80-systemd-osc-context.sh:5: printf ';user=%.255s;hostname=%.255s;bootid=%.36s;pid=%.20d' steve lurcher cce7e53d-bef4-4aec-813d-e48fec766935 29977
+++ /etc/profile.d/80-systemd-osc-context.sh:1: __systemd_osc_context_escape /home/steve
+++ /etc/profile.d/80-systemd-osc-context.sh:8: echo /home/steve
+++ /etc/profile.d/80-systemd-osc-context.sh:8: sed -e 's/\\/\\x5c/g' -e 's/;/\\x3b/g' -e 's/[[:cntrl:]]/⍰/g'
++ /etc/profile.d/80-systemd-osc-context.sh:21: printf '\033]3008;start=%.64s%s;type=shell;cwd=%.255s\033\' b1bc73e3-5876-4fb0-9eba-7e0b127af49f ';machineid=60e6926ef6e148f2a81930f078796b11;user=steve;hostname=lurcher;bootid=cce7e53d-bef4-4aec-813d-e48fec766935;pid=00000000000000029977' /home/steve
++ /etc/profile.d/80-systemd-osc-context.sh:24: read -r systemd_osc_context_cmd_id
As you can see, as each line of the script is executed it’s emitted to the screen and at the start of each line is the name of the script which is executing and the line number in that script.
What output do you get form executing env -i bash --noprofile --norc?
Hi Steve,
Executing that command also returns the same error, with env instead of bash.
Quite bizarre. How about env | wc -c
If you get the same thing we’ll throw rename your bash login scripts and reboot…
The bug is likely in a change you made to your .bashrc.
Try this to see if that is the case
mv .bashrc .bashrc.orig
touch .bashrc
Does the problem go away?
Hi Steve,
Unfortunately, I still got the same error, but this time an extra line with wc error added.
Hi Barry,
The same error persists even when trying to execute your command. I have got the mv version of the error this time.
I don’t know if updates screwed up my computer, because I know I didn’t intentionally touch the .bashrc file
OK - it would appear that this session is broken and cannot issue the most basic of commands.
As you cannot issue any commands, the only way I can think of to repair the configuration is to boot from a live USB stick, mount your home partition on your disk, find the files /home/usr/.bashrc and /home/usr/.bash_profile and append “.old” to them…
… then un-mount the partition and try to reboot from it.
Hi Steve,
Currently I don’t have the live USB with me, but I will update the situation ASAP when I get home.
alternative: boot into a rescue shell (boot into grub, hit e and append systemd.unit=emergency.target to the linux line).
From there you should be able to rename both /home/usr/.bashrc and .bash_profile to prevent them from being called.
You can then reboot and try to log in as normal whereupon we can begin to work out what the root cause is.
First thing is to get you into the system so you can actually do stuff.
Hi Steve,
The login loop problem persists even after entering into the emergency mode. I guess I will try the live USB method.
Well that sucks.
I suspect that what is happening is that something is spamming multiple copies of the same thing into your path or some other environment variable which is so long it’s causing sed and bash itself to fail to parse it all. That’s why I wanted to see the size of env up above. Should be a few thousand characters (mine is 3438) so if it’s in the tens of thousands then it’s probably buggered.
However, in order to stop this stuff from running we need to be able to issue commands via the shell and whatever is broken is preventing you from issuing anything.
Hi Steve,
Fortunately, live USB method worked. I can now post the logs or files you need.
Excellent.
Let’s have a look at the contents of your newly renamed .bashrc and .bash_profile.
Steve