GNOME Bugzilla – Bug 144473
GDM could provide meaningful error when /tmp permissions are incorrect
Last modified: 2013-12-16 18:04:10 UTC
Give inappropriate permissions (say 755) to /tmp and gdm will not login, but it doesn't report a meaningful reason why. It may be nice to provide an error explaining the problem. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111050 for details.
I'd accept a patch
Ubuntu bug about a similar issue if tmp has no free space: https://launchpad.net/products/gdm/+bug/35217
Free space issue is very important for lots of users - they often are installing lots of software or simply downloading lots of stuff and after rebooting they can't login :(
I agree this would be a great bug to fix. As I said, I'd happily accept a patch
(In reply to comment #4) > I agree this would be a great bug to fix. As I said, I'd happily accept a > patch OK, so let's talk about best way how to solve this bug. For most users problem is, that gdm doesn't work when there are no free space on /tmp and doesn't offer a usable solution for regular user how to free some space in volume. I've found a good solution for this gdm problem in gnome bug #339229 - gdm should create place-holder file of needed size (for example ~50 kb) in /tmp after gdm starts (also display a warning message if there are no enough space for creating such file) and erase this file in /tmp before gdm starts. What you think about this way ?
I'm not sure that I agree that it should be GDM's responsibility to make sure that the user's file system is sane. GDM is a Display Manager, not the program that ensures that any issue that could confront a user on bootup is addressed. Are you sure there isn't a more sensible place in the kernel that "protecting the user from filling their file system" should be implemented? Perhaps systems should be setup with users having quotas by default to avoid the filesystem getting filled? That said, I do think that GDM should behave nicely in the situation where the disk is full. It shouldn't block the user from logging into a failsafe session. If the user session will hang if the filesystem is full. It should probably also only allow the user to go into failsafe xterm in this situation and disallow letting the user try to log into other session. In this case, I don't think any files need to be written on login. I think a better solution is for GDM to recognize the situation and not start, leaving the user at a console login so they can fix the problem at the console. It should print out an error message explaining what the user needs to do. I don't think playing games with the filesystem to ensure that there is free space is a good idea. Not sure users would really want GDM consuming extra disk space it doesn't really need. If the filesystem is being filled because some process is writing a lot of stuff, then there is really no guarantee that removing such a placeholder file will free up any space. It is just as likely that the runaway process will consume the free disk space as soon as it becomes available, and not give GDM or the user time to take advantage of it. There are all sorts of race conditions here that would be tricky to address, I think. Though perhaps we can talk this issue through a bit more and come up with a better solution that would resolve the problem.
A console login is not an option for many beginners and gnome is definitely targeted also to beginners. Why is free disk space needed to login inside GDM and not in the console?
A quick look at the GDM code points out that GDM uses /tmp for the following reasons: + /tmp/.gdm_socket for the GDM daemon and GUI program to talk to each other properly. Without the socket being setup, GDM probably would still work though the GUI program wouldn't be able to access the config file and would instead revert to the compiled-in defaults (e.g. your theming would probably be wrong). Features that require the socket to be working (such as automatic/timed login or any gdmflexiserver --commands) would also not work. Perhaps moving the socket to /var/tmp might make it less likely you'd have problems here? + GDM uses /tmp for the fallback Xauth key directory if the normal xauth directory (UserAuthDir in the GDM configuraiton) is also full. If GDM can't write xauth files, then it probably wouldn't let the user login. If both UserAuthDir and /tmp are full, this could be a problem with GDM not allowing users to log in at all. + /tmp/.ICE-unix, /tmp/.X11-lock, and /tmp/.X11-unix are also used. Not sure how GDM will break if it couldn't write these files. I'm guessing this might be the problem that causes GDM to fail to allow login when /tmp is full. + If the user's $HOME is full, it will put the .xsession-errors file in /tmp instead. Probably not a big deal if these don't get written, though I'm not sure what GDM does if it can't write them. If we wanted GDM to work when /tmp is full, we'd need to make sure that GDM has ways to workaround all the above problems.
May I propose the following solution: mount a very small loopback filesystem or even better a ramfs for the sole purpose of hosting all those files? It should be really easy. You mount a small ramfs in /tmp/gdmfs, then you make gdm create all of its files in gdmfs. Since all these files are temporary and small, this makes sense in my opinion, even if problems arise with .xsession-errors, which is unbound in size. Perhaps .xsession-errors should not exist at all if the user has no free space to write on.
I meet the problem today, it is really annoying. (gdm-2.24) GDM should better show such error message on the error label, just as authentication failed.
I'm going to close this out. I wrote this in 2004, and these days I don't even think it's a good idea. GDM shouldn't be showing things to the user without a graphical display, imno.