GNOME Bugzilla – Bug 589862
gdm fails to start if /var/log/gdm does not exist
Last modified: 2010-07-02 19:11:12 UTC
Originally reported at: https://bugs.launchpad.net/bugs/405227 Binary package hint: gdm If a user decides to tidy up their /var/log directory, with e.g., a sudo rm -rf /var/log/*, and removes the 'gdm' subdirectory from /var/log then gdm will refuse to start on next boot/restart. The user will find this difficult to debug. Ideally gdm should be capable of re-creating its own logging directory on start, rather than just weakly reporting that /var/log/gdm doesn't exist and failing to start. i.e., either test for directory existence, and create if not found, or always do a `mkdir -p /var/log/gdm` on startup (as it won't error on directory exists anyway) ProblemType: Bug Architecture: amd64 Date: Mon Jul 27 11:06:40 2009 DistroRelease: Ubuntu 9.10 Package: gdm 2.27.4-0ubuntu6 ProcEnviron: SHELL=/bin/bash PATH=(custom, no user) LANG=en_GB.UTF-8 LANGUAGE=en_GB:en ProcVersionSignature: Ubuntu 2.6.31-4.22-generic SourcePackage: gdm Uname: Linux 2.6.31-4-generic x86_64
makes sense.
This needs to be marked "major". I use an EeePC with an SSD and in order to minimize writes I set /var/log to use tmpfs in fstab. There is a large affected audience that does the same thing that I do. Many users will not know what to do. The solution is VERY simple -- just make the directory before attempting to use itk in the GDM code.
In fact, I don't see why GDM needs to quit if it can't log. It should just print a warning somewhere and move on.
I'd definitely take a patch that did g_mkdir_with_parents or whatever... Otherwise, i'll write it at some point. This is a niche problem though. It's not unreasonable for an application to expect /var/log exists. Trivial workaround is to mkdir -p /var/log in /etc/rc.local.
The problem has been fixed.
Created attachment 145806 [details] [review] the change we use in ubuntu
Created attachment 145809 [details] [review] updated patch that calls chown It's better to call chown() after g_mkdir to ensure the permissions are set properly.
Oops, I mean the updated patch calls g_chmod(), not chown().
Review of attachment 145809 [details] [review]: seems fine to me...
Fixed in master, and in the 2.28.1 release.