Login
Newsletter
Werbung

Thema: Devuan 2.0 »ASCII« veröffentlicht

9 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
4
Von woweil am Di, 12. Juni 2018 um 11:46 #

Ohne ein Downvoting vorzunehmen teile ich Deine Meinung nicht.
Ich habe die Erfahung gemacht, daß systemd teils sehr unflexibel ist.

Beispiel aus dem wirklichen Leben:

Auf der Textkonsole schätze ich im Nichtgrafikmodus (Multiuser nach systemd-Ausdrucksweise) den gpm. Damit kann man bequem copy&paste machen. Zugegebenermaßen Ansichtssache. Nun kann man die Serivedatei für gpm schön konfigurieren, daß er nur im multiusermodus startet.
Jetzt kommt das große Aber: Der grafische Modus braucht den multiusermodus.
Und schon ist der gpm im grafischen Modus gestartet. Ich habe auch noch keine Möglichkeit entdeckt, im grafischen Modus den Start des gpm zu verhindern.
Gut ich könnte einen gpm_stop service einrichten, der im graphical Mode den gpm herunterfährt. Dann wird es aber absurd; wir wären dann faktisch wieder beim sysvinit, der ja zumindest von den Entwicklern arrogant belächelt wird.

Für mich ist eigentlich aus diesem Grunde der systemd ein nogo. Nicht wegen gpm; gpm ist für mich nur ein Symptom der Unausgegorenheit von systemd.
Sowas kann ja auch andere Services betreffen, die mir derzeit nicht bekannt sind und zerstört bei mir deshalb ein gewisses "Vertrauen".

  • 1
    Von Josef Hahn am Di, 12. Juni 2018 um 12:12 #

    Danke für die sachliche Erklärung. Verstehe ich (auch wenn's wohl eher ein exotischer Fall ist).

    Und mit "Conflicts" und "graphical.target" kann man nichts erreichen? Was macht denn gpm im Grafikmodus? Passiert da was Schlimmes, oder stoppt es einfach irgendwie von selbst?

    Ich kenne gpm nur noch aus früheren Tagen...

    • 1
      Von woweil am Di, 12. Juni 2018 um 12:47 #

      Schädlich ist gpm meistens nicht, es gibt auch Fälle, in denen es nicht harmoniert mit dem XServer.
      Aber auch, falles es nicht schädlich ist, sehe ich in solchen erwähnten Verhaltensweisen einen Rückschritt oder auch sogar eine Tendenz zur Primitivierung.
      Und wie gesagt, nicht zu sehr am Beispiel gpm aufhängen, es werden sicherlich auch andere Konstellationen gleichartige Probleme verursachen.

      Und das Themat conflicts kenne ich noch nicht. Das könnte ein Anknüpfungspunkt sein.

    3
    Von name_schon_vergeben am Di, 12. Juni 2018 um 13:05 #

    Ist super simpel zu implementieren. systemd ist in dieser Sicht sogar sehr viel flexibler als das alte sysvinit, da es nicht nur 6 fixe runlevels gibt sondern du dir sogenannte targets anlegen kannst wie du möchtest (targets entsprechen ganz grob den alten runlevels)

    In einem Fall würde ich so vorgehen: Leg ein console.target an, dass multi-user.target reinzieht:
    [Unit]
    Description=Console
    Requires=multi-user.target
    After=multi-user.target rescue.service

    In deinem gpm.service machst du nun
    [Install]
    WantedBy=console.target

    Damit hakt sich gpm service in das console.target beim boot ein und nicht mehr in multi-user.target.

    Beim booten kannst du das neue target auswählen, indem du (siehe man kernel-command-line)
    systemd.unit=console.target and die kernel optionen anwängst
    Wenn du das öfters brauchst, mach dir in grub einen menu eintrag.

    • 1
      Von name_schon_vergeben am Di, 12. Juni 2018 um 13:06 #

      systemctl enable gpm.service
      natürlich nicht vergessen.

      1
      Von woweil am Di, 12. Juni 2018 um 13:21 #

      Das hört sich auch interessant an. Ich habe im Moment nicht das unitfile für gpm da. Aber ich muß dafür unter /etc/systemd/system eine eigene gpm.unit einrichten und noch die Konsole. Was ist da flexibel dran; für solch einen schritt ganz schöner Aufwand. Unter sysvinit wird in der ursprünglichsten Form im betreffenden Runlevel der Link auf /etc/init.d/gpm gelöscht. Ansonsten ging es auch mit chkconfig oder insserv.

      Da kommt noch ein Kritikpunkt hinu: Unter systemd ist alles (unnötigerweise) aufwändiger als unter sysvinit. Also ist dieses Konzept nicht so effizient. Ich kann den Gedanken einfach nicht verdrängen: Ich fühle mich an Windows erinnert, wo viele aufgeblasene Schritte nötig sind, um ein simples Ziel zu erreichen.
      Da ich auch BSD-Systeme administriere, sehe ich zu systemd umsomehr die Gegensätze.

      • 3
        Von name_schon_vergeben am Di, 12. Juni 2018 um 13:34 #

        schon mal versucht ein sysv init skript "korrekt" zu schreiben.
        Das nenne ich aufgeblasen, aufwändig und kompliziert.
        Im vergleich dazu sind .service files eine wahre freude

        1
        Von Karl-Heinz am Di, 12. Juni 2018 um 20:21 #

        Das hört sich auch interessant an. Ich habe im Moment nicht das unitfile für gpm da. Aber ich muß dafür unter /etc/systemd/system eine eigene gpm.unit einrichten

        Nein, Du legst einfach ein Drop-In an und änderst nur das was du ändern must. Das übersteht auch das nächste Dist-Upgrade. ;)

        $ mkdir /etc/systemd/system/gpm.service.d
        $ echo -e "[Install]\nWantedBy=console.target" > /etc/systemd/system/gpm.service.d/nur-console.conf

    1
    Von schmidicom am Mi, 13. Juni 2018 um 10:02 #

    1. Was für sysvinit das runlevel ist, ist für systemd das target. Und die sind sich ähnlicher als viele meinen.
    Working with systemd Targets

    2. Nicht systemd sondern die "[Install]"-Section des Service-Unit entscheidet in welchem Target der Dienst aktiviert/installiert wird. Und dieses Service-Unit kommt, genau wie bei den Initscripten unter sysvinit, nicht vom verwendeten init sondern vom jeweiligen Softwarepaket.
    Kritik ist ja schön und gut sollte aber korrekt Adressiert werden.

    3. Willst du die Standardvorgaben eines vom Paketmanager installierten Service-Unit verändern ist das absolut problemlos möglich und das auch noch, ganz im Gegensatz zu den Initscripten, auf eine Art und Weise die ein Update durch eben diesen Paketmanager überlebt.
    Modifying Existing Unit Files

    Dieser Beitrag wurde 2 mal editiert. Zuletzt am 13. Jun 2018 um 10:08.
Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung