# [gelöst] "su" braucht 100% CPU-Zeit in KDE-Konsole

## Fauli

Bei mir braucht "su" 100% CPU-Zeit, wenn ich Folgendes mache:

KDE-Konsole öffnen

mit "su -" root werden

mit Strg+R und einer Taste einen Befehl aus der History auswählen (kein Enter drücken!)

mit dem "Schließen"-Knopf die KDE-Konsole schließenDer su-Prozess lässt sich dann nur noch mit "kill -9" beenden.

Ist das bei euch auch so?

----------

## Finswimmer

Nö, sollte auch nicht passieren, denn du beendest mit dem "X" Feld die Konsole ganz regulär, wie wenn du Strg+D drückst.

Da ist es eigentlich egal, dass du im History Modus bist.

Leider kann ich dir auch nicht helfen.

Welche Version von konsole und bash hast du denn laufen?

Tobi

----------

## zworK

 *Fauli wrote:*   

> KDE-Konsole öffnen
> 
> mit "su -" root werden
> 
> mit Strg+R und einer Taste einen Befehl aus der History auswählen (kein Enter drücken!)
> ...

 

Tatsache. Nach diesem Vorgehen habe ich einen Prozess mit 99% CPU Last. Jedoch bash und nicht su. Vielleicht ein Bug in der Bash?

Konsole Version ist 1.6.6 aus dem kdebase-3.5.6 Paket. Bash ist in Version 3.1_p17 installiert.

----------

## Finswimmer

Hab beim ersten Mal was falsch gemacht.

Hier tritt es auch auf:

Konsole 3.5.6 aus xeffect Overlay

Bash: 3.2_p10

Tobi

----------

## magicteddy

Moin,

bash 3.1_P17

konsole 1.6.5 

sauber reproduzierbar.

-andreas

----------

## Mr. Anderson

Hier auch mit ~x86

Konsole 1.6.6

bash-3.2_p9-r1

Ich kann su aber mit kill -15 normal beenden.

Interessant:

init hat als Kind kdeinit. Das wiederum hat als Kind Konsole, worin die bash läuft.

Dort führt man nun su - aus. Das ist nun ein Kind der bash - und su bekommt als Kindprozess eine zweit bash.

Schließt man Konsole ist su auf einmal nicht mehr ein Kindprozess der bash, sondern von init.

edit: su, das den Kindprozess bash hat, lässt sich mit SIGTERM schließen, aber der Kindprozess bash nur mit SIGKILL.

edit2: Wenn man Konsole SIGTERM oder SIGKILL schickt, schließt sich alles korrekt. Was passiert denn eigentlich, wenn man auf ein X in der Ecke eines Fensters klickt? Der Window Manager (z. B. KWin) schickt Konsole ein WindowClosingEvent oder so was Ähnliches, oder? Dann müsste Konsole das als Aufforderung zum Beenden auffassen und die bash schließen. Jetzt müsste man in den Code schauen, wie sie das macht.

Übrigens: das Problem ist anscheinend unabhängig von der verwendeten Shell. Das Problem tritt mit der sh genauso auf wie mit der bash.

edit3: Nachdem ich vermutet hatte, dass da irgendwas zu Stande kommt, was nicht erlaubt ist (User versucht Prozess von root zu beenden), habe ich nun festgestellt, dass es völlig egal ist, wer der mit su eingeloggte Benutzer ist. Ich habe mit su mich selbst ein zweites Mal eingeloggt und die Prozesse sind trotzdem verwaist. Ebenso wenn root die Konsole gehört und der Benutzer per su <Benutzer> eingeloggt wird.

(Mehrere Instanzen der bash (also ohne su dazwischen) werden übrigens ohne Probleme geschlossen.)

----------

## Mr. Anderson

das Gleiche passiert mit

xterm -> sh (1) -> su -> sh (2)

----------

## Polynomial-C

Joah, auch hier sauber reproduzierbar...

----------

## Finswimmer

Schon jemand nen Bug Report aufgemacht?

tobi

----------

## Mr. Anderson

 *Finswimmer wrote:*   

> Schon jemand nen Bug Report aufgemacht?
> 
> tobi

 

Ich zumindest noch nicht.

```
USE="-pam" emerge --oneshot shadow
```

Dann ist die zweite Shell direkt ein Kindprozess der ersten Shell und su läuft gar nicht mehr im Hintergrund.

Trotzdem: wenn ich die Konsole schließe, bleibt die zweite Shell als Kindprozess von init übrig und arbeitet mit 100% CPU-Last.

----------

## Fauli

 *zworK wrote:*   

> Nach diesem Vorgehen habe ich einen Prozess mit 99% CPU Last. Jedoch bash und nicht su. Vielleicht ein Bug in der Bash?

 

Wie ich gerade festgestellt habe, ist es bei mir auch die Bash, welche sich aber in der Prozessliste als "-su" tarnt, wenn man "su -" benutzt. Bei "su" ohne "-" sieht man "bash" in der Prozessliste.

Ob es nun an Bash oder Shadow (oder Readline?) liegt, weiß ich nicht. Ich schreibe trotzdem mal einen Bug-Report an bug-bash@gnu.org.

----------

## Mr. Anderson

Grml. Ich nehm das zurück von wegen "es ist egal ob bash oder sh". Ich seh grad, dass die sh bei mir nur ein Symlink auf die bash ist.  :Embarassed: 

Gleich nochmal richtig testen.

Nachtrag: Die Endlosschleife ist tatsächlich in readline. Und zwar wird die Funktion rl_getc in input.c ständig aufgerufen. Während des Schließens wechselt die bash ihren Zustand auch noch. Bevor sie sich aufhängt, versucht sie noch etwa 1.500 Mal sich neu zu zeichnen. Jetzt ist aber wirklich Zeit für Heia. ^^

----------

## firefly

 *Mr. Anderson wrote:*   

> Grml. Ich nehm das zurück von wegen "es ist egal ob bash oder sh". Ich seh grad, dass die sh bei mir nur ein Symlink auf die bash ist. 
> 
> Gleich nochmal richtig testen.
> 
> Nachtrag: Die Endlosschleife ist tatsächlich in readline. Und zwar wird die Funktion rl_getc in input.c ständig aufgerufen. Während des Schließens wechselt die bash ihren Zustand auch noch. Bevor sie sich aufhängt, versucht sie noch etwa 1.500 Mal sich neu zu zeichnen. Jetzt ist aber wirklich Zeit für Heia. ^^

 

ich kenne das phenomen auch, nur das bei mir hierbei der MC dann "verrückt" spielt. Wenn ich aber urxvt(rxvt-unicode) verwende, dann passiert das nicht.

so hier mal eine liste der Terminal Emulatoren, die auf meinen System installiert sind:

kde-base/konsole 3.5.5   -> problem tritt auf

x11-libs/vte 0.14.1          -> problem tritt nicht auf

x11-terms/eterm 0.9.3-r4 -> problem tritt nicht auf

x11-terms/xterm 222     -> problem tritt auf

x11-terms/rxvt-unicode 8.1 -> problem tritt nicht auf

app-shells/bash ist in der version 3.1_p17 installiert

Hmm irgent etwas machen konsole und xterm anders als die anderen Terminal programme.

----------

## Mr. Anderson

Sieht ganz danach aus.

Ich hab inzwischen die Endlosschleife gefunden. Habe jetzt leider keine Zeit mehr. Die Ursache dafür wird später gesucht. ^^

achja: die Endlosschleife ist in isearch.c in der Funktion

```
static int

rl_search_history (direction, invoking_key)

     int direction, invoking_key;
```

das ist die böse:

```
for (;;)

    {

      c = _rl_search_getchar (cxt);

      /* We might want to handle EOF here (c == 0) */

      r = _rl_isearch_dispatch (cxt, cxt->lastc);

      if (r <= 0)

        break;

    }
```

_rl_search_getchar (cxt) liefert da immer -1. Weiter bin ich leider noch nicht gekommen...

----------

## firefly

 *Mr. Anderson wrote:*   

> Sieht ganz danach aus.
> 
> Ich hab inzwischen die Endlosschleife gefunden. Habe jetzt leider keine Zeit mehr. Die Ursache dafür wird später gesucht. ^^
> 
> achja: die Endlosschleife ist in isearch.c in der Funktion
> ...

 

das  _rl_search_getchar (cxt) -1 zurückliefert hat in diesem falle nichts damit zu tun, das diese schleife endlos laufen kann  :Wink: 

sondern die "Problem"-Funktion ist _rl_isearch_dispatch denn die abbruch bedingung ist r <= 0 und r wird von rl_isearch_dispatch "gefüllt"

----------

## Mr. Anderson

 *firefly wrote:*   

> 
> 
> das  _rl_search_getchar (cxt) -1 zurückliefert hat in diesem falle nichts damit zu tun, das diese schleife endlos laufen kann 
> 
> sondern die "Problem"-Funktion ist _rl_isearch_dispatch denn die abbruch bedingung ist r <= 0 und r wird von rl_isearch_dispatch "gefüllt"

 

Dass das c nicht in der Abbruchbedingung steht, seh ich auch  :Razz: 

Zu dem dispatch war ich einfach noch nicht vorgedrungen.  :Wink: 

----------

## Fauli

Chet Ramey (einer der Bash- und Readline-Autoren) hat auf meinen Bug-Report geantwortet: *Chet wrote:*   

> Thanks for the report.  This problem is caused by readline's i-search code
> 
> not handling read errors appropriately.  There were a number of those
> 
> cases in the code; they will all be fixed for the next release.

 

Also setze ich mal ein "gelöst" in den Titel und warte auf das nächste Readline-Release...

----------

## Mr. Anderson

 *Fauli wrote:*   

> Chet Ramey (einer der Bash- und Readline-Autoren) hat auf meinen Bug-Report geantwortet: *Chet wrote:*   Thanks for the report.  This problem is caused by readline's i-search code
> 
> not handling read errors appropriately.  There were a number of those
> 
> cases in the code; they will all be fixed for the next release. 
> ...

 

Na dann kann ich mich ja anderen Dingen widmen. ^^

bleibt aber noch die Frage, warum es bei xterm und Konsole Probleme gibt und bei eterm usw. nicht.

edit: Es heißt xterm, nicht xtrem  :Laughing: 

----------

