Posts by ThomasL

    Nö eigentlich nicht, denn wenn ich eine Erwartungshaltung hätte, dann das. Wenn ich eine Verbesserung will, dann diese. Zeug präziser in ne Textdatei schreiben ist keine Verbesserung. Der Computer weiss doch viel besser was er wann braucht.

    Das hattest Du früher auch nicht.... Du hattest nur einen seriellen Ablauf, ohne Logik, ohne Grips dahinter, einfach nur stur von vorne nach hinten ... und immer auch mit der Gefahr, dass das System stürzt, wenn ein Job stolpert. Ich bestreite nicht, dass es anspruchsvoller geworden ist, aber ich bestreite, dass es schlechter geworden ist. Systemd hat mit seinen Möglichkeiten die Stabilität beim System-Start imho gravierend verbessert.


    Beweise mir, das etwas schlechter ist als zuvor, konkrete Fakten... und zwar, ohne das Versäumnisse des System-Admins die eigentiche Ursache des Problems sind oder dem zugrunde liegen.

    BTW... was immer auch diese Hinweise auf Lennart angeht... man Leute... macht doch mal die Augen auf... unser halbes Linux ist mittlerweile ein Redhat-Linux:

    Pulseaudio

    Wayland

    systemd

    Policykit


    Ich sehe das eher so, dass Red Hat derzeit als einzige unsere Linux-Distris noch richtig weit nach vorne bringt... alles andere stagniert doch. Von Debian kommt doch imho kaum noch Innovation, von Canonical auch nicht... oder kann mich da einer mit besserem Wissen belehren? Ich sehe das so... und das, obwohl ich mit Debian wirklich mein OS gefunden habe und von dem ich total begeistert bin. Aber mittlerweile steckt da imho mehr Fedora als Debian drin.

    ist so pauschal in der Tat falsch.

    Richtig... so pauschal wäre das falsch. Abver ich habe mich wiederholt auf den Zusammenhang mit den generischen service-units aus /etc/init.d bezogen, das war ja auch der Weg, auf den mich DBVs Ansichten geführt hat. Und genau für diese gibt es eben auch nur die generischen Standardabhängigkeiten, die kein spezielles oder individuelles "Warten-auf" beinhalten.

    Natürlich ist es so, dass man mit den passenden Direktiven eine absoute Reihenfolge der Abhängigkeiten vorgeben kann, bis hin zu der Möglichkeit, dass abhängige Jobs gar nicht erst gestartet werden und damit auf Fehler laufen würden, wenn ein vorheriger Prozess abgekackt ist. Aber dafür ist man eben als Systemadmin verantwortlich, das ist nicht Aufgabe von systemd.

    Ja, Du hast mich falsch verstanden. Systemd wartet nicht von sich aus auf abhängige zu startende Jobs, entsprechend einer den vorherigen Job bewertenden Logik. Das wird immer wieder in Anlehnung an die sequentielle Abarbeitung von sysvinit verlangt, aber sysvinit hat das ja auch nicht getan. Systemd startet alles gleichzeitig, sofern nicht konkrete Direktiven gegeben wurden, wie after, before, requires usw.usw. Und alles, was eben nicht konkret festgelegt ist, wird einfach nach gutdünken gestartet, da es ja offensichtlich keine vorgegebenen Abhängigkeiten gibt... wie z.B. bei den generierten service-units, die automatisch bei init.d-Srcipte erstellt werden. Die haben Standard-Dependencies... gerade mit /etc/init.d/networking kann das also nie zuverlässig funktionieren.

    Bei systemd kommt das Totschlagargument:

    Das ist vielleicht gar nicht notwendig sein sollte, das konfigurieren zu müssen wird geflissentlich ignoriert. Ist ja alles besser und bunter jetzt.

    Das ist imho eine falsche Erwartungshaltung... und was die Raspi-Config macht, hat nix damit zu tun, was in der Linux-Welt grundsätzlich von nöten ist. BTW, in der raspi-config wird mit dem Netwait imho schlichterdings nur eine Blockade in der dhcdp-conf eingebaut, was ja vom Grundsatz einer Blockade in einem parallel startenden Init-System geradezu einem Overkill entspricht.... das geht doch gar nicht....


    Sysvinit war ein sequentiell startendes Initsystem. Wenn man da den Start des Netzwerks positioniert hat, hat sysvinit erst weiter gemacht, wenn das Netz durch war, alles musst darauf warten und alle abhängigen Prozesse haben danach natürlich das fertige Netz vorgefunden. Ja, das war wohl so... aber man muss doch zugeben, dass so ein Top-Down-Prozess einfach nur überholt ist, wenn es (heute) eben auch parallel möglich ist. Und ich frage noch mal: Was hat der Start eines Netzwerks (egal ob Wlan oder Kabel) mit dem grundsätzlichen Start eines Betriebssystems zu tun? Meiner Meinung nach genau so viel wie jeder andere Prozess, egal ob Cups, Samba, Dovecot. Das Netzwerk ist nur Ein Prozess, nix mehr, nix weniger. Wenn ein System das Netzwerk für bestimmte Dinge braucht, so ist es Sache des Admins diejenigen vom Netzwerk abhängigen Jobs so zu positionieren, dass diese Jobs funktionieren UND auch damit umgehen können, wenn das Netz noch hängt oder gar nicht verfüßgbar ist. Ich muss doch auch dafür sorgen, dass meine Platten verfügbar sind, wenn ich bestimmte Dirs sharen will. Die zeitliche Abfolge "erst mounten, dann sharen" ist doch meine Verantwortung, ebenso wie ich den Share gar nicht erst versuche, wenn ich die Platte nicht mounten konnte.... dass kann doch nicht systemd's Job sein.... deshalb nicht, weil andere diese Problematik vielleicht gar nicht haben. Auch wenn gewisse Dinge in der sequentiellen Abfolge von sysvinit so waren, so bedeutet das doch nicht, dass man an diesem alten Modell festhalten muss. systemd soll imho einfach nur Dienste starten... sachliche und zeitlich Abhängigkeiten für meine Prozesse muss ICH gewährleisten, das ist nicht Aufgabe von systemd. Das das früher unter sysvinit so war, ist doch allein dem Umstand geschuldet, dass sysvinit ein total schwaches Initsystem war, was einfach nur stur von 1 nach n durchgezählt hat.Und GSD ist das heute eben nicht mehr so.


    Also... ich bin wirklich kein systemd-fan-boy.... ich bin nur erfahren genug, um die gewaltigen Vorteile zu erkennen, die mir systemd mitbringt... im Vergleich zu sysvinit.

    Wo warst du solange? Ich hatte schon Befürchtet du siehst diesen Thread gar nicht - als grosser systemd Befürworter.

    Ich kann Dir was sagen... mir tut alles weh... ich kann kaum geradeaus laufen... die Treppen von oben nach unten hangel ich mich runter, von unten nach oben zieh ich mich rauf....<X;(


    Tja, was ist passiert... ich bin Rentner und musste mal wieder arbeiten.... :cursing:... bin dabei Wände in nem Keller eines Altbaus zu verputzen und Fenster einzubauen... und das als ehemaliger Computer-Fuzzi, der zwei linke Hände hat. :evil:... bin jetzt seit Anfang März für mich selber am malochen.... scheiss Alter, scheiss alte Knochen, scheiss Muskelkater... heute nachmittag hab ich mir dann endlich ne schmerzlindernde Tablette gegönnt... inner 0,5er Flasche, merkwürdiges Medikament mit dem Namen König Pilsener.... aber Medizin soll ja nicht schmecken, nur helfen... und diese Tablette hat meine Laune echt verbessert ^^


    Und mit guter Laune lässt sich schlecht streiten... das ist der Vorteil an solch bewusstseinsverändernden Medikamenten.. die machen gute Laune... *lacht*.. scheiss systemd.... :auslachen: ohjeohjejeh... jetzt krieg ich wieder eine von Frau Meigräfin gewischt, weil ich total unsachlich OT rumlabere..... :saint:

    Das kann ich sehr gut nachvollziehen, der Grund, WARUM ein Service nicht läuft, wenn dem mal so ist, ist (für mich) nicht immer sofort ersichtlich.

    systemd bietet absolut geniale Möglichkeiten zur Fehlersuche, bis hin zur grafischen Anzeige von Abhängigkeiten. Ich habe hier z.B. einen eigenen Prozess "Netfilter", den systemd mir zur Anzeige der sachlichen Abhängigkeiten folgendermaßen anzeigen kann:

    Job

    Code
    Color legend: black = Requires
    dark blue = Requisite
    dark grey = Wants
    red = Conflicts
    green = After

    Oder zur zeitlichen Kontrolle von Abhängigkeiten hier mein Prozess "mountctl.service", der aufs Netzwerk warten muss... was er hier erfolgreich tut:

    Job


    Ich glaube, besser kann man das kaum noch machen... man muss nur wissen, wie man systemd bedient.

    Auch das ist (vermutlich) berechtigte Kritik. Software unnötig aufblähen ist fast nie gut, besonders wenn man sie bei vielen Usern im System verankert.

    Auch das ist imho eine völlig unzutreffende Unterstellung. Zeig mir eine Stelle, auf die die Festellung "aufgebläht" zutrifft. Systemd bringt doch gar nicht nur ein Programm mit, was alles kann, sondern etliche Programme für jeweils eine Aufgabe, die optimal in ein geniales Gesamtkonzept integriert sind. Ich kann da überhaupt nichts falsches dran erkennen. Im Gegenteil, das ist doch endlich mal ein richtig wichtiger Schritt in die Zukunft. Für mich ist sysvinit aus heutiger Sicht einfach nur noch ein lahme Ente mit nur einem Flügel, genau so wie es ist mit sudo und den Prothesen "gksudo" und "ksudo".... auch das sind nur noch Krücken. Für mich ist klar, dass man unter systemd Probleme hat, wenn man an dem alten Scheiss festhält... aber dafür systemd verantwortlich zu machen halte ich für einigermaßen unsachlich.

    Ich finde es absolut genial, weil man damit phänomenale Möglichkeiten hat und richtig gute Kontrolle über seine Prozesse bekommt... weitaus besser, als das mit sysvinit jemals möglich war.


    systemd ist nicht mal in der Lage das System zuverlässig neu zustarten. Da vertrau ich diesem Krebsgeschwür bestimmt keine kritischen Dienste an.

    A stop service is running Waiting x Minutes /infinite

    Hast Du Dich nie gefragt, dass das vielleicht gar kein Systemd-Problem ist, sondern ein reines Customizing-Problem, verursacht durch den verantwortlichen Admin? Mich erinnert das ziemlich deutlich an einen Schaltwagenfahrer, der regelmäßig seinen Automatik-Dienstwagen versemmelt, weil er mit 2 linken Füssen und dem einen fehlenden Pedal nicht klarkommt und dann dem Automatik-Getriebe die Schuld gibt. Das ist doch echter Blödsinn. Und mich erinnert das an die frühen Diskussionen, als die typische Topdown-Programmierung mit C durch die eine eventgesteuerte objektorientierte Programmierung mit C++ abgelöst wurde. Was haben die Leute damals darauf geschimpft... und dabei war objektorientierte Programmierung faktisch der geilste Fortschritt zur damaligen Zeit mitte der 80er.


    Das gleiche Gilt für Startjobs weil systemd einfach drauf los vermutet welche Hardware es denn brauchen könnte anstelle einfach zu starten (z.b. WLAN nicht verfügbar)

    Nein, das ist falsch... eine absolut falsche Erwartungshaltung. Systemd vermutet überhaupt nix. Und systemd hat überhaupt nix damit zu tun oder ist dafür veranwortlich, dass irgendwelche im Kopf des Admins bestehenden imaginären Abhängigkeiten während einer parallel ablaufenden Startphase eingehalten werden. Was hat denn systemd mit der Verfügbarkeit vom WLAN zu tun, wieso sollte sich systemd überhaupt darum scheren? Es ist alleinig Sache des Admins, seine eigenen Jobs sachkundig via Service-Units und unter Berücksichtigung der von ihm festgelegten Abhängigkeiten in den Start-Prozess einzureihen... und das geht mit systemd absolut genial einfach.


    Ich verstehe gar nicht, was da immer von systemd erwartet wird... es soll doch nur Prozesse starten... und zwar nach meinen Abweisungen. Und wieso ist systemd verantwortlich, wenn ich nicht imstande bin, saubere Anweisungen für einen parallelen Start von Prozessen zu formulieren?


    Meine Meinung dazu ist, dbv, lösche einfach ALLE initd-Scripte, die Du noch hast... wirklich alle... einschließlich dieses völlig überflüssigen /etc/init.d/networking. Richte dann für alle zu startenden Jobs passende Service-Units ein, mit entsprechenden Statements für zeitliche und sachliche Abhängigkeiten und alle Deine Probleme sind gelöst. So war es zumindest bei mir. Das krampfhafte Festhalten an die alten sysvínit-Scripte, die unter systemd mehr oder weniger zeitlich zufällig ausgeführt werden, ist imho eine Garantie für Probleme... deshalb, weil sie im Kompatibilitäts-Modus gestartet werden... und da fehlen schlichtweg saubere Angaben zu Abhängigkeiten zu anderen gleichzeitig gestarteten Prozessen. Gibt es diese Angaben für die Startphase des Prozesses, passieren solche "stop-service"-Effekte beim Shutdown definitiv nicht mehr.


    Systemd startet alles mehr oder weniger gleichzeitig, ohne darauf zu warten, dass irgendein Job fertig ist oder von irgendwas anderes abhängig ist. Das ist so gewollt und das ist so genial... das ist ganz einfach "intended working", genau so wie das "Nicht-Schalten-Müssen" ebenfalls "intended working" beim Automatik-Getriebe eines Autos ist. Und bei Problemen damit ist imho nicht das Auto schuld.


    j.m.2.c.

    b) mit Hilfe von systemd und das müsste ich dann in der Konfigurations-Datei machen.

    Nimms mir bitte nicht übel, aber ich kann mir wirklich kaum vorstellen, dass jemand Lust hat, diesen von mir genannten Thread für Dich zu lesen, die relevanten Stellen rauszusuchen und diese dann schön mundgerecht aufbereitet zu servieren. Vergiss besser die Lösung mit Systemd.... die ist vermutlich zu einfach, als das es funktionieren kann... :evil:

    2. Wie kann aus einem Python Script eine Anweisung an systemd gegeben werden, das Script neu zu starten ?

    Das steht in dem genannten Thread beschrieben. Eigentlich ist es nur notwendig, das Programm (quasi als Daemon) via Systemd zu starten. Systemd überwacht den Prozess, wenn er stirbt, wird er automatisch neu gestartet. Also, wie gesagt, systemd kannn sowas schon von Hause aus. Siehe "restart=on-failure" in 'man systemd.service" , um einen gestorbenen Prozess automatisch neu zu starten. Oder alternativ, siehe "OnFailure=" in 'man systemd.unit'. Wie eine passende Service-Unit aussieht, steht im genannten Thread beschrieben.


    Und meine Meinung.... wenn Du so ein 24/7-System betreust und bestimmte Dienste einrichtest, dann gehören Kenntnisse zu systemd zu den zwingend notwendigen Kenntnissen... alles andere ist Autofahren mit rundrum vereisten Scheiben... und ankommen ist dabei Glücksache. Du sollte also schon wissen, wie man ein Programm als Dienst einrichtet und in der Folge die Überwachung von Systemd nutzen kann.

    wobei das Script dann

    mittels Eintrag in /etc/rc.localneu gestartet würde,


    Geht das überhaupt ?

    Gehen tut das, aber es ist die schlechteste Lösung. Starte das Script über eine systemd-service-unit und überlasse systemd die Überwachung. Mit richtiger Einstellung startet systemd den Service automatisch neu, sobald er gestorben ist. Den Rechner zu rebooten ist dafür nicht notwendig. Am Script musst du auch nix ändern, nur die kleine Unit mit etwa 10 Zeilen schreiben.

    Eine komplette Lösung findest du in diesem Thread

    https://debianforum.de/forum/viewtopic.php?f=34&t=168838


    Achte dabei auf scientifics Beiträge, der ist Fachmann für systemd und man kann sich drauf verlassen, dass das korrekt ist.

    Nö, ich habe einem Bekannten auf seinem MSI Wind o.ä. mal diverse Linuxe probiert, Lubuntu lief am besten, die anderen haben ziemlich gehakt.

    Dann erklären mir mal die Unterschiede, die lubuntu performanter machen, als Debian LXDE. Sorry, aber das glaube ich in 100 Jahren nicht.... :P


    Mint? Nun ja, das ist ja nun ne Alternative, die ich nie als Alternative betrachten würde :no_sad:

    Die von dir vorgeschlagene 32bit Version läuft, aber sehr träge. Es läuft aber inzwischen auch die 64 Bit Version von Knoppix 8.1.

    Ich würde dann auch mal die 64bit-Version von Debian versuchen. Wenn der Installer auch erfolgreich läuft, liegt die Problemquelle im lubuntuinstaller. Dann empfehle ich dir bei Debian zu bleiben. Lubuntu ist sowieso keinesfalls die bessere Alternative. Soweit ich mich aber innere, musst du beim Debian-Installer den Expertmodus wählen, um lxde zu installieren. Ich glaube,im Default-Lauf wählt er Gnome.


    Was das 'träge' angeht bin ich davon überzeugt, dass mit keinem der ubuntu-Derivate eine bessere Performance als mit Debian erreichbar ist.

    Hättest Du Lust, aus reiner Neugier mal dieses Image mit win32diskimager auf den Stick zu schreiben und zu prüfen, ob der bis zum Installer bootet?

    https://cdimage.debian.org/deb…an-9.4.0-i386-netinst.iso


    Es ist ein Original-Debian-Iso (Web-Installer mit Firmware), mit dem Du auch eine LXDE-Variante installieren kannst. Wenn das auch nicht geht, wissen wir, dass es nicht am Lubuntu-Iso liegt und man kann sich der nächsten Fehlerquelle widmen.Mich hat bei Deinen Hinweisen irritiert, als Du von PAE gesprochen hast. Physical Adress Extension ist -soweit ich mich erinnere- für 32Bit-Architektur gedacht. Deswegen habe ich jetzt hier mal das 32Bit-Debian gewählt. Irgendwo muss man mal anfangen, Ursachen auszuschließen.


    Wenn 32 Bit bis zum Installer bootet könnte man abbrechen und schauen, ob auch 64 Bit bootet. Wenn dann das 64 Bit-Debian auch nicht bis zum Installer bootet, dann hat man wohl die Quelle der Probleme gefunden:

    https://cdimage.debian.org/deb…n-9.4.0-amd64-netinst.iso

    Genau das habe ich geladen nur nicht win32diskimager benutzt sondern Lili. Aber dort kommt genau die oben genannte Meldung.

    Genau deswegen würde ich mich jetzt erst wieder um ein solches Problem kümmern, wenn es statt mit einem USB-Creator auch mit einem einfachen Image-Schreiber nicht geht. Wie gesagt, versuchs erst mal mit win32diskimager.... für dieses Iso ist ein Bootable-USB-Creator die falsche Wahl.

    M. E. ist der PI der 24/7 eingeschaltet ist, mit einem Laptop aber nicht vergleichbar.

    Der Unterschied besteht aber nur in der subjektiven Betrachtungsweise der Aufgabe, die man dem Pi zugedacht hat. Linux-technisch besteht kein Unterschied. Und wenn die Aufgabe es hergibt, kann man das WLAN auch durchaus deaktiviere.

    und ich frage mich wieso gibt es dann Kommandos für eben diese Fälle.

    Genau dafür ....und die Verwendung ist ziemlich problemlos. Nur kommt mir die Methode des "DOWN ohne die folgenden Aufräumarbeiten ein wenig so vor, als würde man Dir den Barhocker unterm Hintern wegziehen, ohne Dich vorher zu bitten, kurz aufzustehen... *lacht*. Das empfinde ich als "unsauber", weil möglicherweise wpa-supplicant als auch dhclient permanent versuchen, doch noch wieder ans laufen zu kommen. In meinen 3 Zeilen ist möglicherweise aber ein Fehler für Dich enthalten... ich verwende ja nicht diesen fast obligatorischen dhcpcd5... den ich für völlig überflüssig halte.... sondern isc-dhcp-client. Da muss Du ggf. prüfen, wie Du den Daemon zufrieden stellst.