UCC-Desktop "hängen" nach der Anmeldung

german

#1

Hallo,

nach dem Aufspielen der letzten Updates auf dem UCS (4.1) und den UCCs hängen die Sitzungen sehr oft nach der Anmeldung.
Das im UCS-Forum beschriebene Problem tritt in unserer Umgebung auch auf, aber das lässt sich durch einen Neustart ja “beheben”.

Der Start der UCC und die Anmeldungen sehen alle ganz normal aus. Wenn der Nutzer-Desktop erscheint friert die Oberfläche für 3-10 Minuten ein. Manchmal auch für “immer”.
Dieser Effekt tritt während des Betriebs dann gehäuft wieder auf.
Eine Systemetik welchen Nutzer und welchen Rechner es betrifft und welchen nicht, ist nicht zu erkennen. (Lokale Anmeldungen scheinen nicht betroffen.)

Alle Freigaben werden per cifs gemountet.
Im syslog auf dem Server und den Clients konnte ich nichts “Verdächdiges” erkennen, außer eben die Lücke in den Zeitstempeln während die Rechenr einfrieren.

Bitte um Hilfe
Torsten


#2

Hallo,
ich habe mir die log.smbd angeschaut.
Sowohl in der Testumgebung als auch in der produktiven Umgebung stehen Meldungen wie diese im log.
Oplock break failed for file .kde/share/apps/activitymanager/resources/database – replying anyway
[2015/11/30 13:42:53.165559, 0, pid=14839] …/source3/smbd/oplock.c:699(oplock_timeout_handler)

Ich habe die /etc/samba/base.conf jetzt “angepasst”. Der home-Eintrag sieht jetzt so aus:

[homes]
comment = Heimatverzeichnisse
browsable = no

read only = no

    create mask = 0700
    directory mask = 0700
    vfs objects = acl_xattr

ab hier neu von Hand

    fs objects = acl_xattr
    msdfs root = no
    writeable = yes
    public = no
    dos filemode = no
    hide unreadable = no
    create mode = 0744
    directory mode = 0755
    force create mode = 00
    force directory mode = 00
    security mask = 0777
    directory security mask = 0777
    force security mode = 00
    force directory security mode = 00
    locking = 1
    blocking locks = 0
    strict locking = 0
    oplocks = 0
    level2 oplocks = 0
    fake oplocks = 0
    csc policy = manual[errata][/errata]
    nt acl support = 1
    inherit acls = 1
    inherit owner = no
    inherit permissions = no

Seit dem taucht der Fehler nicht mehr auf und auch das “Einfrieren” scheint nicht mehr aufzutreten.
Ich bin mir nur nicht sicher, ob ich mir damit jetzt andere Probleme bereitet habe?


#3

Es ist hier nicht so leicht vorherzusehen ob weitere Probleme damit auftreten und welcher Teil der Config jetzt das Problem behoben hat ohne dein System genau zu kennen. Um ganz sicher zu gehen würde ich die Config so lange zurückfahren bis der Fehler wieder auftritt. Aber wenn grad nichts auffällig ist kann das auch so bleiben, denke ich.

Grüsse!


#4

Hallo,
ich habe mir eine weiter Testumgebung geschaffen.
UCS + UCC:

  • alle auf dem letzten Update-Stand
  • ucs nur mit DHCP, DNS, AD, Cups, UCC
  • 2 unterschiedliche Laptops + 2 unterschiedliche PCs
  • 4 Nutzer
  • das Ausrollen der UCC hat wie immer reibungslos geklappt
  • die “home” Verzeichnisse wie im Handbuch beschrieben über die Variablen eingebunden
  • in der pam_mount.conf.xml steht:
  • als Nutzer melde ich mich mit Accounts nun wechselnd an den Geräten an und die Sitzungen hängen kurz nach der Anmeldung, wie im ersten Eintrag beschrieben (mit hoher Wahrscheinlichkeit)

Ich würde beinahe behaupten, ich könnte das regelmäßig reproduzieren und Univention sicher auch.
Änderungen an der base.conf haben keine Wirkung, darum ist diese im “Originalzustand”.
Sobald ich die home-Verzecihnisse nicht einbinde, geht die Anmeldung und das Arbeiten reibungslos, auch wenn ich sonstige “allgemeine” Freigaben einbinde.

in der .xsessio-errors des Nutzers stehen unter anderen diese Meldungen:

file:///usr/share/kde4/apps/plasma/plasmoids/notifier/contents/ui/devicenotifier.qml:224:13: QML QDeclarativeListView_QML_156: Bei der FÃ^ülloperation wurde eine potentielle Endlosschleife der Anker festgestellt.
file:///usr/share/kde4/apps/plasma/plasmoids/battery/contents/ui/CompactRepresentation.qml:73:9: QML Column: Cannot specify top, bottom, verticalCenter, fill or centerIn anchors for items inside Column
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
Verbindungsfehler: Verbindung verweigert
pa_context_new() fehlgeschlagen: Verbindung verweigert
Verbindungsfehler: Verbindung verweigert
pa_context_new() fehlgeschlagen: Verbindung verweigert
klipper(2902) Klipper::loadHistory: Failed to load history resource. Clipboard history cannot be read. : History file does not exist
plasma-desktop(2828)/plasma StatusNotifierItemSource::refreshCallback: DBusMenu disabled for this application
No Nepomuk data found
nepomukbaloomigrator(2887): Communication problem with “nepomukbaloomigrator” , it probably crashed.
Error message was: “org.freedesktop.DBus.Error.UnknownObject” : " “No such object path ‘/MainApplication’” "
Application '/usr/bin/nepomukstorage ’ exited normally…
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
^[[31mvoid DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*)^[[0m: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the networ$
QPixmap::scaled: Pixmap is a null pixmap
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
(process:2959): GLib-CRITICAL **: g_slice_set_config: assertion ‘sys_page_size == 0’ failed
[calBackendLoader] Using libical backend at /home/tzorn/.thunderbird/flwebqnh.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
dolphin(2944)/kdecore (KTimeZone): KSystemTimeZones: ktimezoned initialize() D-Bus call failed: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expire$
I/O warning : failed to load external entity “/home/tzorn/.qalculate/eurofxref-daily.xml”

Die letzten Zeilen im Syslog sehen so aus:
Jan 4 10:02:58 fantasia-pc02 colord: Automatic metadata add icc-a9cb427b01d553c172ba73db863030e8 to xrandr-BenQ-BenQ GL2250-99D05447019
Jan 4 10:02:58 fantasia-pc02 colord: Profile added: icc-a9cb427b01d553c172ba73db863030e8
Jan 4 10:03:04 fantasia-pc02 lightdm: pam_succeed_if(lightdm:auth): requirement “user ingroup nopasswdlogin” not met by user “tzorn”
Jan 4 10:03:09 fantasia-pc02 lightdm: pam_krb5(lightdm:auth): user tzorn authenticated as tzorn@FANTASIA.INTRANET
Jan 4 10:03:09 fantasia-pc02 lightdm: Libgcrypt warning: missing initialization - please fix the application
Jan 4 10:03:09 fantasia-pc02 PAM-runasroot[2181]: continuing as normal user
Jan 4 10:03:09 fantasia-pc02 lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
Jan 4 10:03:09 fantasia-pc02 lightdm: pam_kwallet(lightdm-greeter:session): pam_sm_close_session
Jan 4 10:03:09 fantasia-pc02 lightdm: pam_kwallet(lightdm-greeter:setcred): pam_sm_setsecred
Jan 4 10:03:09 fantasia-pc02 NetworkManager[1093]: error requesting auth for org.freedesktop.NetworkManager.wifi.share.protected: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ‘:1.34’: no such name
Jan 4 10:03:09 fantasia-pc02 colord: device removed: xrandr-BenQ-BenQ GL2250-99D05447019
Jan 4 10:03:09 fantasia-pc02 colord: Profile removed: icc-a9cb427b01d553c172ba73db863030e8
Jan 4 10:03:09 fantasia-pc02 NetworkManager[1093]: error requesting auth for org.freedesktop.NetworkManager.wifi.share.open: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ‘:1.34’: no such name
Jan 4 10:03:09 fantasia-pc02 lightdm[2181]: pam_group(lightdm:setcred): field too long - ignored
Jan 4 10:03:10 fantasia-pc02 kernel: [ 59.133403] FS-Cache: Netfs ‘cifs’ registered for caching
Jan 4 10:03:10 fantasia-pc02 kernel: [ 59.133564] Key type cifs.spnego registered
Jan 4 10:03:10 fantasia-pc02 kernel: [ 59.133584] Key type cifs.idmap registered
Jan 4 10:03:11 fantasia-pc02 lightdm[2181]: pam_unix(lightdm:session): session opened for user tzorn by (uid=0)
Jan 4 10:03:11 fantasia-pc02 lightdm[2181]: pam_ck_connector(lightdm:session): nox11 mode, ignoring PAM_TTY :0
Jan 4 10:03:12 fantasia-pc02 dbus[711]: [system] Activating service name=‘org.freedesktop.UDisks2’ (using servicehelper)
Jan 4 10:03:12 fantasia-pc02 udisksd[2728]: udisks daemon version 2.1.3

Über Rat und Hilfe wäre ich sehr froh.
Torsten


#5

Hallo Leute,

ich beschäftige mich auch seit einigen Tagen mit diesem System. Ich hatte zuvor verschiedene Möglichkeiten ausprobiert (Windows Server, FreeNAS als Domaincontroller usw.), aber bei allen vermisste ich die Möglichkeit die Clients innerhalb weniger Minuten aufzusetzen und ins System zu bringen.

Nun, Univention überzeugt auf den ersten Blick! :slight_smile: Aber… auch ich habe Schwierigkeiten mit den Clients und der Anmeldung. Es ist wie verhext! Dreimal Mal funktioniert es auf Anhieb und beim vierten Mal bleibt das System minutenlang stehen oder es hilft nur noch ein Kaltstart des Clients. Ich habe auch schon alle Logs durchforstet und ähnliche Meldungen wie bei Torsten gefunden, aber nach meiner Recherche, sollen sie “normal” sein?

QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.

Im Syslog steht sonst nix. Auch während der Blackouts wird nix geschrieben und ich habe das Gefühl, dass die Clients immer an einer anderen Stelle des Anmeldevorgangs stehen bleiben.

Hat jemand eine Idee, wo ich noch weiter gucken könnte? Die lokale Anmeldung auf einem Client funktioniert immer, aber sobald sie sich am UCS anmelden sollen, gehen diese seltsamen Probleme los. :-/

Liebe Grüße
Christian


#6

Hallo,

das kann potentiell an der KDE Desktopsuche liegen, die mit dem eingebundenen /home Verzechnissen nicht so gut klar kommt. Testweise kann in den KDE Systemeinstellungen das /home Verzeichnis von der Indizierung ausgenommen werden.

Zusätzlich würde ich mich per root auf dem UCC Client anmelden und zum Beispiel mit ‘top’ untersuchen, welche Prozesse sich während der Benutzeranmeldung problematisch verhalten.


#7

Hallo,
danke für die Antwort.
Tatsächlich war die Desktop-Suche bei den Nutzern “standardmäßig” aktiviert. Ich habe diese nun deaktiviert. Das hat aber leider keine Änderung ergeben.
‘top’ zeigt keine Auffälligkeiten. Während des “äußerlichen” Stillstandes der Rechner Pegeln die Prozesse unter 1%, aber sie wechseln, d.h. sie sind nicht völlig erstarrt, so wie es eben wirkt, wenn man als Nutzer vor dem Rechner sitzt.

Gibt es auch die Möglichkeit, dass sich Univention direkt (also von Ferne) das Problem anschaut? Natürlich gegen Erstattung der Aufwändungen?
Viele Grüße
Torsten


#8

Hallo, ich habe Ihre Anfrage intern weitergeleitet.


#9

Hallo Torsten,

selbstverständlich unterstützen wir da gerne auch direkt. Am Besten besprechen wir die Möglichkeiten einfach einmal telefonisch. Du erreichst mich und meine Kollegen im Vertrieb unter: +49 421 22232-20.
Ich freue mich auf Deinen Anruf!

Viele Grüße,
Ben


#10

Hallo allerseits,

ich bin gerade zufällig auf diesen Thread hier gestoßen, als ich nach Lösungsansätzen für genau das hier beschriebene Problem gesucht habe. (Hatte lediglich nicht “UCC” in meiner Suchanfrage drin, weswegen ich es ein wenig gedauert hat… Auf Seite 3 einer Google-Suche noch was Nützliches zu finden, hat man wohl auch eher selten… ;-))

Wie es aussieht, haben wir vergleichbare Probleme und mein Verdacht fiel ebenfalls auf den Cifs-Mount der Homeverzeichnisse. Ich würde gerne meine Erkenntnisse hier teilen - vielleicht fällt ja jemandem was dazu ein.

Die Symptomatik ist identisch: Die UCCs hängen regelmäßig während und nach der Anmeldung, wobei der allererste Klick auf das Startmenü meistens den Hänger triggert.

Auf der Suche nach “verdächtigen” Prozessen, bin ich auf das hier gestoßen:

2969 ? Ss 0:00 kdeinit4: kdeinit4 Running... 2970 ? S 0:00 \_ kdeinit4: klauncher [kdeinit] --fd=9 2985 ? Sl 0:00 \_ kdeinit4: ksmserver [kdeinit] 3001 ? Sl 0:02 | \_ kwin -session 1013d102111d7000142969199500000026930000_1470116666_651700 3076 ? Sl 0:00 \_ /usr/lib/i386-linux-gnu/indicator-power/indicator-power-service 3082 ? Sl 0:00 \_ /usr/lib/i386-linux-gnu/indicator-bluetooth/indicator-bluetooth-service 3089 ? Sl 0:34 \_ /usr/lib/firefox/firefox 3118 ? S 0:00 \_ /usr/bin/nepomukbaloomigrator 3122 ? D 0:00 | \_ /usr/bin/nepomukbaloomigrator 3135 ? Sl 0:35 \_ /usr/lib/firefox/firefox

3032 ? Sl 0:00 /usr/bin/akonadi_control 3035 ? Sl 0:00 \_ akonadiserver 3041 ? Sl 0:08 | \_ /usr/sbin/mysqld --defaults-file=/home/gy_sprt/lehrer/wendrockl/.local/share/akonadi/mysql.conf --datadir=/home/gy_sprt/lehrer/wendrockl/.local/s 3211 ? D 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_akonotes_resource akonadi_akonotes_resource_0 3212 ? D 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_akonotes_resource akonadi_akonotes_resource_1 3213 ? D 0:00 \_ /usr/bin/akonadi_baloo_indexer --identifier akonadi_baloo_indexer 3216 ? D 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_contacts_resource akonadi_contacts_resource_0 3217 ? D 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_contacts_resource akonadi_contacts_resource_1 3218 ? Sl 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_ical_resource akonadi_ical_resource_0 3219 ? D 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_ical_resource akonadi_ical_resource_1 3220 ? Sl 0:00 \_ /usr/bin/akonadi_agent_launcher akonadi_maildir_resource akonadi_maildir_resource_0 3221 ? D 0:00 \_ /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent 3222 ? D 0:00 \_ /usr/bin/akonadi_migration_agent --identifier akonadi_migration_agent 3232 ? D 0:00 \_ /usr/bin/akonadi_newmailnotifier_agent --identifier akonadi_newmailnotifier_agent 3234 ? D 0:00 \_ /usr/bin/akonadi_notes_agent --identifier akonadi_notes_agent

Auffällig sind 12 Akonadi-Prozesse, von denen 10 den Status “D” haben sowie der nepomukbaloomigrator, ebenfalls mit Status “D”. Der Load-Wert ist bei ziemlich genau 13, was vermutlich kein Zufall ist:

 top - 14:06:08 up  2:49,  4 users,  load average: 13,08, 13,06, 13,05

Ich versuche, Akonadi bei der Anmeldung zu stoppen, aber vermutlich wird der Dienst umgehend wieder gestartet, da wohl auch die Uhr in der Task-Leiste diesen Dienst nutzt.