Logout (aus XFCE oder KDE) beendet nicht alle User-Prozesse

Hinweis: In dem Thema Logout (aus XFCE oder KDE) beendet nicht alle User-Prozesse gibt es 18 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Mit einem Script, das ~/.config/autostart/ aufgerufen wird, starte ich mehrere Anwendungen (tcl-Scripte).
    Das Script sorgt dafür, dass, ähnlich der inittab-Funktion "Programm nach dem Beenden neu starten" nach einem Exit oder Kill, das Anwenderprogramm wieder neu gestartet wird.
    Aus einem Terminal heraus gestartet gibt es auch keine Probleme.


    Sobald es jedoch als Autostart-Programm aufgerufen wird, bleiben die Prozesse erhalten, auch wenn der betreffende User abgemeldet ist.
    Beim Wiederanmelden laufen diese dann mehrfach.
    Möglicherweise ist das ein Bug von systemd, denn als Elternprozess nennt pstree systemd(1) .
    So ein Verhalten ist für Linux völlig untypisch und u.U. für Spionage zu gebrauchen.
    >> ein User, der sich anmeldet vertraut auf das System, findet mit who nur sich als User, er bemerkt nicht, dass trotzdem andere User-Programme laufen und arbeitet. "Mein Programm protokolliert .... "
    Das ist nicht so gut!!!!



    Hier ein Script für Autostart:


    #!/bin/bash
    while true
    do
    /usr/bin/xclock
    done


    Je öfter man sich ausloggt und wieder einloggt, um so mehr Uhren hat man.
    ?(?(?(

    Für den Inhalt des Beitrages 132329 haftet ausdrücklich der jeweilige Autor: xterm

  • Das halte ich eher für normal.


    who hat noch nie alle Prozesse eines Users angezeigt.
    systemd "übernimmt" die Elternschaft von Prozessen, wenn die Originaleltern sterben.
    Das gilt für alle Prozesse, die disowned laufen (oder mit nohup gestartet werden).
    Wie damals init auch schon. Auch das ist normal.


    inittab hat keine solche Funktion, wie Starten und nach Kill wieder starten. Dort sind lediglich die Runlevel definiert.
    Es gibt in openSUSE nicht einmal mehr eine /etc/inittab.
    Das alte SysV Init System wird bei systemd von einer Kompatibilitätsschicht emuliert, damit auch alte Programme weiterhin ohne Anpassung laufen können.


    Was du da wirklich treibst, kann man erst sagen, wenn du dieses Script mal postest.
    Ich denke, du verwechselst da ein paar Dinge.
    Wenn du Programme in einer interaktiven Shell aufrufst, "sterben sie" beim Enden der Shell.
    Das tut aber autostart genau nicht.


    Dein anderes Script hier ruft in einer Endlosschleife wieder und wieder xclock auf.
    Die Schleife kann aber nicht enden, weil du xclock im Vordergrund laufen lässt.
    Als Urgestein läuft dann halt xclock einfach weiter - es ist per se von deinem DE unabhängig, da es eben ein "echtes X-Programm" ist.
    Und klar wird nach dem Neuanmelden eine weitere Instanz gestartet.
    Und alle finden sich auf demselben Bildschirm, weil eben wieder DISPLAY:0 verwendet wird...
    ps würde dir das zeigen - who nicht.


    Man kann es natürlich ausnutzen.
    Aber ist das relevant, wenn man sich selbst vorsätzlich in's Knie schießt?
    Dagegen gibt es kein Kraut.


    Es wäre wohl sinnvoller für solche Startjobs einfach ein paar Unitfiles zu schreiben und die Arbeit gleich systemd erledigen zu lassen.
    (systemd tut auch für User, nicht nur für root- Jobs.)


    Wäre meine Vermutung - was du wirklich treibst, weiß ich nicht.

  • du hast mein Anliegen überhaupt nicht verstanden.
    Selbstverständlich gibt es die /etc/inittab nicht mehr. Kann mich aber noch gut an so etwas wie

    respawn :Der Prozess wird jedesmal neu gestartet, sobald er beendet ist. (Typisches Beispiel ist Getty)

    erinnern. "Dort sind lediglich die Runlevel definiert" ist also falsch.


    "Es wäre wohl sinnvoller für solche Startjobs einfach ein paar Unitfiles zu schreiben und die Arbeit gleich systemd erledigen zu lassen."
    Warum sagst du mir das? Der Autostart-Mechanismus wird in den mir bekannten Distributionen SuSE, Manjaro, Mint angeboten. Dort treten die gleichen Effekte auf.
    Autostart, auf die von mir beschrieben Weise einrichten, ausloggen und die laufen unter meiner User-ID weiter.
    Das soll so gewollt sein. Na danke.

    Für den Inhalt des Beitrages 132334 haftet ausdrücklich der jeweilige Autor: xterm

  • Du hast mit der inittab recht. Dort konnte man init konfigurieren, Prozesse zu respawnen.
    (Is mir zu lange her und ich dachte wohl eher an Unix, denn Linux. egal.)


    Dass das Verhalten, das sich dir zeigt "gewollt" wäre, hat niemand behauptet.
    xclock ist nur ein Beispiel für Programme, die sich "anders" verhalten, als man denkt. Es kann auf dem Loginscreen laufen.
    Um deine Vermutung zu belegen, ist das das wohl schlechteste Beispiel. (Noch dazu in einem vorsätzlich dummen Script)


    Und warum manche Prozesse sich ebenfalls nicht so verhalten, wie du verlangst, habe ich angerissen.
    Vielleicht magst du ja doch einmal dein Script posten.


    Warum ich das mit systemd schreibe? Weil systemd am Start ist und das Leben sehr viel leichter machen kann.
    Man muss nicht die althergebrachten Methoden weiterverwenden, nur weil es sie gibt und man sie gelernt hat.
    Dort kann man seine Programme sehr viel feiner konfiguriert starten.
    Das ist heute einfach der "native" Weg. Mit herkömmlichen Scripten ist man halt wieder auf die Rückwärtskompatabilität (für Daemonprozesse) angewiesen. Oder halt auf Autostart. Eine heute überflüssige zusätzliche Schicht.


    Ich denke immer noch, dass du da einiges verwechselst. Und ich habe das nicht einmal nachzustellen versucht.
    Gerade weil eben alle Distris das gleiche Verhalten zeigen, ist das wohl nicht die große Sicherheitslücke, auf die du gestoßen sein willst. Das hätte, wie ich meine, niemals so lange unentdeckt bleiben können. Wenn es denn so wäre.


    Vielleicht magst du ja dein Script doch einmal posten?

  • Gerade weil eben alle Distris das gleiche Verhalten zeigen, ist das wohl nicht die große Sicherheitslücke, auf die du gestoßen sein willst. Das hätte, wie ich meine, niemals so lange unentdeckt bleiben können. Wenn es denn so wäre.


    Kannst du dir vorstellen, das Software in hunderten elektronischer Vermittlunsstellen ohne Probleme über viele Jahre stabil lief, nur in einer liefen die Gebührenzähler manchmal rückwärts? Diese stand auch noch mehrere Tausend Kilometer weit weg und wir konnten daran nicht experimentieren. Es hat 6 Monate gedauert, bis wir den Fehler im Labor reproduzieren konnten. Bis zum "Finden" sind dann noch mal 2 Monate vergangen. Beginnend mit der Fehlermeldung wurden sofort enorme Kapazitäten zur Fehlersuche bereitgestellt.Welchen Schaden die Firma davongetragen hat, wurde uns nie genannt. Die Hektik sagte aber vieles.


    Für mich stellt sich dieser Effekt, dass über die angebotenen Mittel, User-Prozesse ein Logout überleben, als ernsthafter Fehler dar.
    Wer aber will das hier wissen?
    Ich suche hier keine Lösung für irgendein Problem. Deshalb geht aus auch nicht um "althergebrachten Methoden", ich bin seit 10 Jahren Altersrentner, spiele mit Linux (d,h. benutze es, versuche Dinge zu verstehen, schreibe Programme für mich) , nicht mehr.


    In meinem "früheren Leben" war ich einer derer, die Software vor deren Auslieferung getestet haben. Dazu gehörte auch, Dinge zu machen, die der Kunde hätte machen können. Es war erschreckend, was da alles zu Bemängeln war.
    Aus dieser Haut kann und will ich nicht heraus.


    Die Programme (in der Scriptsprache Tcl/Tk ), die bei mir laufen, sind nicht ohne großen Aufwand auf andere Systeme zu übertragen (schon die Erweiterung der Tcl- und der Tk- Library erfordert Wissen oder meine eigenen Tools). Ich will niemanden unterstellen, das nicht zu können, sehe aber keinen Grund, nicht alles so weit zu reduzieren, dass man es sofort versteht.


    So ein stark reduziertes Script habe ich genannt dort aber /usr/bin/xclock eingetragen weil man das dann auch auf dem Monitor sieht.
    Dafür kann aber jedes andere Programm oder Script stehen.


    Getestet habe ich es auch mit /usr/bin/sleep 2 , was natürlich keinen Sinn macht. Ich kann aber damit zeigen, dass es nach dem Logout von der grafischen Oberfläche (bei mir XFCE) weiter läuft.
    <Ctrl><Alt><F1>
    login root


    ps -Af |grep ^<username>
    <username> 8234 6550 0 09:22 pts/1 00:00:00 sleep 2


    Für <username> gibt es nur 2 Prozesse, den des Scripts und den mit sleep, er sollte also definitiv irgendwo noch eingeloggt sein.


    Würde man sleep (oder wie oben xclock) durch ein Script ersetzen, das alle Prozesse eines bestimmten Users erkennt und speichert ....
    Das ist dann schon Spionage, die ein anderer erst einmal nicht erkennt.

    Für den Inhalt des Beitrages 132340 haftet ausdrücklich der jeweilige Autor: xterm

  • Ich schätze einmal, das du dann ein Script schreiben muss, was dein erststes Script bei der Abmeldung killt.
    Autostart

    Für den Inhalt des Beitrages 132341 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Es war noch nie richtig in keiner Unix oder Linuxversion, dass ein Userprozess nur dann existieren könne, wenn ein Login damit assoziert ist. Wie könnte sonst ein screen dettached laufen? Wie ein SSH Tunnel?
    Es gibt sehr viele Prozesse, die ohne Login laufen.


    Und nochmal:
    Solange du nicht postest, was du da wirklich treibst, bleibt deine Behauptung fragwürdig.
    Ich glaube nach wie vor, dass du Chimären jagst.


    Außerdem gibt es Leute, die sehr wohl Tickle noch können.
    Manche sollen sogar immer noch reine Tcl Bots im IRC für das einzig Wahre halten.
    Du kannst dein Zeuchs also ruhig posten und es dem Leser überlassen, ob der dem folgen kann.

  • Hat wohl noch keiner bemerkt, das sich der Beitrag unter "Lob, Kritik und Vorschläge" befand? ðđ

  • Da darf man dann nicht antworten?

    Doch, und dumme Fragen stellen darf man auch. So bekommt man seinen Beitragszähler auch nach oben geschraubt.


    @xterm
    Bitte darauf achten, wo du etwas postest.