gdm fails to start if /var/log/gdm does not exist

[Dominic Evans]

Binary package hint: gdm

This fields a bit like a papercut to me.

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 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.

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

[Sebastien Bacher (seb128)]

Thank you for your bug report, there is no need to call every small bug a papercut though those are usability issues

[Sebastien Bacher (seb128)]

The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME). They seem to have decided to break if system directories are not available which can make sense, you should not fiddle with things if you don't know what you are doing

[Dominic Evans (oldmanuk)]

raised upstream on gnome-bugs, although note that despite any upstream decisions, it could trivially be fixed as a couple of additional `mkdir -p` or `[ -d ... ]` lines in the 'debian/gdm.init' init.d script

[Sebastien Bacher (seb128)]

Right but should the init scripts all try to workaround every way users might have screwed their install? It would add complexity and bugs only to try to workaround users touching things they should not

[Dominic Evans (oldmanuk)]

Well of all the apps I had jnstalled that logged to /var/log/
subdirectory only gdm and apt failed to recreate their chosen subdir
on next launch and gdm was the only one that failed to launch because
of it. So patching gdm to be consistent with all the other apps
included in a default ubuntu install seems a fair proposal to me. As
far as I'm concerned /var/log should be as throwaway a dir as /var/tmp
and the cache dirs for a user.

On 27 Jul 2009, at 13:31, Sebastien Bacher <email address hidden> wrote:

> Right but should the init scripts all try to workaround every way
> users
> might have screwed their install? It would add complexity and bugs
> only
> to try to workaround users touching things they should not
>
> ** Changed in: gdm (Ubuntu)
> Status: New => Triaged
>
> --
> gdm fails to start if /var/log/gdm does not exist
> https://bugs.launchpad.net/bugs/405227
> You received this bug notification because you are a direct subscriber
> of the bug.

[Sebastien Bacher (seb128)]

I don't argue against fixing this issue, but next you can raise the same concern about deleting the etc directory, etc

[Guilhem Lettron (guilhem-fr)]

This bug is quite important for me because my netbook is unusable because of this.

To prevent damage on SSD, I use tmpfs for /var/log/
So, I lost all changes and any folder. It make an error for apt, but it's really crazy that gdm stop for this!

[damianos (damian-linux)]

I use /var/log on a tmpfs mount too. I just did the following in /etc/init.d/gdm

if [ ! -d /var/log/gdm ]; then
 mkdir /var/log/gdm
fi

[dbkaplun (dbkaplun)]

This bug's priority should be raised to critical. Like Guilhem, many SSD users (that includes some models of EeePCs) use tmpfs for /var/log.

[dbkaplun (dbkaplun)]

Furthermore, damianos' fix is reasonable but should not be included in /etc/init.d/gdm as the logging code is not there. It should instead be in GDM's logging code.

[Noel J. Bergman (noeljb)]

Sebastien, as just came up on #ubuntu+1, "Many EeePC users have /var/log set to tmpfs", so the proposed init script fix should be adopted until something else is done. I'd go with Damianos' solution.

[dbkaplun (dbkaplun)]

One more thing.

I encountered this bug when booting up. However, when GDM failed to start, I was stuck with a blinking white text cursor at the top-left of my black screen and I was not able to Ctrl+Alt+F<n> to a prompt.

Booting up should fail gracefully.

[dbkaplun (dbkaplun)]

Importance should be "Critical".

This bug bit me in the ass again as the init script, /etc/init.d/gdm, was replaced with /etc/init/gdm.conf. I had to recode the fix into the init file.

This is NOT a difficult bug to fix for GDM developers! It is so disappointing that this bug still exists.

[ENigma885 (enigma-pentagram)]

"Importance should be "Critical"." OF COURSE

Having a non-functional gdm is just like having a useless machine.

[Pär Lindfors (paran)]

This bug is about GDM breaking when a user remove system directories
that they should never remove. Importance Critical would be
ridiculous, I actually think even Medium is too much.

It is an incorrect assumption that it is OK to "tidy up" by running
"rm -rf /var/log/*". Doing that is never correct, AFAIK /var/cache is
the only directory under /var where the FHS say you may remove
anything at any time.

There is probably many other programs that can't recreate their own
log directory, especially programs running as non-root. Only root can
write to /var/log, so giving write permissions for other system
uid/gid is often the reason that an application have a separate
directory under /var/log.

(SSD) Users that like to put /var/log on tmpfs will need to sync files
to/from it at boot/shutdown, just as if they put any other system
directory on tmpfs. If there are guides/howtos suggesting to mount an
empty tmpfs on /var/log at boot then those guides needs to be fixed.

Here are the relevant parts of FHS[1] and Debian Policy[2]:

[1] http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#THEVARHIERARCHY
[2] http://www.debian.org/doc/debian-policy/ch-files.html

[dbkaplun (dbkaplun)]

Say what you wish. Here are two facts:

1) GDM should not explode because its logging directory doesn't exist. Logging is strictly a feature. This statement goes along with every other program that does not inherently require logging.
2) A non-trivial quantity of users will have GDM fail because its logging directory doesn't exist.

GDM can a) recreate its logging directory structure, or b) emit a warning; both of these methods are foolproof, simple, and safe.

All in all, the dangers of keeping current behavior are great while changing behavior to something less flawed is extremely redeeming.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm - 2.28.0-0ubuntu2

---------------
gdm (2.28.0-0ubuntu2) karmic; urgency=low

  * debian/patches/08_use_polkit_for_settings.patch:
    - set translatable strings and list the file to translate (lp: #425798)
  * debian/patches/09_gdmsetup.patch,
    debian/patches/99_autoreconf.patch:
    - initialize the translations so the gdmsetup interface is translated
      (lp: #434102)
  * debian/patches/17_use_timed_login_after_autologin.patch:
    - revert upstream change to not use timed login after autologin session
      (lp: #396489)
  * debian/patches/18_create_log_dir_when_required.patch:
    - create the log directory when required (lp: #405227)
  * debian/gdm.config, debian/gdm.templates:
    - restore debconf files which have been dropped by error in karmic,
      thanks Pär Andersson (lp: #395591)

 -- Sebastien Bacher <email address hidden> Tue, 22 Sep 2009 15:20:27 +0200