0

I have a Jessie install that wont allow me to logon.

It boots up, presents the prompt, accepts the username and password, but just blinks and comes back to the login prompt.

It appears that Bash is getting an error code from some part of the login process, which causes it to exit back to the parent process.

How can I trace this. I have had a look thru all the regular profile and rc files (there is only one user besides root) but I can't see anything that might be causing it.

Because its happening inside Bash, its NOT putting anything in the system logs.

Is there a way to start/verify logging deamons, and what can I use to see what, where or why Bash is exiting after logging in.

I have access to the filesystem, so I can manually poke through it and make changes.

Paul Wratt
  • 334
  • A few things, permissions or if you have exit on one of the rc files then yeah, that would prevent you from logging in. – Jetchisel Mar 28 '20 at 03:54
  • ok, permissions I had not thought of, but exit had occured to me. My last resort (which I have not tried yet) is to move all the fc files (maybe providing blank ones) and reintroduce then one at a time. thnx – Paul Wratt Mar 28 '20 at 04:17
  • @Jetchisel If the OP said "intermittantly wont allow" instead of "wont allow", would that change your response (because that was happening previously, before last upgrade)? – Paul Wratt Mar 28 '20 at 04:44
  • Do you have graphical or text terminal where you log on? The problems you describe look very typical XWindows crash, if you use graphical login. After login XWindows start, and if they crash you get back to login screen. – nobody Mar 28 '20 at 07:59
  • You aren't using the word "terminal" correctly, as clearly this is terminal login. Moreover, saying that this is the console is saying something quite specific, that it is the console device, which probably is not specifically the case here. It is more likely that it is a Linux kernel virtual terminal that you are talking about. You are not clarifying things to people. Clarifications would mention the actual terminal device name (/dev/tty1?), mention whether this applies to both accounts, and mention how you are otherwise logging on in order to access the filesystem. – JdeBP Mar 28 '20 at 09:23
  • I just deleted a comment because I thought it was pointless, and the comment by @nobody may be of use to someone else in the future. FYI The linux source code calls it "console", go look. IE a terminal requires terminal emulation and by definition on TTY device, which is explicitly "a TeleTYpe terminal device". If I were to concede to "console terminal" I would also have to accept the year as 1970. Remember that a printer is "an output terminal", which is why "go sit at that terminal console" is accurate. In modern context a terminal is generally speaking an X Windows program that provides – Paul Wratt Mar 28 '20 at 11:18
  • You really do not understand the terminology, and are not clarifying things for people with this mis-use, let alone by omitting the other stuff. https://unix.stackexchange.com/a/484601/5132 – JdeBP Mar 28 '20 at 11:28
  • .. a specific terminal emulation (eg XTerm). But technically that is not accurate, because FBTerm does not run on X Windows, it runs on the linux console. If I was to agree with you, then I would have to say the other comment is also true, as both imply that I have lied by ommision, because I did not mention any TTY# or X Windows running automatically after login. The truth is you are both wrong as I use a Frame Buffer device, and have presumed there is some missing information because I failed to specifically exclude certain informaition. CLEARLY neither understood the OP. – Paul Wratt Mar 28 '20 at 11:29

1 Answers1

1

You could add set -x to the beginning of /etc/profile, causing the shell to display every command it is going to execute with all the variable expansions etc. already expanded, so you'll see what the shell is actually doing.

But if you're talking about a GUI login, first check that your filesystem is not 100% full: creating a GUI session requires creating a few small files, and if the filesystem is completely full, that will fail. A basic command-line login (e.g. over SSH or on the text-mode console) should succeed even when the disk is 100% full.

telcoM
  • 96,466
  • thnx, that may help debugging, line stepping would be the next helper (not available in any shell that I know of). The problem with that is the screen blank that happens before returning to the login prompt. Yes I originally thought it was a "disk" issue (full or inability to write, because its and sd-card). Because I know it is failing in bash, I already know it will fail with ssh as well. I will 1st try your suggestion (a painful and time consuming process). However I could probably do that via chroot from another Jessie install, in which case it might not do the screen blank. – Paul Wratt Mar 28 '20 at 12:32
  • 1
    Check any ~/.bash_logout scripts that might be applicable and comment out any "clear" commands for the duration of troubleshooting. – telcoM Mar 28 '20 at 12:37
  • arh, thankyou. my feeling is that there is an error being printed, you just never get to se any text because the next thing that happens is a screen (terminal) clear. – Paul Wratt Mar 28 '20 at 12:44
  • The "set -x in /etc/profile" trick helped me understand why my session was crashing at login, thanks! – KooKiz Oct 15 '21 at 16:35