Description of problem: TTY login no longer works when disk is full (password prompt never shows up after entering the user name). This can be a problem when root access is required to remove the files, and there is no root shell open (or no user login at all). I haven't tested ssh, but I suppose it might be affected aswell. The component I picked may be wrong, but I was refused the correct component name in #fedora because it was spontaneously decided this was "not a bug" and I should apparently be barred from filing it. While I agree the behaviour which is subject of this bug might be more of a design issue, it's still not ideal and I would certainly like to be allowed to file a bug report on it. Version-Release number of selected component (if applicable): 3.11.1-200.fc19.x86_64 How reproducible: I tested only once, at a later accidential disk fill I hit #1017408 and therefore I was a bit reluctant to try again with additional disk fills Steps to Reproduce: 1. Fill disk 2. Go to TTY with ctrl+alt+F2 3. Attempt login Actual results: I can enter a username and press enter, but the password prompt never shows up. Eventually, the login expires. Expected results: Login works. Additional info:
If your disk is full and things need to write to the disk to log in, then I don't think there is much that can be done here. At any rate, it isn't a kernel issue. Moving to the distribution component.
I am wondering if there was a way login could be done anyway? (e.g. by storing whatever needs to be written - login logs I suppose - in memory?) Also sorry for the #fedora remark, it doesn't belong here and it might or might not have been a misunderstanding. (it's on irc feedback now)
The login & getty programs come from util-linux, although the issue could lie elsewhere.
If this is related, sudo and su don't work either.
We would need a strace log of the login process to see where it is stuck.
Hmm I suppose I could see if I can reproduce it safely inside a virtual machine. I'm a bit reluctant with trying it on my laptop atm where I experienced this, since btrfs. The agetty processes are the one I would need to attach strace to I suppose?
Yes, probably strace with -f (agetty asks for username, then exec login(1), the login process asks for password). It's probably journald or audit problem.
We need strace log to find out where the login process is stuck.
Clearing needinfo since this has been closed for years