Epoptes Dienst startet nicht mehr

Einige Zeit funktionierte Epoptes einwandfrei. Vor ein paar Tagen ist mir aufgefallen, dass der Epoptes-Dienst nicht mehr startet. Am Lehrerrechner scheitert der Programmstart dann mit der Fehlermeldung “Ein Fehler ist beim Vebinden zum Epoptes-Dienst aufgetreten. Datei oder Verzeichnis nicht gefunden. Stellen Sie sicher, dass der Epoptes-Dienst gestartet ist”. Ergo: Der Dienst läuft einfach nicht…

Ein sudo service epoptes start kann ihn zwar starten, aber das kann man ja keinem Kollegen zumuten :wink:

Auch wenn es bei mir um epoptes (nicht um epoptes-client, wie hier) ging, hatte ich ein update als Auslöser im Verdacht und habe mit sudo apt-get install --reinstall epoptes das Ding nochmal installiert, Image geschrieben - leider erfolglos.

Wie kann ich herausfinden, woran es plötzlich scheitert, dass epoptes beim Systemstart geladen wird?
Zur Not: Kann ich automatisiert ein service epoptes (re)start beim Login/Systemstart auslösen? Wie mache ich das?

Bitte um Hilfe
Grüße Michael

Schick mal die letzten Zeilen von
/var/log/epoptes.log – da müsste ja was zu finden sein. Die Meldung “Datei oder Verzeichnis nicht gefunden ist ja schon mal ein Anhaltspunkt”?!

Welches Update war es bei dir?
(/var/log/apt/history …)

Hallo Michael!

Ich hatte die gleichen Symptome und bei mir war die Ursache der
Kernelupdate - siehe dazu der folgender Auszug aus meiner Doku:

09.12.2016:
epoptes funktioniert mit diesem Image nicht mehr. Beim Booten kann der epoptes-Dienst nicht gestartet werden.
Ursache noch unbekannt. Nach kurzer Zeit kann man den Dienst dann als root starten (# etc/inint.d/epoptes start )
→ zurück zum Image von 15.11.2016
12.12.2016:
Zweiter Versuch mit funktionierender Installation als Basis - gleiches Problem
15.12.2016:
Problem sind die fehlenden Dateien /etc/init.d/epoptes und /etc/init.d/epoptes-client
Beim Update (des Kernels?) werden diese Dateien nicht gefunden und alle Links darauf entfernt
Dadurch wird der epoptes-Dienst nicht mehr gestartet
Lösung: * postsync-Script für Image-Rechner kopiert die Dateien an den richtigen Ort
* image-Vorbereitungs-Script löscht die Dateien wieder

Gruß - Rainer

Hallo Rainer,
deine Analyse passt auf mein Problem. Epoptes selbst wurde im entsprechenden Zeitraum nämlich nicht upgedated - anderes schon (vermutlich auch der Kernel - bin grade nur nicht in der Schule und sehe die history des clients nicht…).

Sehe ich das richtig? Das sieht mir nach einer strukturellen Falle aus, in die früher oder später jeder mal tappen wird… Dann sollte ein Hinweis darauf in die Installationsanleitung zu epoptes, oder?

Zwei Dinge verstehe ich übrigens noch nicht ganz:

  • warum mein sudo apt-get install --reinstall epoptes das Problem dann nicht behoben hat.
  • warum die client-Anwendung weiterhin funktioniert - sobald man epoptes manuell startet, sieht man die clients wieder und kann sie steuern.

Sei’s drum.

Ich probier’s auf jeden Fall demnächst mal so, wie beschrieben: Von funktionierendem Stand ausgehen, vor Kernel-update schauen, dass der linuxadmin die nötigen init.d-Dateien hat. etc.

Soweit danke und Grüße
Michael

Hi Michael,
hast du die Sache lösen können? Falls ja, so wie Rainer es bereits beschrieben hat oder hast du einen anderen Weg genommen/gefunden?
Habe bei uns dasselbe Problem und wollte mich die kommende Woche mal dran machen.
Viele Grüße,
David

Hej David,
habe letztens schon kurz daran gedacht, dass ich an den Thread noch einen Knopf dran machen sollte.
Also: Ja, Rainers Tipp war goldrichtig. Bei uns funktioniert epoptes nun wieder.

Vorgehen:

  • Wir sind zurück auf ein funktionierendes Image,
  • haben dann die Programmdateien von epoptes und epoptes-client in den postsync-Pfad des Imagemasters (Rechner von dem das Image erstellt wird) kopiert.
  • Das Image-Vorbereitungsskript haben wir um die folgenden Zeilen ergänzt

rm -rf /etc/init.d/epoptes
rm -rf /etc/init.d/epoptes-client
rm -rf /etc/default/epoptes-client
rm -rf /etc/default/epoptes
rm -rf /etc/xdg/autostart/epoptes-client.desktop
rm -rf /etc/hosts

rm -rf /usr/bin/epoptes
rm -rf /usr/sbin/epoptes-client
rm -rf /usr/share/applications/epoptes.desktop

  • Erst danach haben wir das Kernelupdate (das war also wirklich “schuld”) und die nötige Clientpflege gemacht.

Das hat geholfen, seither funktioniert es.

Grüße
Michael

Hey Michael,

danke für die schnelle Antwort.
Paar Dinge raffe ich noch nicht so ganz. Bei mir, war bei dir vermutlich auch so, wird mit dem derzeitigen Image wie in der Anleitung beschrieben einiges bereits per postsync auf die Clients kopiert, u.a. auch die init.d-Dateien. Wenn ich das richtig verstehe funktioniert dieses Vorgehen nun nicht mehr, daher die Probleme und deine Lösung.

Dazu ein paar Fragen:

Ist das der /mnt Ordner des Clients?
Dort habt ihr alle Dateien reingelegt, die auch in der Anleitung erwähnt werden, bzw. die ihr unten über das Vorbereitungsskript löschen lasst…?

Damit meinst du das, in meinem Fall, /var/linbo/xenial916.rsync.postsync Skript?

Danke dir schonmal,

viele Grüße,

David

Hast du diesen Thread gelesen? Klingt irgendwie so, als hätte ich das gleiche Problem gehabt?

Hej,

Da liegt der Knackpunkt - es geht um den Client, auf dem Du das Image erstellst (Habe ich vorhin „Imagemaster“ getauft), nicht um einen Rechner im Computerraum.

Klar: per postsync schiebst Du auf alle Schülerrechner im Computerraum die epoptes-client-Anwendung nach und auf den Lehrerrechner die epoptes-server-Anwendung.
Wir machen unsere Images immer von einem Ersatz-Schüler-Rechner. Der hat also auch nur die epoptes-client-Anwendung. Wenn man auf dem Gerät dann ein Kernelupdate durchführt, findet Linux die server-Anwendung nicht und räumt auf…

Du musst also zwei Dinge sicherstellen,

  1. dass der Imagemaster beide Anwendungen hat: epoptes und epotes-client, bevor Du ein Kernelupdate machst
  2. dass die Dateien wieder vom Imagemaster runter sind, bevor Du das Image schreibst.

Wir benutzen ein Shellskript, das vor dem Image-Erstellen ein paar Dateien löscht (Cache-Dateien, Firefox-Profile apt-get autoremove etc.). Das liegt bei uns auf dem Client in /usr/local/sbin und wird vom Linuxadmin vor Imageerstellung ausgeführt.

Weiß jemand, ob / wo das dokumentiert ist?

Grüße
Michael

Ja, hatte ich damals schon gelesen. Ist aber ein anderes Problem…
Die Dummyfiles hatte ich auf dem Lehrerrechner angelegt und das hat soweit auch funktioniert.

Bei mir hat ja mit allerhöchster Wahrscheinlichkeit ein Kernelupdate die Verknüpfungen zur epoptes-server-Anwendung gekappt.

Wundert mich, dass noch nicht mehr Leute in die Falle getappt sind. Eigentlich müsste das früher oder später doch jedem passieren…

Grüße
Michael

Hey Michael,

Ich denke das könnte es sein. Ich habe vor den Updates das Postsync deaktiviert, dann das dist-upgrade laufen lassen, geimaged und das Postsync-Skript wieder rein gehauen. Die Dateien waren nach dem syncen aber nicht da.
Versuche das morgen oder die Tage mal und gebe Rückmeldung.

Eins wundert mich allerdings auch, ähnlich wie du es schon beschrieben hast:
Wenn ich epoptes reinstalliert habe, wurden die Dateien auch nicht mehr angelegt…

Naja, wenn es so gelingt wie du geschrieben hast, dann ist alles in Ordnung.

Vielen Dank und viele Grüße,

David

PS: Werde mir auch ein „Aufräumskript anlegen“, das macht für mich ab jetzt ebenfalls Sinn. Habe bisher vor Imageerstellung immer manuell aufgeräumt :wink:

Hallo,

PS: Werde mir auch ein “Aufräumskript anlegen”, das macht für mich ab
jetzt ebenfalls Sinn. Habe bisher vor Imageerstellung immer manuell
aufgeräumt :wink:

da würde ich mal ins wiki schauen und nach
lmlcc
suchen: das räumt auf Knopfdruck auf: auch Verzeichnisse, die man selber
angibt.

LG

Holger

Hi Holger,

danke für den Tipp. Habe meine Dateien ins lmlcc eingetragen. Sehr komfortabel :wink:
Die Epoptes Dateien sind nach dem Update auch alle da (dann über lmlcc gelöscht), konnte aber die Funktion noch gar nicht testen, da ich nun ein dickes anderes Problem habe, das ich bisher noch nie hatte.

Nachdem ich auf dem Imagemaster alles upgedatet und ausprobiert hatte, habe ich ein neues Image erstellt und wollte das auf die anderen Rechner verteilen. Bis dahin alles gut, allerdings bekomme ich beim Start alle anderen Clients (außer dem Imagemaster, da kann ich syncen, neustarten usw. läuft einwandfrei) eine Fehlermeldung und die Rechner starten nicht mehr.
Die Rechner gehen nach dem PXE Boot ins Linbo und starten neu um das Betriebssystem (Ubuntu) zu starten. Bis dahin alles wie gehabt.
Nun kommt der erste Unterschied zu “vor dem Update”. Die Rechner starten das Grub Menü

!

Wenn Ubuntu starten möchte kommt:

Danach nach Tastendruck oder nach ein paar Sekunden automatisch lande ich auf dem besagten Screen

und nix geht mehr.

Habe bereits versucht: Clients nochmal neu partitionieren, formaieren, syncen usw…
Lande aber immer auf dem Blackscreen mit der Fehlermeldung. Hat irgendetwas mit der UUID zu tun.
Weiß jemand wie ich das beheben kann?
Wie gesagt, der Imagemaster läuft, alle anderen Rechner nicht.

Vielen Dank für eure Hilfe und viele Grüße,

David

Hi David,

schau mal hier:

vG

Danke für die schnelle Antwort,

du meinst ich sollte es mal mit GRUB_DISABLE_LINUX_UUID=true versuchen?
Schaue später mal nach. Danke dir.

Grüße

Hallo,

du meinst ich sollte es mal mit GRUB_DISABLE_LINUX_UUID=true versuchen?
Schaue später mal nach. Danke dir.

ja: das muß sein (in der /etc/default/grub??? )

Und schau in der /etc/fstab
Da dürfen auch keine UUIDs stehen

LG

Holger

Hi,

wollte ja noch kurz Rückmeldung geben. Nach einigen weiteren Problemchen konnte ich heute das Image verteilen. Obiges Problem mit den UUID’s ließ sich mit Holgers Tipp schnell lösen.
Nachdem ich das dist-upgrade laufen ließ und der Kernel 4.4.0-96 installiert wurde konnte ich keinen shutdown und reboot mehr machen, da die Clients hängen blieben. Nach downgrade auf 4.4.0-66 läuft jetzt alles wieder.

Nach Michaels (sedding) Anleitung hat alles wunderbar mit Epoptes geklappt. Per Postsync alle Epoptes Dateien auf einen Imagemaster, dist-upgrade, Aufnahme der Dateien in lmlcc (super Tool, danke für den Tipp Holger) und alles bereinigen lassen, geimaged, verteilt. --> Epoptes läuft.

Danke an alle für eure Hilfe.

Viele Grüße und einen schönen Abend,

David