# Startverzögerung nach GDM Login

## TheSmallOne

Hallo erstmal.

Seit ein paar Tagen habe ich eine merkwürdige Verzögerung nach dem grafischen Login.

Also mein Rechner fährt ganz normal hoch und zeigt dann das grafische Login an.

Wenn ich dort meine Zugangsdaten eingebe passiert aber erstmal etwa 2,5 Minuten gar nichts.

Ich kann auch keinen Tast oder so entdecken, der da eventuell zu viele Ressourcen beansprucht und das System ausbremsen würde. Es passiert einfach nichts auf der grafischen Oberfläche.

Hier mal ein Log-Auszug meines letzten Logins:

```
May 16 16:08:50 laputa /usr/sbin/gpm[1928]: *** info [daemon/startup.c(136)]: 

May 16 16:08:50 laputa /usr/sbin/gpm[1928]: Started gpm successfully. Entered daemon mode.

May 16 16:09:02 laputa dbus[1636]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper)

May 16 16:09:02 laputa dbus[1636]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper)

May 16 16:09:03 laputa polkitd[2130]: Started polkitd version 0.110

May 16 16:09:03 laputa dbus[1636]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'

May 16 16:09:03 laputa dbus[1636]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'

May 16 16:11:14 laputa dbus[1636]: [system] Activating service name='org.freedesktop.UDisks' (using servicehelper)

May 16 16:11:14 laputa dbus[1636]: [system] Successfully activated service 'org.freedesktop.UDisks'

May 16 16:11:22 laputa dbus[1636]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper)

May 16 16:11:22 laputa dbus[1636]: [system] Successfully activated service 'org.freedesktop.UPower'

May 16 16:11:22 laputa dbus[1636]: [system] Activating service name='org.gnome.SettingsDaemon.DateTimeMechanism' (using servicehelper)

May 16 16:11:22 laputa kernel: [  173.329484] ata2.00: configured for UDMA/133

May 16 16:11:22 laputa kernel: [  173.329490] ata2: EH complete

May 16 16:11:22 laputa dbus[1636]: [system] Successfully activated service 'org.gnome.SettingsDaemon.DateTimeMechanism'

May 16 16:11:23 laputa kernel: [  173.583715] EXT4-fs (sda5): re-mounted. Opts: commit=0

May 16 16:11:23 laputa kernel: [  174.143209] EXT4-fs (sda6): re-mounted. Opts: commit=0

May 16 16:11:23 laputa kernel: [  174.145430] EXT4-fs (sda8): re-mounted. Opts: commit=0

May 16 16:11:23 laputa kernel: [  174.347789] EXT4-fs (sda7): re-mounted. Opts: commit=0

May 16 16:11:23 laputa kernel: [  174.351992] EXT4-fs (sda9): re-mounted. Opts: commit=0
```

Wie man sieht gibt es da zeitlich eine Lücke von 16:09:03 bis 16:11:14 in der nichts ist.

Interessant finde ich auch die Einträge am Schluß, dass sämtliche Dateisysteme re-mounted wurden. Wieso?

Kennt jemand das Problem evtl. und weiß wo ich da anpacken muss?

----------

## schmidicom

Interessant finde ich das es genau nach dem aktivieren von Consolekit passiert:

```
May 16 16:09:03 laputa dbus[1636]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' 

May 16 16:11:14 laputa dbus[1636]: [system] Activating service name='org.freedesktop.UDisks' (using servicehelper)
```

Da das Ding ja nicht mehr wirklich weiterentwickelt wird könnte es vielleicht wirklich daran liegen. Das dumme ist nur um das zu überprüfen müsstest du systemd als die einzige alternative ausprobieren was aber leider keine Kleinigkeit ist. Oder du kannst Consolekit im Debugmodus starten lassen und sehen ob es dann was brauchbares ausspuckt.

----------

## TheSmallOne

Wo muss ich denn da den Debug-Modus einstellen?

----------

## schmidicom

Mit einem "--debug" an der richtig Stelle im entsprechenden Initscript, aber wo genau kann ich dir auch nicht sagen da meine Installationen inzwischen mit systemd und ohne Consolekit laufen.

----------

## TheSmallOne

Soweit ich weiß wird es bei mir aber nicht durch ein Init-Skript gestartet, sondern irgendwann während des grafischen Logins.

----------

## Josef.95

 *TheSmallOne wrote:*   

> Soweit ich weiß wird es bei mir aber nicht durch ein Init-Skript gestartet, sondern irgendwann während des grafischen Logins.

 

Hm, eventuell bringt es ja was wenn dbus und consolekit schon vor dem (xdm) gdm via InitScript gestartet werden - packe die doch mal mit ins default Runlevel.

(ist doch, soweit mir bekannt, der normale Weg wenn man das Zeugs braucht)

----------

## TheSmallOne

Also irgendwie sehe ich nicht ganz die Notwendigkeit dafür irgendwelche Daemons, die für den Desktop benötigt werden bereits zu starten, bevor ich die Grafische Oberfläche überhaupt benutze.

Wie auch immer; ich habe consolekit in den default Runlevel eingefügt und das Init-Skript um ein --debug ergänzt. Ich erhalte allerdings keinerlei Meldungen, die nicht vorher schon da gewesen wären.

Hat evtl. noch jemand eine Idee?

In der letzten Woche bin ich so verfahren, dass ich den Rechner komplett habe durchlaufen lassen, um die drei Minuten Verzögerung zu vermeiden, aber das kann es ja auch nicht sein.

----------

## Josef.95

 *TheSmallOne wrote:*   

> Also irgendwie sehe ich nicht ganz die Notwendigkeit dafür irgendwelche Daemons, die für den Desktop benötigt werden bereits zu starten, bevor ich die Grafische Oberfläche überhaupt benutze.

 

Hm ja, aber normal muss consolekit eben schon vor dem User-Login gestartet sein - aber ok, zur Not macht GDM das auch selbst. Meine Vermutung war, das es daran liegen könnte das gdm erst selbst dbus und consolekit starten muss.

Ich denke es wäre hilfreich wenn man wüsste um welche gdm Version es überhaupt geht.

Ansonsten schau doch auch noch mal ob in der Log Datei von gdm was hilfreiches zu finden ist, oder auch in der ~/.xsession-errors

----------

## TheSmallOne

 *Josef.95 wrote:*   

> Ich denke es wäre hilfreich wenn man wüsste um welche gdm Version es überhaupt geht.
> 
> Ansonsten schau doch auch noch mal ob in der Log Datei von gdm was hilfreiches zu finden ist, oder auch in der ~/.xsession-errors

 

```
$ gdm --version

GDM 2.20.11
```

In der .xsession-errors finde ich nichts relevantes. gdm hat eine eigene Log-Datei?

Irgendwie hatte ich vor längerer Zeit an einem anderen Rechner mal einen etwas ähnlichen Fehler. Damals lag es daran, das irgendein Paket eine bestimmte Kerneloption benötigt hatte und portage erst nach einigen Versionsänderungen eine entsprechende Warnmeldung ausgegeben hat. Ob das hier was ähnliches ist?

----------

## Josef.95

 *TheSmallOne wrote:*   

> gdm hat eine eigene Log-Datei?

 

Da bin ich mir nicht sicher, könnte je nach Version und Konfiguration unterschiedlich sein.

Aber schaue doch einfach mal nach, wenn, dann wird sie wahrscheinlich unter /var/log/ zu finden sein.

----------

## kernelOfTruth

das mit dem remounten dürfte ein Feature von gnome & kde4 sein,

wo das genau ausgelöst, hab ich bis jetzt noch nicht rausgefunden (nicht genauer damit beschäftigt, nutze zur Zeit auch XFCE4)

----------

## ChrisJumper

Ich habe ein ähnliches "Problem" bei mir ist es allerdings bei grnome 3 und auch scheinbar nur dort bezüglich der gnome-shell. Weil ich aber komplett andere Versionen nutze und diese Erfahrung auch gemacht habe, kann es nur an Consolkit liegen und daran das das System neuerdings schneller Bootet und Hochfährt.

Mit sysvinit 2.88 und vor allem der Kernel 3.9.1, brachte allein eine Bootbeschleunigung bis zum Graifkmanger von bestimmt 10 Sekunden. Der Login-Vorgang (nach Eingabe der Daten und Enter) braucht dann aber auch nochmal weitere 15-20 Sekunden.

Der Grafische Login ist nach 10 Sekunden (!) schon da.

Edit:

Oha! Das sind ja fast 2-3 Minuten, ich dachte es geht hier um ein Verzögerung im Sekundenbereich. Da würde ich als erstes die Festplatten überprüfen, nicht das die einen Fehler haben oder erstmals "aufwachen" müssen. Allerdings würde sich das bemerkbar machen.

----------

## TheSmallOne

Wollte mich nur noch mal kurz melden.

Ich habe zwar nicht herausgefunden was das Problem genau war, aber irgendwann war es von heute auf morgen genauso plötzlich verschwunden, wie es aufgetaucht war.

Diese Fehler sind mir irgendwie immer recht suspekt.

----------

