Posts by ThomasL

    Sind die sowieso vorhandenen Bord-Mittel dafür nicht ausreichend?


    TV auf HDMI-1 ist an:

    Code
    1. $ xrandr | grep connect
    2. HDMI-1 connected (normal left inverted right x axis y axis)
    3. HDMI-2 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm

    TV auf HDMI-1 ist aus:

    Code
    1. $ xrandr | grep connect
    2. HDMI-1 disconnected (normal left inverted right x axis y axis)
    3. HDMI-2 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm

    Jemus  


    Wie dreamshader schon erwähnt hat, der Thread ist uralt. Du solltest einen neuen eigenen Thread öffnen und kurz beschreiben, welche Rahmenbedingungen bestehen, was Du genau erreichen möchtest, also was am Ende rauskommen soll. Und alles so kurz wie möglich beschreiben, aber so umfassend und eindeutig wie nötig... dann kann man sehen, wie man am besten das Problem lösen kann.

    Hat jemand eine Idee woran es liegen kann, dass es auf 2 Rechnern funktioniert und bei den beiden anderen nicht?

    Vielleicht unterschiedliche Schreibweise des Usernamens auf Server und Client...?... versuch mal eine direkten Mount auf der Windows-Maschine, mit expliziter Angabe von user und password.... genau so, wie es auf der Linux-Maschine eingerichtet ist:

    net use x: \\1.1.1.2\ShareName Pwd /user:%USERDOMAIN%\Username /persistent:no


    IP-Adresse, ShareName, Pwd und Username natürlich entsprechend ersetzen.... case-sensitive !!!

    Was haltet ihr für sinnvoll?

    Deutsche Texte in einem deutschsprachigen Forum, englische Texte in einem englischen/internationalen Forum. Manche technischen Texte sind schon in deutsch hoch-anspruchsvoll, da brauch ich jedenfalls nicht noch zusätzliche Hürden durch eine Fremdsprache. Ich schließ mich Flyppo an... englisch *hier* klick ich vermutlich ein wenig verärgert weg... "vermutlich ein wenig verärgert" dann, wenn mich das Thema eigentlich interessiert.

    dbv: systemd mag in Summe komplexer sein. Deswegen muss es aber nicht zwangsläufig schwieriger bzw. unverständlicher zu konfigurieren sein.


    peuler: das mit dem "leichter verständlich" sehe ich in der Tat genau so ...

    Ich finde #metoo-Postings eigentlich total doof... aber diese beiden vorherigen Statements schließe ich mich voll und ganz an.

    Eine farbliche Unterscheidung wäre natürlich mein Favorit, gefolgt von einer Ausgabe in Textform

    Wie soll das gehen? "grep" kennt doch gar nicht die Farbcodes für journald. Soll heissen, Du hast die Journald-Ausgabe nach grep gepiped, siehst also nicht mehr die Ausgabe von Journald, sondern die von grep.


    Damit kommt die Anzeige auch farblich korrekt:

    Code
    1. journalctl -b -p err
    2. journalctl -b -p warning

    Aber es gibt ne bessere Alternative... öffne einfach ein weiteres Fenster und starte dort

    Code
    1. journalctl -f

    Damit siehst Du live alle Meldungen, die Dein Job in dem anderen Fenster produziert... und hier dann auch farblich markiert.


    BTW: Noch'n Tip... das Statement "systemctl enable" solltest Du tunlichst nicht vorher verwenden, bis Du 100% bestätigt hast, dass Service-Unit und Job zweifelsfrei fehlerfrei funktionieren. Sowas sofort in der Startphase zu machen erschwert es Dir nur, Probleme zu beheben. Der Job muss jederzeit OnTheFly mit

    Code
    1. systemctl start jobname
    2. systemctl restart jobname
    3. systemctl stop jobname

    kontrolliert werden können. Und im zweiten Terminalfenster siehst Du immer passend dazu alle Meldungen. Wenn ich im ersten Terminal den Daemon direkt starte:

    Code
    1. $ ./daemon start
    2. thomas@thomaspc:/testbin
    3. $ ./daemon stop
    4. thomas@thomaspc:/testbin

    sehe ich im zweiten Terminal bei vorherigem journalctl -f das hier:

    Code
    1. Apr 18 21:39:47 thomaspc thlu:daemon[6573]: starting
    2. Apr 18 21:39:47 thomaspc thlu:daemon[6577]: started
    3. Apr 18 21:39:47 thomaspc thlu:daemon[6580]: running 1: warte 10 Sekunden
    4. Apr 18 21:39:57 thomaspc thlu:daemon[6586]: running 2: warte 10 Sekunden
    5. Apr 18 21:40:07 thomaspc thlu:daemon[6592]: running 3: warte 10 Sekunden
    6. Apr 18 21:40:09 thomaspc thlu:daemon[6599]: stopping
    7. Apr 18 21:40:09 thomaspc thlu:daemon[6606]: stopped


    Mach ich das gleiche über die Service-Unit (bei mir Type forking) sieht das so aus.... im Terminal 1:

    Code
    1. # systemctl start daemon
    2. root@thomaspc:/testbin
    3. # systemctl stop daemon
    4. root@thomaspc:/testbin

    was dann im Terminal 2 zur folgenden Ausgabe führt:



    Also... wie ich schon sagte... das beste Vorgehen ist, es "direkt" zu testen... und erst wenns wirklich fehlerfrei läuft folgt ganz am Ende der

    Code
    1. systemctl enable servicename

    und ggf. ein Reboot für die Abschlußkontrolle.


    Das hier ist mein "Daemon"-Test-Script, welches bei der Entwicklung der Unit die Aufgabe des späteren Programms übernimmt:||


    Und das ist die Mini-Service-Unit, mit der man mit dem Unit-Type Forking rumbasteln kann....

    Code
    1. [Unit]
    2. Description=Test Daemon
    3. [Service]
    4. Type=forking
    5. ExecStart=/testbin/daemon start
    6. ExecStop=/testbin/daemon stop
    7. [Install]
    8. WantedBy=multi-user.target


    Also.. alles zusammen demonstriert nur, wie ich sowas angehe.... vielleicht findest Du davon etwas hilfreich....

    Das etwas fehlt kann durchaus sein, hab d

    Mittlerweile ist das Log größer, aber eine Unterscheidung welche Meldungsart es ist ist für mich auch noch nicht ersichtlich.

    Doch, das geht... und die Grösse des Journals habe ich begrenzt.... das regelt also journald für mich. Ich verwende

    err

    warning und

    info (siehe oben)


    zur Unterscheidung meiner Meldungstypen

    Die Reihenfolge ist eigentlich egal, ich entwickel und teste nur beides getrennt.


    Und was die Service-Unit angeht, verwende ich dazu eben ein völlig unverfängliches Script, was definitiv fehlerfrei funktioniert.... was ich dann auch mit Log-Einträgen kontrollieren kann. Wie sich die Unit in den Start einreiht, ob das kollisionsfrei ist, ob die sachlichen und zeitlichen Abhängigkeiten passen, kontrolliere ich mit systemd-analyze. Wenn ich sicher bin, dass es so ist, wie ich will, hänge ich das richtige Programm ein. Wenn es dann Probleme gibt, weiss ich, dass es nicht an systemd oder der Unit liegt. Mitterweile habe ich verschiedene dieser Testscripte, die ich in Abhängigkeit des Unit-Types wähle, bis hin zu einem kurzen Testscript, welches sich forken kann... für den Unit-Type "forking".


    Es ist definitiv anspruchsvoller, als früher unter sysvinit, aber auch definitiv weitaus effektiver, mit genialen Möglichkeiten zu absolut 'feinen' Einstellungen.

    Hofei


    Ich habe grundsätzlich ein geteiltes Vorgehen. Zuerst erstelle ich die Service-Unit mit einem Dummy-Programm, danach das eigentliche Programm, welches im root-Terminal mit dem gleichen Eintrag gestartet wird, wie er in der Service-Unit seht. Wenn beides einzeln funktioniert, funktioniert es auch zusammen. Und "sudo" ist bei allen Tests absolut tabu!


    Als Dummy-Programm verwende ich meistens ein Bash-Script, aber ähnliches sollte auch mit Python klappen... ich hoffe mal, dass auch Python direkt ins Journal schreibt.

    Shell-Script
    1. #!/bin/bash
    2. echo "Programm gestartet: User=$USER Param.: 1=$1 2=$2 3=$3" | systemd-cat -t "hofei:$(basename $0)" -p info
    3. exit 0

    Wenn jetzt also auch das Journal aktiviert ist, könntest Du nachsehen, ob das Programm mit Parameter ordentlich aufgerufen wurde. Also, wichtig ist, das Journal zu aktivieren... und wenn man sich mal dran gewöhnt hat, kann man schließlich sogar die alte Leiche "rsyslog" purgen... das Journal ist viel "mächtiger".


    Code
    1. journalctl -b | grep hofei


    Nachtrag:

    Hier liegt noch ein Problem mit der Codedarstellung vor... der Shebang wird nicht angezeigt, obwohl er im Codeblock drin steht..., wie kann das sein?

    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
    1. Color legend: black = Requires
    2. dark blue = Requisite
    3. dark grey = Wants
    4. red = Conflicts
    5. 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.

    cool... so was wie in China das Social Ranking, an dem man ablesen kann, ob man ein ordnungsgemäßer, folgsamer und treuer Staatsbürger ist. :evil:


    Ich persönlich würde mich über die Entscheidung freuen, das nicht zu aktivieren.... ich stehe jedweder Aussage eines EDV-Systems zu Menschen sehr kritisch gegenüber, aus der sich am Ende auch assoziative Bewertungen ergeben können.

    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.