Samba Shares werden nicht angelegt

german

#1

Hallo,

aktuell haben wir folgendes Problem:

System: UCS 2.4.2-5

Nach dem Anlegen eines Samba-Shares im UDM wird diese nicht auf das Dateisystem geschrieben.

Das einzige was dabei ins Log geschrieben wird ist folgendes:
24.10.11 11:18:15 TRANSFILE ( WARN ) : ERROR Could not get lock for file [/var/lib/univention-ldap/listener/listener.lock]; count = 0

Erst nach einem ‘univention-directory-listener-ctrl resync samba-shares’ ist die Share dann verfügbar.

Ist hierzu etwas bekannt? Wie können wir dem Problem auf die Schliche kommen?

Vielen Dank im Voraus für jegliche Hilfe
Grüße, ckorn


Druckerfreigabe auf 3 UCS-Servern
#2

Hallo,

für eine nähere Analyse wären weitere Informationen hilfreich. Sie können hierzu einmal den Debuglevel des Univention Directory Listener auf dem DC Master erhöhen und anschließend erneut einen Share anlegen. Evtl. lassen sich dadurch in der Log-Datei /var/log/univention/listener.log erweiterte Meldungen erzeugen die weitere Hinweise auf das Problem liefern. Beachten Sie bitte dass der Debuglevel nach dem Test wieder herabgesetzt werden sollte.

# ucr set listener/debug/level=4
# /etc/init.d/univention-directory-listener restart

Mit freundlichen Grüßen
Murat Odabas


#3

Guten Tag Herr Odabas,

ich bin ein Kollege von Herrn ckorn. Da er momentan nicht Antworten kann, übernehme ich diese Aufgabe.

Der Debuglevel war bereits auf 5 gesetzt. Zum Test haben wir ihn auf 4 gestellt. Leider beschränken sich die Logfiles weiterhin auf das bekannte

31.10.11 13:28:43  TRANSFILE   ( WARN    ) : ERROR Could not get lock for file [/var/lib/univention-ldap/listener/listener.lock]; count = 0

Gibt es noch weiter Dinge, die wir ausprobieren könnten?

Vielen Dank für Ihre Hilfe.
Grüße,iKu_Systems


#4

Hallo,

die von Ihnen gepostete Meldung besagt das der Univention Directory Listener versucht einen Lock anzulegen der aber fehlschlägt. In der Regel müssen im Debuglevel 4 weitere Meldungen in der Listener.log zu finden sein. Können Sie bitte nochmal folgendes durchführen:

  • Listener anhalten:
# /etc/init.d/univention-directory-listener stop
  • Prüfen ob der Listener wirklich nicht mehr läuft:
# ps aux | egrep listener
  • Falls der Listener weiterhin läuft, kann es mit kill beendet werden:
# kill $(pidof univention-directory-listener)
  • Listener Debuglevel auf 4 setzen:
# ucr set listener/debug/level=4
  • Listener wieder starten
# /etc/init.d/univention-directory-listener start

Anschließend erneut einen Samba-Share über den UDM anlegen und die listener.log hier posten. Alternativ können Sie die Log-Datei auch an feedback@univention.de senden.

Weiterhin wäre es noch hilfreich zu erfahren welche Umstände evtl. zu diesem Verhalten geführt haben. Seit wann ist dieses Verhalten zu beobachten (evtl. nach einem Update, o.a.)? Wo liegen die Shares und werden im Verzeichnis
/etc/samba/shares.conf.d/ die entsprechenden Konfigurationsdateien erstellt?

Mit freundlichen Grüßen
Murat Odabas


#5

Hallo Herr Odabas,

wie von Ihnen beschrieben habe ich erneut den Loglevel auf 4 gestellt und einen Samba-Share angelegt. Der listener.log bleibt jedoch wie zuvor unberührt.

Die Shares liegen unter /var/samba, dort werden die entsprechenden Ordner jedoch nicht angelegt. Weiterhin werden keine Konfigurationsdateien für die Shares unter /etc/samba/shares.conf.d/ angelegt.

Ab wann genau dass Problem aufgetreten ist, lässt sich leider nicht zurückverfolgen. Nach Rücksprache mit einigen Kollegen kann ich nur weitergeben, dass zwischenzeitlich auch Updates eingespielt worden sind.

Grüße,
iKu_Systems


#6

Hallo,

wie bereits von meinem Kollegen erwähnt müsste es hier, gerade nach dem Listener Neustart, deutlich mehr Meldungen in der listener.log geben. Wurde der Listener vom Init-Script korrekt beendet oder haben Sie den Prozess manuell beendet? War er anschließend wirklich aus?

Mit freundlichen Grüßen
Janis Meybohm


#7

Hallo Herr Meybohm,

wie von Herrn Odabas vorgegeben habe ich versucht, über das Init-Skript den Listener zu stoppen. Nach erneutem prüfen lief der Listener jedoch noch, sodass ich Ihn mt einem

# kill $(pidof univention-directory-listener)

beendet habe.
Danach habe ich, wie beschrieben, den Loglevel erhöht und weitere Shares angelegt, leider ohne erfolg.

Grüße,
iKu_Systems


#8

Hallo,

haben Sie nach dem “kill” überprüft ob der Dienst tatsächlich beendet war? Evtl. lief er dann noch immer, was erklären würde warum nicht geloggt wird.

Mit freundlichen Grüßen
Janis Meybohm


#9

Hallo Herr Meybohm,

bitte entschuldigen Sie die fehlende Angabe.
Ich habe natürlich nach dem ausführen des “kill” nochmals überprüft, ob der Dienst beendet war. Dies war der Fall.

Grüße,
iKu_Systems


#10

Hallo,

ich denke für eine generelle Übersicht wäre es hilfreich wenn Sie uns (z.B. über sdb.univention.de/1174 zukommen lassen könnten. Bitte geben Sie außerdem an wann das Debuglevel erhöht bzw. der Listener neu gestartet wurde und wann versucht wurde einen Share anzulegen.

Mit freundlichen Grüßen
Janis Meybohm


#11

Hallo,

Ich habe das gewünschte Support Info-Archiv an feedback@univention.de geschickt. Wann was geändert wurde, ist ja hier im Forum ersichtlich. Lassen Sie uns wissen falls sie noch genauere Informationen brauchen.

Danke und Grüße
iKu_Systems


#12

Hallo,

Ich habe die Logdateien des Systems einmal überprüft.
Ich würde vermuten hier bisher die falsche Logdatei kontrolliert wurde. Die Initial angegebene Log-Meldung (ERROR Could not get lock for file…) lässt sich nur in der /var/log/univention/notifier.log finden. Die /var/log/univention/listener.log ist, wie bei Debuglevel 4 zu erwarten, mit diversen Meldungen gefüllt.

Die Beschriebenen Probleme sind darauf zurück zu führen dass die Notifier-ID (1991) auf dem System deutlich kleiner ist als die Listener-ID (2859). Der Listener wird somit Änderungen des Notifier ignorieren, da er davon ausgeht, diese bereits durchgeführt zu haben.
Generell kann dieser Zustand so nicht eintreten, ich würde daher vermuten dass ein volles Dateisystem, die Rücksicherung aus Backups, eine unvollständige Migration des Systems auf andere Hardware/Virtualisierung o.ä dieses Problem verursacht haben.

Die Datei /var/lib/univention-ldap/notify/transaction sollte alle Transaktion des Notifiers enthalten, wobei in der ersten Spalte die fortlaufende Notifier-ID geführt wird. Die Anzahl von Zeilen (“wc -l /var/lib/univention-ldap/notify/transaction”) in der Datei sollte daher immer der ID in der letzten Zeile entsprechen (“tail -n1 /var/lib/univention-ldap/notify/transaction”). Weitere Informationen zur Listener/Notifier-Replikation finden Sie in dem Dokument UCS Domänenkonzept.

Eine nähere Analyse der Umstände die zu diesen Problemen geführt haben, sowie die Ausarbeitung eines entsprechenden Lösungsweges, kann nicht im Rahmen der kostenlosen Unterstützung hier im Forum erfolgen. Ich würde Sie daher bitten sich diesbezüglich mit unserem Vertrieb (Telefonisch über +49 421 2223220 oder per Mail: vertrieb@univention.de) in Verbindung zu setzen, dieser wird Ihnen die Möglichkeiten und Angebote für eine weitere Unterstützung gerne erläutern.

Mit freundlichen Grüßen
Janis Meybohm