• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

2 logins übereinander .... geschieht das öfter?!

kohlhz

Member
SuSE 11.2(64)

Heute, 8.3.2010, ca. 15:30, eine für mich völlig neue Situation ...

Zustand vor "Ruhezustand auf Festplatte" ... user-login auf "F7" (deutsch, userspezif. Einstellungen), root auf "F8" (englisch, system default appearence)
Nach Boot aus dem Ruhezustand .. beide user-Fenster liegen "auf F7" übereinander und Teilfenster wechseln einander in wilder Folge ab (engl. / deutscher Anwendungsstarter, ..., Root- und userfenster wechseln einander ab ... Aktivierung des "root"-Logouts wirkt aber auf den "gemeinsamen" Loginprozess.
Da dürften alle Prozesse der beiden Jobs übereinander ausgeführt worden sein. Auf "F8" lag nichts.

... und das in der Fastenzeit ... :irre: :-(

Nach Logout und neuem Login als User sieht jetzt alles ganz normal aus.

Ansonsten ist vor allem ein anderes Fehlverhalten der 11.2 deutlich häufiger als in früheren Versionen zu beobachten - Einfrieren der Maus (ohne Notblinken an der Tastatur), nur Ausschaltknopf möglich, der erwartete 'Neustart' danach ist in der 11.2 oft jedoch ein Wiederhochfahren nach dem letzten regulären Ruhezustand.
 

lOtz1009

Moderator
Teammitglied
Grafischer Login als Root sollte auch tunlichst unterlassen werden.

Nach dem Einfrieren mal in /var/log/messages und /var/log/Xorg.0.log sowie ~/.xsession-errors nach entsprechenden Meldungen schauen.
 
OP
K

kohlhz

Member
lOtz1009 schrieb:
Grafischer Login als Root sollte auch tunlichst unterlassen werden.

Klar, es gibt eine Reihe Gründe dafür, die root-privileges soweit möglich zu meiden und die Textkonsole zu lieben.
Diese Gründe sprechen stark gegen Unix/Linux.
Ein heutiges Betriebssystem sollte ein geeignetes Rechtesystem haben, aber keinen Textmode -
brutale Informatiker wie ich arbeiten soweit möglich so, als ob dies für Linux gälte.
In der 9.3 mußte ich -zigmal restarten und im Single-user-mode agieren, bis mein damaliger Monitor tat ...

lOtz1009 schrieb:
Nach dem Einfrieren mal in /var/log/messages und /var/log/Xorg.0.log sowie ~/.xsession-errors nach entsprechenden Meldungen schauen.

Ja, nach Fehlermeldungen und Warnungen sollte man eigentlich regelmäßig schauen.
Früher hat man jede(!) einzelne ernstgenommen und entweder behoben oder weitergemeldet.
Leider ist das in Linux weder sinnvoll noch möglich - der Normalbetrieb von Linux ist mit so vielen (undokumentierten, kryptischen) Warnungen und Fehlermeldungen gespickt, dass diese in aller Regel ignoriert werden (müssen!).

"HPET not enabled, ((you may) try hpet=force boot option)" - nun, bei einem Monoprocessor dürfte das nicht so wichtig sein, oder?
aber ... kernel: [ 33.815020] Clocksource tsc unstable (delta = -126057903 ns)

"please enable IOMMU option in the BIOS setup" - habe nichts derartiges in meinem BIOS gefunden. Kein Wunder - AMD hat angekündigt, erste Prozessoren mit IOMMU ab 2009, zusammen mit HyperTransport 3.0, auszuliefern. Meine Kiste war 2005 brandneu.
Deshalb auch "EDAC MC: Rev. E or earlier detected.
Was das hier soll, ist mir unklar: "epl: module is from the staging directory, the quality is unknown, ... (systec_epl)"

kernel: [ 185.630473] serial8250: too much work for irq20 ... eine relativ häufige Meldung.

"SMART Prefailure Attribute ..." etc. - naja, meine Kiste ist ein früher "S.M.A.R.T-(Halb-)-Versteher". Diese Meldungen sagen deshalb ziemlich genau nichts, wenn sie etwas sagen, erkennt man nur bei einer ungewöhnlichen Häufung.

Ich sehe keine für mich erkennbar einschlägigen Meldungen.
Hier sind die - hier am ehesten relevanten - Meldungen von SuSE 11.2 (fast unveränderte Standardinstallation) in obigen Files:

Mar 8 16:34:41 linux-c4mo kdm_config[6870]: Multiple occurrences of key 'UseTheme' in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc
Mar 8 16:34:41 linux-c4mo kernel: [ 1524.908882] [drm] Num pipes: 1
Mar 8 16:34:52 linux-c4mo checkproc: checkproc: can not get session id for process 7135!
Mar 8 16:35:01 linux-c4mo python: hp-systray[7102]: warning: hp-systray should not be run as root/superuser.
Mar 8 16:35:01 linux-c4mo python: hp-systray[7102]: error: hp-systray cannot be run as root. Exiting.


kdeinit4: preparing to launch /usr/lib64/kde4/kio_thumbnail.so
*** nss-shared-helper: Shared database disabled (set NSS_USE_SHARED_DB to enable).
kdeinit4: preparing to launch /usr/lib64/libkdeinit4_kbuildsycoca4.so
<unknown program name>(2046)/ KStartupInfo::createNewStartupId: creating: "linux-c4mo;1268061050;836588;2046_TIME0" : "unnamed app"
kbuildsycoca4 running...

(npviewer.bin:3604): Gdk-WARNING **: XID collision, trouble ahead
...
(npviewer.bin:3604): Gdk-WARNING **: XID collision, trouble ahead

(npviewer.bin:3604): Gdk-WARNING **: XID collision, trouble ahead
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 20 (X_GetProperty)
Resource id: 0x22002ef
Xlib: extension "XFree86-Misc" missing on display ":0.0".
X Error: BadAccess (attempt to access private resource denied) 10
Major opcode: 2 (X_ChangeWindowAttributes)
Resource id: 0x360001e
X Error: XSyncBadAlarm 154
Extension: 144 (Uknown extension)
Minor opcode: 11 (Unknown request)
Resource id: 0x0
X Error: XSyncBadAlarm 154
Extension: 144 (Uknown extension)
Minor opcode: 11 (Unknown request)
Resource id: 0x0
Authentication failure
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Unsupported operation (2)": "Invalid model"
...
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"


"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Invalid iterator."
kdeinit4: preparing to launch /usr/lib64/kde4/kio_thumbnail.so
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Unsupported operation (2)": "Invalid model"
...
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Invalid iterator."
"KConfigIni: In file /home/kohl/.kde4/share/apps/RecentDocuments/errs.txt.desktop.lock, line 1: " Invalid entry (missing '=')
"KConfigIni: In file /home/kohl/.kde4/share/apps/RecentDocuments/errs.txt.desktop.lock, line 2: " Invalid entry (missing '=')
"KConfigIni: In file /home/kohl/.kde4/share/apps/RecentDocuments/errs.txt.desktop.lock, line 3: " Invalid entry (missing '=')
kdeinit4: preparing to launch /usr/lib64/libkdeinit4_kwrite.so
kdeinit4: preparing to launch /usr/lib64/libkdeinit4_konsole.so
Cannot register object at /dolphin/Dolphin_1/actions because actions exports its own child objects
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Unsupported operation (2)": "Invalid model"
...
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(3198)" Error in thread 140668421039952 : "Invalid iterator."
kdeinit4: preparing to launch /usr/lib64/libkdeinit4_kwrite.so
 
Bitte verwende in Zukunft code-tags, das ist dann etwas besser zu lesen.

Klar, es gibt eine Reihe Gründe dafür, die root-privileges soweit möglich zu meiden und die Textkonsole zu lieben.
Diese Gründe sprechen stark gegen Unix/Linux.

Da hast Du was falsch verstanden. lOtz warnte vor dem grafischen *login*, also das fahren einer kompletten Sitzung als root. Du kannst auch GUIs als root nutzen, nur eben besser nicht aus einer root-Sitzung heraus, sondern mittels z.B. 'kdesu' innerhalb einer user-Sitzung.

@Thema: ich würde die Meldungen von s.m.a.r.t. ernst nehmen und die Festplatte gründlich überprüfen. Ein Überprüfung des Dateisystems mittles fsck scheint mir ebenfalls angebracht.
 
OP
K

kohlhz

Member
Da hast Du was falsch verstanden. lOtz warnte vor dem grafischen *login*, also das fahren einer kompletten Sitzung als root. Du kannst auch GUIs als root nutzen, nur eben besser nicht aus einer root-Sitzung heraus, sondern mittels z.B. 'kdesu' innerhalb einer user-Sitzung.

Nö, ich meinte das schon so, wie ich das geschrieben habe.
Behelfsaktionen wie oben sind bei kleineren Arbeiten - System-Update etc - durchaus angemessen, ansonsten nervtötend.
Eine Textshell sollte nach meiner Meinung für gar nichts außer der Erstellung größerer Skripts nötig sein, schon gar nicht für den Aufruf einzelner Kommandos.
Alles andere zeigt mangelhafte Userorientierung eines Systems.
Mit Textfenstern habe ich lange genug in Unix gearbeitet, das gehört definitiv in die DV-Steinzeit.

Die Frage ist, ob 2 parallele Jobs nach Ruhezustand in der 11.2 öfter oder regelmäßig so ähnlich reagieren - in der Zwischenzeit habe ich es einmal extra probiert, und es sah so aus.

@Thema: ich würde die Meldungen von s.m.a.r.t. ernst nehmen und die Festplatte gründlich überprüfen. Ein Überprüfung des Dateisystems mittles fsck scheint mir ebenfalls angebracht.

Na gut - zuerst sollte man smartmontools installieren und schauen, ob es bezüglich der smart-Meldungen etwas zum Überprüfen gibt (klar, fsck-en sollte man auch regelmäßig).
Habe ich jetzt gerade getan.
Ohne weitere Informationen sind die smart-Meldungen kontraproduktiv -
es können trotz gutem Plattenzustands sehr, sehr viele smart-Meldungen zusammenkommen, siehe Info-Seite:
http://de.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology#S.M.A.R.T.-Programme_im_Vergleich

Intensiv überprüfen - das hatte ich vor Jahren nach Aktivierung der S.M.A.R.T-Prüfungen in Linux auch getan.
Hat mich ein paar Tage sinnloser Überprüfungen gekostet - fsck's für alle Platten o.k., sonstige Plattentests ohne Fehler, aber etwa gleichbleibende smart-Meldungsdichte.

Geht inzwischen besser.
Habe heruntergeladen und installiert:
http://sourceforge.net/projects/smartmontools/files/smartmontools/5.39.1/smartmontools-5.39.1.tar.gz/download

Erste Überprüfung: Alles im "grünen Bereich".
 
Habe heruntergeladen und installiert:

So was macht man in der Regel mit der Paketverwaltung. Wie genau hast Du die Partitionen überprüft? Man kann sich durchaus auch sehr übersichtliche Ausgaben generieren lassen. Wirft fsck irgendwas interessantes aus?

OT:

[...]
Alles andere zeigt mangelhafte Userorientierung eines Systems.
Mit Textfenstern habe ich lange genug in Unix gearbeitet, das gehört definitiv in die DV-Steinzeit.

Ich glaube, Linux ist nicht so ganz das richtige für Dich.
 
Welche Grafikkarte mit welchem Treiber verwendest Du?
Gdk-WARNING **: XID collision, trouble ahead
wird zwar am häufigsten in Verbindung mit Firefox bei google gelistet, scheint aber ursächlich mit libgtk bzw dessen Zusammenspiel mit der GraKa zusammen zu hängen. Dies könnte auch das Verhalten deines Systems erklären.
 
OP
K

kohlhz

Member
Geier0815 schrieb:
Welche Grafikkarte mit welchem Treiber verwendest Du?
Gdk-WARNING **: XID collision, trouble ahead
wird zwar am häufigsten in Verbindung mit Firefox bei google gelistet, scheint aber ursächlich mit libgtk bzw dessen Zusammenspiel mit der GraKa zusammen zu hängen. Dies könnte auch das Verhalten deines Systems erklären.

Das dürfte es treffen - nach dem Auftreten sieht es so aus, dass es damit zu tun hat.
Zumeist friert das System ein, während ich eine kleine Bewegung des Mauszeigers in einem Fenster mache, während die Darstellung in diesem Fenster verändert wird (oft, nicht immer, eine Folge von schnellen Mausbewegungen und Klicks im Zuge der Bildbearbeitung in Gimp) während der Veränderung der Bildschirmdarstellung Auslöser wäre, was auf Probleme im Interrupthandling hindeutet.
Nur - was genau, und was kann man tun?
Merklich seltener friert das System während der Verwendung von Gimp ein, seit ich den von Speicherplatz von Gimp hochgesetzt habe - Gimp kann aber kaum Ursache des Problems sein, es tritt auch sonst auf - in den letzten Tagen z.B. beim Schreiben einer Antwort hier im Forum.

Dies ist gerade jetzt wieder geschehen.
Nach schnellem Wiederstart war dieser Text noch vorhanden.
Im Info-Panel erscheint in so einem Fall:
"1 kürzlich abgeschlossene Aktion: Prüfung[abgeschlossen] Der Zugriff auf Dateien mittels Protokoll kio_sysinfo ist leider"

Sollte ich einen anderen Treiber verwenden? (radeon ist der standardmäßig vorgeschlagene. radeonhd? Die proprietären Treiber von ATI möchte ich tunlichst vermeiden. die haben mich in der 9.3 das Gruseln gelehrt)

Oder deutet die obige verstümmelte Meldung in eine andere Richtung?

Grafikkarte: Radeon X600 (RV370) 5B62 (PCIE)
Treiber: radeon


P.S.: Natürlich ist Linux nicht das richtige System für mich - aber gibt es Alternativen? MS bietet keine. MacOS ist inzwischen auch Unix mit all dessen Problemen und zudem proprietär - gerade vor kurzem hatte ich das Problem, die X.3.9 zu haben und die X.4 zu brauchen.
Also - ich baue darauf, dass Linux sich weiterentwickelt, und da besonders der Kern (zugegeben eine logistische Herausforderung) und die Benutzungsschnittstelle (ich verfüge zweifellos nicht über das Fingerspitzengefühl, das nötig dafür wäre, die Entwickler zum Entwickeln und Einhalten von Standards zu motivieren. An dieser Stelle könnten Linux-Entwickler sehr, sehr viel von MacOS lernen. Sogar bei zueinander verwandten KDE-Applikationen sind gleichartige Teilleistungen unnötiger- und fehlerträchtigerweise unterschiedlich aufzurufen - einfaches Beispiel: wie Konqueror und Dolphin zueinander widersprüchliche Bedienungsmerkmale auf).
 
OP
K

kohlhz

Member
gropiuskalle schrieb:
Ich glaube, Linux ist nicht so ganz das richtige für Dich.

Diese Aussage freut mich.

Wenn jemand so eine Aussage gemacht hat, und das war in den letzten gut 30 Jahren öfter der Fall, ist das von mir Gewünschte frühestens in der nächsten Version, spätestens 10 Jahre später in Unix (bsd, hp-ux, aix bzw. linux) teilweise oder ganz realisiert gewesen.

Das liegt im übrigen nicht an mir.
Wäre es nicht so, wäre Unix ein Nischenprodukt für jene kleine Minderheit von Fans geblieben, die u.a. zuerst ed, später den zuerst von Unix-Fans strikt abgelehnten vi für den jeweils allerbesten Editor, mail/mailx für unübertreffbar, C für die beste denkbare Programmiersprache, und u.a. X - erst recht darauf aufbauende grafische Systeme! - und Mosaik für sinnlos Ressourcen fressende Spielzeuge gehalten haben.

Unix / Linux wurde bisher immer deutlich besser als das, was Unix-Fans bereits als Idealzustand sahen, und blieb dabei immer deutlich hinter dem zurück, was zu recht gewünscht wurde und möglich gewesen wäre.
 

lOtz1009

Moderator
Teammitglied
Dir ist aber schon bewusst, dass Programme auch grafisch mit Root-Rechten gestartet werden können, ohne dass Root komplett angemeldet sein muss?
 
Wie gesagt:

Da hast Du was falsch verstanden. lOtz warnte vor dem grafischen *login*, also das fahren einer kompletten Sitzung als root. Du kannst auch GUIs als root nutzen, nur eben besser nicht aus einer root-Sitzung heraus, sondern mittels z.B. 'kdesu' innerhalb einer user-Sitzung.

Sprich: es gibt längst eine Lösung, und die ist um einiges bequemer als Dein Ansatz, als root in eine eigene Sitzung einzuloggen. Lies doch erst mal, was man schreibt, bevor Du hier einen auf weitsichtig machst und daraus Unterstellungen ableitest... *kopfschüttel*
 
Sorry, ganz so pampig war das nicht gemeint. Du musst aber zugeben, dass Deine Darstellung von dem, was unter einem System als richtig und gut anzusehen ist, hier vielleicht etwas fehlplatziert ist. Linux basiert nun mal sehr stark auf der Konsole, viele Linuxer *lieben* die Konsole sogar und betrachten die grafischen frontends eher als nützliche Erweiterung der Kommandozeile, weniger als zentralen Bestandteil, und das ist sicherlich nicht unmodern. bash, zsh und Co. sowie die darin ausgeführten CLI-Anwendungen bieten eine komfortable und höchst flexible Arbeitsweise, welche die grafischen Pendants in Sachen Funktionsumfang nicht nur manchmal, sondern sogar fast immer weit übertrifft.

Man kann Linux natürlich auch super mit der GUI steuern, aber wer die Kommandozeile als Prinzip ablehnt, für den ist Linux ganz sicherlich nicht geeignet.
 
OP
K

kohlhz

Member
kdesu habe ich ausprobiert (ich meine, ich hätte dies schon früher mal getan und es damals als unausgereift weggelegt).

Leider habe ich auch diesmal lästige Probleme festgestellt.
"kdesu dolphin" lieferte gelegentlich "Klauncher ist nicht über D-Bus erreichbar. Fehler beim Aufruf von start_service_by_desktop_path: The name org.de.klauncher was not provided by any service files"
"kdesu kwrite" sperrte sich teilweise beim Zurückschreiben von Files, sodaß shell-Commands nötig waren.

Gibt es Lösungen dafür, etwa spezielle Einstellungen?

Es heißt "SuSE-Anwender, denen die Vorgehensweise mit kdesu nicht gefällt, können auch das Programm sux benutzen. Dieses wird bei SuSE standardmäßig installiert und genauso angewendet wie das Programm su." heißt es - aber sux finde ich nicht.

Da ich immer mal eine Reihe Fenster offen habe, ziehe ich es, solange es keine einfache und zuverlässige Alternative gibt vor, root mit wenigen Aktivitäten auf einem Parallel-Login zu fahren, wenn die Nutzung von Shell-Commands zu umständlich erscheint.

Besteht beim Schlafenlegen ("Ruhezustand") ein zweiter, gleichzeitiger Login - z.B. als root - führt das zumindest bei mir seit der 11.2 regelmäßig zu Salat nach dem Wiederaufwachen - die beiden Jobs werden zu einem zusammengesampelt. Das ist - sollte es nicht nur bei mir vorkommen - ein schwerer Fehler der 11.2. In der 11.2 beta 3 gab es das Problem noch nicht.


gropiuskalle schrieb:
Du musst aber zugeben, dass Deine Darstellung von dem, was unter einem System als richtig und gut anzusehen ist, hier vielleicht etwas fehlplatziert ist.

Grübel - soll ich mich wirklich zu einer - hier auch nicht gerade gut plazierten Antwort - provozieren lassen?
Mag sein. Unix nutze ich seit knapp 30 Jahren. Damals sollte ich es u.a. tageweise im Wechsel mit VAX/VMS anbieten, was sich wegen unkalkulierbar hoher Umrüstzeit zu bsd-Unix als unmöglich erwies.

gropiuskalle schrieb:
Linux basiert nun mal sehr stark auf der Konsole, viele Linuxer *lieben* die Konsole sogar ...

Sicher. Seit den 70er-Jahren und seit der PDP 11/40 kenne ich Unix und Unix-Shell-Fans.
5 MB Platte mußten für einen Arbeitsgruppenrechner reichen. Das zwang zu sehr maschinenorientierter Arbeit.
Unix war ein Riesenfortschritt gegen RSX-11, und vi eine Offenbarung für Nutzer des RSX-Editors - aber nur für diese.

Ich hätte gar nichts gegen textuelle Kommandos, aber die Crux an den klassischen Unix-Shell-Commands ist seither eine zu große Maschinen- statt Nutzerorientierung.

gropiuskalle schrieb:
.. welche die grafischen Pendants in Sachen Funktionsumfang nicht nur manchmal, sondern sogar fast immer weit übertrifft.

Sicher - aber das ist zugleich das größte Hindernis für die Weiterentwicklung von Unix-Systemen.
Eine systematische Weiterentwicklung der Nutzerschnittstelle kann allzu leicht vertagt werden.
 
Das ist eine Sichtweise, die grundsätzlich davon ausgeht, dass die CLI unbequemer sei als eine entsprechende GUI-Anwendung - und da kann man auch anderer Ansicht sein. Dies zu diskutieren führt hier aber wohl zu weit, glaube ich (wie hätten da aber noch die Rubrik "Talk" und "Blafasel" im Angebot).

@topic: Deine Probleme kann ich hier nicht nachvollziehen... 'kdesu' macht genau das, was Du willst, nämlich eine Anwendung mit root-Rechten starten; bei mir haut das hin:

Code:
kalle@hoppers:~> kdesu dolphin
kdesu(14671) KDESu::PtyProcess::exec: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/process.cpp : 295 ]  Running "/bin/su"
kdesu(14671) KDESu::SuProcess::ConverseSU: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/su.cpp : 259 ]  Read line "Password: "

[Passwort wird abgefragt]

Code:
kdesu(14700) KDESu::PtyProcess::exec: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/process.cpp : 295 ]  Running "/bin/su"                                                            
kdesu(14700) KDESu::SuProcess::ConverseSU: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/su.cpp : 259 ]  Read line "Password: "                                                       
kdesu(14700) KDESu::PtyProcess::WaitSlave: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/process.cpp : 381 ]  Child pid 14707                                                         
kdesu(14700) KDESu::SuProcess::ConverseSU: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/su.cpp : 259 ]  Read line ""                                                                 
kdesu(14700) KDESu::SuProcess::ConverseSU: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/su.cpp : 259 ]  Read line "kdesu_stub"                                                       
kdesu(14700) KDESu::PtyProcess::exec: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/process.cpp : 295 ]  Running "/bin/su"                                                            
kdesu(14700) KDESu::SuProcess::ConverseSU: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/su.cpp : 259 ]  Read line "Password: "                                                       
kdesu(14700) KDESu::PtyProcess::WaitSlave: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/process.cpp : 381 ]  Child pid 14712                                                         
kdesu(14700) KDESu::SuProcess::ConverseSU: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/su.cpp : 259 ]  Read line ""                                                                 
kdesu(14700) KDESu::SuProcess::ConverseSU: [ /usr/src/packages/BUILD/kdelibs-4.4.1/kdesu/su.cpp : 259 ]  Read line "kdesu_stub"
kalle@hoppers:~>

[Anwendung wird gestartet]

Welche Version von KDE4 fährst Du da? Ich erinnere mich dunkel an einen entsprechenden bug von kdesu, vielleicht hilft eine Aktualisierung schon weiter (muss ja nicht auf KDE4.4 sein, bugfixes werden derzeit über das 'update'-Repo zur 4.3.5 rückportiert, und das würde ich auch grundsätzlich empfehlen).

Besteht beim Schlafenlegen ("Ruhezustand") ein zweiter, gleichzeitiger Login - z.B. als root - führt das zumindest bei mir seit der 11.2 regelmäßig zu Salat nach dem Wiederaufwachen - die beiden Jobs werden zu einem zusammengesampelt. Das ist - sollte es nicht nur bei mir vorkommen - ein schwerer Fehler der 11.2. In der 11.2 beta 3 gab es das Problem noch nicht.

Ich würde Dir nahe legen, zunächst mal das Problem mit kdesu zu lösen, damit dieser Salat gar nicht erst möglich ist. Sollte sich nach einer Aktualisierung immer noch keine Änderung des Verhaltens einstellen, schicke uns doch mal den kompletten output.
 
OP
K

kohlhz

Member
Ich verwende: 11.2(64), alle offiziellen Updates eingefahren, KDE: 4.3.5 (KDE 4.3.5) "release 0"


> @topic: Deine Probleme kann ich hier nicht nachvollziehen... 'kdesu' macht genau das, was Du willst, nämlich eine Anwendung mit root-Rechten starten; bei mir haut das hin:

Aktueller Versuch:
kdesu dolphin
... startet, und es war diesmal sogar möglich, eine Directory (hier: /etc) auszuwählen und eine Datei in /etc mit neuem Namen zu kopieren (neue privileges: -rw-r--r-- owner root).
Teilweise(!) hat bereits die erste Auswahl eines Directories nach Start von dolphin (und Paßwortabfrage) nicht geklappt.

Die Meldung
"KLauncher ist nicht über D-Bus erreichbar. Fehler beim Aufruf von start_service_by_desktop_path:
The name org.kde.klauncher was not provided by any .service files"

kommt diesmal erst, wenn versucht wird, diese Datei im Fenster von kdesu dolphin mit kwrite zu öffnen.
Verständlich, daß die Datei nicht mit vererbter root-Berechtigung geöffnet wird, unbefriedigend, daß dies nichteinmal mit Normalberechtigung geschieht.
Dieselbe Datei wird aus einem "normalem" Dolphin heraus anstandslos mit Kwrite geöffnet.
 
OP
K

kohlhz

Member
Ich verstehe.

Na gut, dann muß man z.B. ggf. erst mal den gesamten Pfad textuell erstellen.
Das Command-Fenster bleibt das zentrale Arbeitsfenster.
Oft genug wird es dann zweckmäßig sein, zwei Fenster aufzumachen - eines im Normal-, eines im Superuser-Mode.
Und bei jedem dieser Fenster muß ich mir merken, ob es Normalmodus- oder Superuser-Fenster ist.

Sicher, das ist ein nützlicher Notbehelf für einfache Fälle - arbeiten im GUI-Mode stelle ich mir doch anders vor.
 
Und bei jedem dieser Fenster muß ich mir merken, ob es Normalmodus- oder Superuser-Fenster ist.

Na, setze doch mal ein wenig Kreativität ein - ich vermeide Verwechslungen, indem ich im KDE-Profil von root ein anderes Farbprofil einstelle, schon sieht man auf dem ersten Blick, welches Fenster zu welchem user gehört.

Ich weiß auch gar nicht, weshalb man laufend als root arbeiten muss (das hört sich bei Dir ein wenig danach an). Administrative Aufgaben sind doch eher die Ausnahme.
 
Oben