This bug may be related to Bug #332927 but this bug report is specific to Gnome and it inability to create a login session and be "reasonably" informed about why it cannot do so (so instead of bumping it up the GNU/GlibC ladder it should be bumped up the Gnome ladder.) After having upgraded to glibc-2.12 (which entails the fatal static programs no longer execute thus proving that they aren't really "static" in spite of what reasonable people would like to believe). (And I am working around this largely by copying non-static binaries off of a Ubuntu root partition rather than attempting to rebuild a functional Gentoo system...)... Here is the primary complaint. After having rebooted the system (which I'm surprised worked given that init and the tools are "static"), I can only login as "root". So all the gnome utilities work (I have a functional desktop session as root). But all logins as other users (which were functional before the glibc upgrade and system reboot) fail. (One can login to an X terminal but one is immediately returned to a login screen). Reproducible: Always Steps to Reproduce: 1. Upgrade to glibc-2.12.1 2. Reboot system (now of course the catch here is that many packages are built in "static" mode -- as they should be for reliability/security. 3. Attempt to login as a non-root user. Actual Results: Here is an investigation: cd /home/bradbury frodo bradbury # cat .gnomerc-errors Warning: Only changing the first 7 of 10 buttons. which: no keychain in (:/home/bradbury/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.4.4:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/qt/3/bin:/usr/games/bin:/usr/GNUstep/System/Tools:/usr/GNUstep/Local/Tools:/usr/java/bin:/home/bradbury/Genomes/bin) mkdtemp: private socket dir: No space left on device frodo bradbury # df / /usr /home Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 3943836 3658504 84996 98% / /dev/sda9 15752996 15131916 541060 97% /usr /dev/sda13 15752996 15500744 172232 99% /home frodo bradbury # date Thu Aug 19 14:15:59 EDT 2010 frodo bradbury # ls -ld /home/bradbury/.gnomerc-errors -rw------- 1 bradbury aeiveos 396 Aug 19 14:14 /home/bradbury/.gnomerc-errors This is after an attempt to login as "bradbury" on VT2. Now the ".gnomerc-errors" seems to be pointing out a problem which does not exist [lack of space] (so the error message is *wrong* and it should be bumped upstream). Expected Results: If I can login as root (and get a valid Gnome session) I should be able to login as bradbury or firefox (previously valid users before upgrading glibc and rebooting the system). The fact that I cannot suggests there is some interaction between the system libraries and Gnome related to the "static" options -- when there should not be.
I believe this is the second time you open a bug and there is a "no space left on device" message in your logs but you never answer said bug about this problem. Anyway, what is the filesystem on your /home, if it is ext3/4, please paste the output of tune2fs -l /dev/sda13.
Created attachment 243609 [details] State of /home device as requested. Here is a df & tune2fs of /dev/sda13 at such a time when "normal" users, e.g. "bradbury", "firefox", etc. are incapable of logging in. As stated these users were "functional" before the glibc upgrade + reboot. And the question (IMO) may revolve around how gnome may depend upon "static" libraries. As also stated this is a "functional" system, I am logged in as "root" using a VT with X, Gnome, ... The problem takes place specifically when I try to login as a non-root user.
Gilles, I don't believe that I've opened two bug reports regarding the "no space" message. I did open a bug report (which I believe was properly resolved as "invalid") due to trying to login as a new user without a proper "TMPDIR". Point (a) I've got space on sda13 - home. I went through a process of explicitly deleting files and then attempting to login to make sure of this. So the error message from gnome in the .gnomerc-errors file is either completely wrong or misleading. That implies an upstream report -- the gnome developers are not properly handling/documenting login case failures. Point (b) The problem only arose after the glibc upgrade. Coincidence? Maybe but doubtful. Point (c) and this goes back to my previous failure to login when one doesn't have an existing directory for "TMPDIR". Gnome logins should put up pop-up windows pointing out what is *clearly* wrong with a login instance. One should not be reduced to mucking around through .gnomerc-errors -- when the average (non-gnome/X-literate user) isn't going to even know that that file exists. And this needs to be made clear to the upstream Gnome providers. Gnome is next to useless if it can only be used by people who can deal with it from a developer level.
Well there is no program on the system "mkdtemp". So its either an error coming from a shell script or an error from a binary like "gnome-session. I've tried "set -x" in .profile and that yields no additional information in .gnomerc-errors. So it is happening very early on in the login session. I'd appreciate some help here -- how does one go about diagnosing specific problems in Gnome logins? "gnome-session" is compiled with "debug" -- how does one enable it? Again, I can find no file system which has "No space left on device" so the error message is misleading or simply wrong.
I stand corrected. As it turns out is a combination of my fault and extremely poor error reporting from ssh-agent and to a lesser extent Gnome (the login proceedures). *** This bug is unrelated to glibc problems *** The Gnome session login process is complex enough (starting up 6+ processes (gnome-session, gnome-panel, nautilus, metacity, etc.) that the startup files (Sessons/Gnome, etc.) need to make it easer to diagnose problems. The program which uses mkdtemp is "ssh-agent", and it creates a directory in /tmp (ignoring any setting of TMPDIR). If /tmp is full from the perspective of the user logging in the login will fail. (Root could write into /tmp but other user-ids could not [a flaw in the reserved block architecture since it only allows a single uid/gid.). The problem was mistakenly filed under "glibc" due to the fact that the error arose during the static library problems and "openssh" (including ssh-agent) had to be rebuilt (-static) during that period to allow remote logins. At the same time /tmp ran out of space. The error could be corrected by one or more of: a) ssh-agent following the TMPDIR conventions for creating directories; b) ssh-agent following TMPDIR or alternately use /tmp if TMPDIR fails due to space limitations; c) ssh-agent indicating in error messages that it is *ssh-agent* error; d) Gnome logins/sessions did not fail if ssh-agent or indicate that they are failing *because* ssh-agent fails. It would be nice to know whether openssh has a bug reporting system and/or if Gentoo will file the bugs upstream.
this bug should be assigned to openssh maintainers then.
Created attachment 244623 [details, diff] openssh-ssh-agent-tmpdir.patch here is an untested patch
upstream says it'll be fixed in 5.7 ... this isnt a regression, and hardly anyone has ever noticed it, so i'm inclined to just wait for the next release
