Hallo allemiteinander, ich habe ein KDE-Update auf KDE3.0.4 auf meiner SuSE7.2 durchgeführt. Leider gab es dabei einige Probleme. Ich habe die entsprechenden Pakete von SusE-Seite geladen und mit rpm -i --nodeps --force * installiert. Dabei wurde unter anderem /opt/kde3/bin/ angelegt, indem wesentliche Teile des KDE3, unter anderem auch der kdm liegen. Blöder Weise ist /opt/kde3/bin/ aber nicht Teil des Suchpfades geworden, mit der Folge, das der kdm nicht gestartet werden kann bei erreichen des Runlevel 5. Ebenso können die in /opt/kde3/bin liegenden Anwendungen nicht ohne direkte Pfadangabe gestartet werden. Ich habe jetzt in der /etc/init.d/xdm explizit den Pfad eingetragen und in der /etc/profile PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/kde3/bin Soweit scheint alles wieder zu laufen. Trotzdem frage ich mich, was da falsch gelaufen ist. Wo wird denn der Suchpfad global festgelegt? Die Angabe in der /etc/profile alleine genügt nicht, um den kdm beim Hochfahren automatisch zu starten. Gruß Hannes
Am Mon, 02 Dez 2002 schrieb Hannes Vogelmann:
ich habe ein KDE-Update auf KDE3.0.4 auf meiner SuSE7.2 durchgeführt. Leider gab es dabei einige Probleme. Ich habe die entsprechenden Pakete von SusE-Seite geladen und mit
rpm -i --nodeps --force *
installiert.
Aua. Das allein kann schon sehr viel Unheil anrichten, ich hoffe, Du hast vorher genau überlegt, was Du da getan hast.
Dabei wurde unter anderem
/opt/kde3/bin/
angelegt, indem wesentliche Teile des KDE3, unter anderem auch der kdm liegen.
Blöder Weise ist /opt/kde3/bin/ aber nicht Teil des Suchpfades geworden, mit der Folge, das der kdm nicht gestartet werden kann bei erreichen des Runlevel 5. Ebenso können die in /opt/kde3/bin liegenden Anwendungen nicht ohne direkte Pfadangabe gestartet werden. Ich habe jetzt in der /etc/init.d/xdm explizit den Pfad eingetragen und in der /etc/profile
PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/kde3/bin
Soweit scheint alles wieder zu laufen. Trotzdem frage ich mich, was da falsch gelaufen ist. Wo wird denn der Suchpfad global festgelegt? Die Angabe in der /etc/profile alleine genügt nicht, um den kdm beim Hochfahren automatisch zu starten.
/etc/profile wird nur für Login-Shells (bei SuSE über .bashrc auf für alle anderen interaktiven Shells) ausgewertet, nicht für die nicht interaktiven, wie die init-Skripte. PATH sollte zum ersten Mal von init gesetzt werden. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Mon, 02 Dez 2002 schrieb Andreas Feile:
Christoph Maurer, Montag, 2. Dezember 2002 18:32:
rpm -i --nodeps --force *
installiert.
Aua. Das allein kann schon sehr viel Unheil anrichten, ich hoffe, Du hast vorher genau überlegt, was Du da getan hast.
Wie würde es richtig gehen?
Dafür gibt es kein Patentrezept, aber das Prinzip von RPM ist darauf ausgelegt, das die RPM-Datenbank darüber buchführt und weiß welche Pakete installiert sind. Wenn man nun ein neues Paket installieren will, dann bringt das normalerweise die Information mit, welche Pakete es sonst noch benötigt. Wenn da ein Mismatch auftritt, dann installiert RPM das Paket erst mal nicht. Üblicherweise sollte man dann so vorgehen, das man das Problem analysiert, fehlende Probleme evtl. nachinstalliert und dann die Installation startet. Wenn man weiß, was man tut, kann man sich für einzelne Pakete auch mal mit einem nodeps über die Warnung hinwegsetzen (gerade KDE-Pakete bringen IMHO manchmal unnötige Abhängigkeiten mit, bloß weil KDE mit CUPS Unterstützung kompiliert ist, ist KDE IMO z.B: noch nicht von CUPS abhängig). Aber ein --force zwingt das rpm-System sich nicht nur über verletzte Abhängigkeiten, sondern über alle Warnungen hinwegzusetzen (Du könntest Dir auf diese Weise z.B. eine libc auf Dein System spielen, die inkompatibel zu Deinen Anwendungen ist und dann läuft nicht mehr viel). --force würde ich deshalb eigentlich nie, und wenn, dann nur für ausgewählte Pakete, niemals aber in der Form rpm --force * einsetzen. Die Fehlermeldungen, die einen zu --force zwingen, haben in der Regel durchaus einen Sinn und sollten nicht unbedingt mißachtet werden. Also: Bevor man zum großen Hammer greift, würde ich versuchen das dahinterliegende Problem zu lösen. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Montag, 2. Dezember 2002 19:00 schrieb Andreas Feile:
Christoph Maurer, Montag, 2. Dezember 2002 18:32:
rpm -i --nodeps --force *
installiert.
Aua. Das allein kann schon sehr viel Unheil anrichten, ich hoffe, Du hast vorher genau überlegt, was Du da getan hast.
Wie würde es richtig gehen?
Ohne --nodeps und --force! Bei Updates sollte man auch kein -i, sondern ein -U verwenden. Wenn nicht erfüllte Abhängigkeiten angezeigt werden, ist das nicht nur des Spasses halber. Die fehlenden Pakete gehören nachinstalliert. Nur in seltenen Ausnahmen, wenn man genau weiß, was und warum man es tut, kann man die Parameter verwenden. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de
Am Mon, 02 Dez 2002, schrieb Christoph Maurer:
Am Mon, 02 Dez 2002 schrieb Hannes Vogelmann:
ich habe ein KDE-Update auf KDE3.0.4 auf meiner SuSE7.2 durchgeführt. Leider gab es dabei einige Probleme. Ich habe die entsprechenden Pakete von SusE-Seite geladen und mit
rpm -i --nodeps --force *
installiert.
Aua. Das allein kann schon sehr viel Unheil anrichten, ich hoffe, Du hast vorher genau überlegt, was Du da getan hast.
Hintergrund war der, dass ich davon ausging, dass alle von SuSE zum Update auf KDE3 angebotenen Pakete der KDE-Base-Serie diese Abhägigkeiten unter sich erfüllen würden, was sie wohl auch tun. Nur hatte ich keine Lust, mir um die richtige Reihenfolge Gedanken zu machen, nur um den Abhängigkeiten zu genügen. Die Reihenfolge der Installation dürfte doch auch im Endeffekt keine Rolle spielen? Ansich läuft ja auch alles, nur das aufgrund des fehlenden Suchpfades der kdm und die anderen dort befindlichen Anwendungen nicht mehr automatisch laufen.
Dabei wurde unter anderem
/opt/kde3/bin/
angelegt, indem wesentliche Teile des KDE3, unter anderem auch der kdm liegen.
Blöder Weise ist /opt/kde3/bin/ aber nicht Teil des Suchpfades geworden, mit der Folge, das der kdm nicht gestartet werden kann bei erreichen des Runlevel 5. Ebenso können die in /opt/kde3/bin liegenden Anwendungen nicht ohne direkte Pfadangabe gestartet werden. Ich habe jetzt in der /etc/init.d/xdm explizit den Pfad eingetragen und in der /etc/profile
PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/kde3/bin
Soweit scheint alles wieder zu laufen. Trotzdem frage ich mich, was da falsch gelaufen ist. Wo wird denn der Suchpfad global festgelegt? Die Angabe in der /etc/profile alleine genügt nicht, um den kdm beim Hochfahren automatisch zu starten.
/etc/profile wird nur für Login-Shells (bei SuSE über .bashrc auf für alle anderen interaktiven Shells) ausgewertet, nicht für die nicht interaktiven, wie die init-Skripte. PATH sollte zum ersten Mal von init gesetzt werden.
Mit welchem Skript oder Programm kann man das in den init-Skripten eintragen lassen, oder muss ich wirklich sämtliche Einträge von Hand editieren, welche sind das überhaupt, nur die in den autofs-skripten oder gibt es da noch andere? Gruß Hannes
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
Am Mon, 02 Dez 2002, schrieb Christoph Maurer:
Am Mon, 02 Dez 2002 schrieb Hannes Vogelmann:
ich habe ein KDE-Update auf KDE3.0.4 auf meiner SuSE7.2 durchgeführt. Leider gab es dabei einige Probleme. Ich habe die entsprechenden Pakete von SusE-Seite geladen und mit
rpm -i --nodeps --force *
installiert.
Aua. Das allein kann schon sehr viel Unheil anrichten, ich hoffe, Du hast vorher genau überlegt, was Du da getan hast.
Hintergrund war der, dass ich davon ausging, dass alle von SuSE zum Update auf KDE3 angebotenen Pakete der KDE-Base-Serie diese Abhägigkeiten unter sich erfüllen würden, was sie wohl auch tun. Nur hatte ich keine Lust, mir um die richtige Reihenfolge Gedanken zu machen, nur um den Abhängigkeiten zu genügen. Die Reihenfolge der Installation dürfte doch auch im Endeffekt keine Rolle spielen?
Nein, aber wenn Du in das Verzeichnis wechselst, wo die Pakete liegen und dort rpm -U * eingibst, dann sortiert sich rpm die Pakete selbst schon so, das alle gegenseitigen Abhängigkeiten erfüllt werden, danach noch nicht aufgelöste Abhängigkeiten bestehen aber von den neu zu installierenden Paketen zu anderen evtl. tatsächlich fehlenden. Ich würde nicht --force daran gehen.
Ansich läuft ja auch alles, nur das aufgrund des fehlenden Suchpfades der kdm und die anderen dort befindlichen Anwendungen nicht mehr automatisch laufen.
Welche anderen dort befindlichen Anwendungen? Alle KDE-Applikationen?
Dabei wurde unter anderem
/opt/kde3/bin/
angelegt, indem wesentliche Teile des KDE3, unter anderem auch der kdm liegen.
Blöder Weise ist /opt/kde3/bin/ aber nicht Teil des Suchpfades geworden, mit der Folge, das der kdm nicht gestartet werden kann bei erreichen des Runlevel 5. Ebenso können die in /opt/kde3/bin liegenden Anwendungen nicht ohne direkte Pfadangabe gestartet werden. Ich habe jetzt in der /etc/init.d/xdm explizit den Pfad eingetragen und in der /etc/profile
PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/kde3/bin
Soweit scheint alles wieder zu laufen. Trotzdem frage ich mich, was da falsch gelaufen ist. Wo wird denn der Suchpfad global festgelegt? Die Angabe in der /etc/profile alleine genügt nicht, um den kdm beim Hochfahren automatisch zu starten.
/etc/profile wird nur für Login-Shells (bei SuSE über .bashrc auf für alle anderen interaktiven Shells) ausgewertet, nicht für die nicht interaktiven, wie die init-Skripte. PATH sollte zum ersten Mal von init gesetzt werden.
Mit welchem Skript oder Programm kann man das in den init-Skripten eintragen lassen, oder muss ich wirklich sämtliche Einträge von Hand editieren, welche sind das überhaupt, nur die in den autofs-skripten oder gibt es da noch andere?
Was hat das jetzt mit Autofs zu tun? Für Anwendungen, die Du nach dem Einloggen als User starten willst, kannst Du (wie bereits getan) den PATH in /etc/profile(.local) umsetzen und das einzige KDE-Programm, das beim Boot-Prozeß gebraucht wird, ist doch kdm, und da hast Du den Pfad auch gesetzt, das wird auch nicht viel anders gehen als durch explizites Editieren des Startskriptes, der alte Pfad (/opt/kde2/) war da bestimmt auch fest verdrahtet, oder? Du kannst ja wenn Du willst mal in /etc alle Dateien mit Hilfe eines rekursiven grep nach /opt/kde2 durchsuchen. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
Am Mon, 02 Dez 2002, schrieb Christoph Maurer:
Am Mon, 02 Dez 2002 schrieb Hannes Vogelmann:
ich habe ein KDE-Update auf KDE3.0.4 auf meiner SuSE7.2 durchgeführt. Leider gab es dabei einige Probleme. Ich habe die entsprechenden Pakete von SusE-Seite geladen und mit
rpm -i --nodeps --force *
installiert.
Aua. Das allein kann schon sehr viel Unheil anrichten, ich hoffe, Du hast vorher genau überlegt, was Du da getan hast.
Hintergrund war der, dass ich davon ausging, dass alle von SuSE zum Update auf KDE3 angebotenen Pakete der KDE-Base-Serie diese Abhägigkeiten unter sich erfüllen würden, was sie wohl auch tun. Nur hatte ich keine Lust, mir um die richtige Reihenfolge Gedanken zu machen, nur um den Abhängigkeiten zu genügen. Die Reihenfolge der Installation dürfte doch auch im Endeffekt keine Rolle spielen?
Nein, aber wenn Du in das Verzeichnis wechselst, wo die Pakete liegen und dort rpm -U * eingibst, dann sortiert sich rpm die Pakete selbst schon so, das alle gegenseitigen Abhängigkeiten erfüllt werden, danach noch nicht aufgelöste Abhängigkeiten bestehen aber von den neu zu installierenden Paketen zu anderen evtl. tatsächlich fehlenden. Ich würde nicht --force daran gehen.
Aha, das wusste ich nicht, beim nächsten Versuch... ;-)
Ansich läuft ja auch alles, nur das aufgrund des fehlenden Suchpfades der kdm und die anderen dort befindlichen Anwendungen nicht mehr automatisch laufen.
Welche anderen dort befindlichen Anwendungen? Alle KDE-Applikationen?
Alle diejenigen, die in /opt/kde3/bin liegen, das sind allerdings nur die, die durch das upgrade neu installiert wurden. Alle anderen liegen nach wie vor in /opt/bin/kde2/. Ich kann sie ja nun auch starten, nachdem ich den Pfad direkt in die /etc/profile editiert habe. Den Sinn der Schleife (in /etc/profile) test "$UID" = 0 && PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH for DIR in /usr/lib/java/bin \ /var/lib/dosemu \ /usr/games/bin \ /usr/games \ /opt/bin \ /opt/gnome/bin \ /opt/kde2/bin \ /opt/kde/bin \ /usr/openwin/bin; do test -d $DIR && PATH=$PATH:$DIR done test "$UID" = 0 || PATH="$PATH:." export PATH vestehe ich allerdings nicht ganz. Wenn eine Installation etwas dort einträgt, könnte sie es doch gleich in den Pfad eintragen, oder stelle ich mir da irgendwas falsch vor?
/etc/profile wird nur für Login-Shells (bei SuSE über .bashrc auf für alle anderen interaktiven Shells) ausgewertet, nicht für die nicht interaktiven, wie die init-Skripte. PATH sollte zum ersten Mal von init gesetzt werden.
Mit welchem Skript oder Programm kann man das in den init-Skripten eintragen lassen, oder muss ich wirklich sämtliche Einträge von Hand editieren, welche sind das überhaupt, nur die in den autofs-skripten oder gibt es da noch andere?
Was hat das jetzt mit Autofs zu tun?
Nur dort konnte ich PATH-Definitionen innerhalb der /etc/init.d finden.
Für Anwendungen, die Du nach dem Einloggen als User starten willst, kannst Du (wie bereits getan) den PATH in /etc/profile(.local) umsetzen und das einzige KDE-Programm, das beim Boot-Prozeß gebraucht wird, ist doch kdm, und da hast Du den Pfad auch gesetzt, das wird auch nicht viel anders gehen als durch explizites Editieren des Startskriptes, der alte Pfad (/opt/kde2/) war da bestimmt auch fest verdrahtet, oder?
Genau das kann ich eben nicht feststellen, und war daher etwas verwundert. Irgendwas stimmt auch immer noch nicht ganz, denn jetzt habe ich immer zwei kdm-Tasks am laufen, wenn ich nach RL5 ein top eingebe. Ich weiß allerdings nicht, ob das vorher bei KDE2 auch schon so war. Gruß Hannes
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
Ansich läuft ja auch alles, nur das aufgrund des fehlenden Suchpfades der kdm und die anderen dort befindlichen Anwendungen nicht mehr automatisch laufen.
Welche anderen dort befindlichen Anwendungen? Alle KDE-Applikationen?
Alle diejenigen, die in /opt/kde3/bin liegen, das sind allerdings nur die, die durch das upgrade neu installiert wurden. Alle anderen liegen nach wie vor in /opt/bin/kde2/. Ich kann sie ja nun auch starten, nachdem ich den Pfad direkt in die /etc/profile editiert habe. Den Sinn der Schleife (in /etc/profile)
test "$UID" = 0 && PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH for DIR in /usr/lib/java/bin \ /var/lib/dosemu \ /usr/games/bin \ /usr/games \ /opt/bin \ /opt/gnome/bin \ /opt/kde2/bin \ /opt/kde/bin \ /usr/openwin/bin; do test -d $DIR && PATH=$PATH:$DIR done test "$UID" = 0 || PATH="$PATH:." export PATH
vestehe ich allerdings nicht ganz. Wenn eine Installation etwas dort einträgt, könnte sie es doch gleich in den Pfad eintragen, oder stelle ich mir da irgendwas falsch vor?
Der Pfad wird halt in /etc/profile dynamisch zusammengebaut, je nachdem ob bestimmte Verzeichnisse vorhanden sind oder nicht, da Deine 7.2 nichts von kde3 wußte, taucht /opt/kde3/bin da halt nicht auf und muß manuell eingetragen werden. Dabei solltest Du darauf achten, wenn Du jetzt KDE3 benutzen willst, aber noch KDE2 zusätzlich installiert hast, daß kde3 im PATH als erstes auftaucht.
/etc/profile wird nur für Login-Shells (bei SuSE über .bashrc auf für alle anderen interaktiven Shells) ausgewertet, nicht für die nicht interaktiven, wie die init-Skripte. PATH sollte zum ersten Mal von init gesetzt werden.
Mit welchem Skript oder Programm kann man das in den init-Skripten eintragen lassen, oder muss ich wirklich sämtliche Einträge von Hand editieren, welche sind das überhaupt, nur die in den autofs-skripten oder gibt es da noch andere?
Was hat das jetzt mit Autofs zu tun?
Nur dort konnte ich PATH-Definitionen innerhalb der /etc/init.d finden.
Init ist der erste Prozeß, der vom Kernel gestartet wird, Du findest es in /sbin/init. Darin wird der PATH das erste mal gesetzt, siehe auch man init
Für Anwendungen, die Du nach dem Einloggen als User starten willst, kannst Du (wie bereits getan) den PATH in /etc/profile(.local) umsetzen und das einzige KDE-Programm, das beim Boot-Prozeß gebraucht wird, ist doch kdm, und da hast Du den Pfad auch gesetzt, das wird auch nicht viel anders gehen als durch explizites Editieren des Startskriptes, der alte Pfad (/opt/kde2/) war da bestimmt auch fest verdrahtet, oder?
Genau das kann ich eben nicht feststellen, und war daher etwas verwundert. Irgendwas stimmt auch immer noch nicht ganz, denn jetzt habe ich immer zwei kdm-Tasks am laufen, wenn ich nach RL5 ein
top
eingebe. Ich weiß allerdings nicht, ob das vorher bei KDE2 auch schon so war.
Will mich jetzt nicht ausloggen, um zu schauen, wie das bei mir ist, aber poste doch mal die relevanten Zeilen aus /etc/init.d/xdm (so, daß man erkennen kann, wie es ursprünglich war und was Du geändert hast) Mein (8.0) Startskript prüft überigens nacheinander das Vorhandensein von /opt/kde/bin/kdm, /opt/kde2/bin/kdm und /opt/kde3/bin/kdm (in dieser Reihenfolge) und führt dann das letzte gefundene Binary aus. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Der Pfad wird halt in /etc/profile dynamisch zusammengebaut, je nachdem ob bestimmte Verzeichnisse vorhanden sind oder nicht, da Deine 7.2 nichts von kde3 wußte, taucht /opt/kde3/bin da halt nicht auf und muß manuell eingetragen werden.
OK, ich dachte diese Eintragungen würden bei der Installation neuer Anwendungen vorgenommen werden. Klar das es nicht gehen kann, wenn alle Eintragungen nur von der SuSE Installation selbst stammen.
Dabei solltest Du darauf achten, wenn Du jetzt KDE3 benutzen willst, aber noch KDE2 zusätzlich installiert hast, daß kde3 im PATH als erstes auftaucht.
Das müsste eigentlich so sein, da ich vor dem Aufruf der Schleife PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/kde3/bin gesetzt habe. Ich könnte es natürlich auch in die Schleife eintragen, um bei weiteren KDE-upgrades kein Problem zu bekommen.
Init ist der erste Prozeß, der vom Kernel gestartet wird, Du findest es in /sbin/init. Darin wird der PATH das erste mal gesetzt, siehe auch man init
init arbeitet aber doch nur das ab, was in der /etc/inittab zu finden ist und dort wiederum finde ich nur Verweise auf etc/init.d/
Will mich jetzt nicht ausloggen, um zu schauen, wie das bei mir ist, aber poste doch mal die relevanten Zeilen aus /etc/init.d/xdm (so, daß man erkennen kann, wie es ursprünglich war und was Du geändert hast)
Also hier wäre es: case "$DISPLAYMANAGER" in kdm|kde|KDM|KDE) DISPLAYMANAGER=/opt/kde3/bin/kdm PIDFILE="-p /var/run/xdm.pid" test -x /opt/kde/bin/kdm && \ DISPLAYMANAGER=/opt/kde2/bin/kdm ;; gdm|GDM|Gnome|GNOME) DISPLAYMANAGER=/opt/gnome/bin/gdm ;; wdm|WDM) DISPLAYMANAGER=/usr/X11R6/bin/wdm ;; *) DISPLAYMANAGER=/usr/X11R6/bin/xdm ;; esac test ! -x "$DISPLAYMANAGER" && DISPLAYMANAGER=/usr/X11R6/bin/xdm geändert habe ich nur den Pfad in der zweiten Zeile des Auszugs, da stand vorher kde2 statt kde3. Leider kenne ich mich mit der Syntax dieser Skripte zu wenig aus um zu wissen, was ich machen müsste damit der entsprechende Eintrag als alleiniges Ergebnis der Abfrage herauskommt.
Mein (8.0) Startskript prüft überigens nacheinander das Vorhandensein von /opt/kde/bin/kdm, /opt/kde2/bin/kdm und /opt/kde3/bin/kdm (in dieser Reihenfolge) und führt dann das letzte gefundene Binary aus.
so dachte ich mir das. Gruß Hannes
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Dabei solltest Du darauf achten, wenn Du jetzt KDE3 benutzen willst, aber noch KDE2 zusätzlich installiert hast, daß kde3 im PATH als erstes auftaucht.
Das müsste eigentlich so sein, da ich vor dem Aufruf der Schleife
PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/kde3/bin
OK.
Init ist der erste Prozeß, der vom Kernel gestartet wird, Du findest es in /sbin/init. Darin wird der PATH das erste mal gesetzt, siehe auch man init
init arbeitet aber doch nur das ab, was in der /etc/inittab zu finden ist und dort wiederum finde ich nur Verweise auf etc/init.d/
Init arbeitet zwar die /etc/inittab ab, es macht aber auch noch andere Dinge wie z.B. das erste mal den PATH setzen, und zwar auf /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
Will mich jetzt nicht ausloggen, um zu schauen, wie das bei mir ist, aber poste doch mal die relevanten Zeilen aus /etc/init.d/xdm (so, daß man erkennen kann, wie es ursprünglich war und was Du geändert hast)
Also hier wäre es: [...]
Mein (8.0) Startskript prüft überigens nacheinander das Vorhandensein von /opt/kde/bin/kdm, /opt/kde2/bin/kdm und /opt/kde3/bin/kdm (in dieser Reihenfolge) und führt dann das letzte gefundene Binary aus.
so dachte ich mir das.
Okay, der relevante Auszug ist: case "$DISPLAYMANAGER" in kdm|kde|KDM|KDE) PIDFILE="-p /var/run/xdm.pid" DISPLAYMANAGER=/opt/kde/bin/kdm test -x /opt/kde2/bin/kdm && \ DISPLAYMANAGER=/opt/kde2/bin/kdm test -x /opt/kde3/bin/kdm && \ DISPLAYMANAGER=/opt/kde3/bin/kdm ;; Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
init arbeitet aber doch nur das ab, was in der /etc/inittab zu finden ist und dort wiederum finde ich nur Verweise auf etc/init.d/
Init arbeitet zwar die /etc/inittab ab, es macht aber auch noch andere Dinge wie z.B. das erste mal den PATH setzen, und zwar auf /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
Ich dachte eben, man könne genau das einstellen, daher meine Frage.
Okay, der relevante Auszug ist:
case "$DISPLAYMANAGER" in kdm|kde|KDM|KDE) PIDFILE="-p /var/run/xdm.pid" DISPLAYMANAGER=/opt/kde/bin/kdm test -x /opt/kde2/bin/kdm && \ DISPLAYMANAGER=/opt/kde2/bin/kdm test -x /opt/kde3/bin/kdm && \ DISPLAYMANAGER=/opt/kde3/bin/kdm ;;
Gut, so verstehe ich es auch, bei mir sah es aber wirklich so verwurschtelt aus, wie ich es geposted habe. Allerdings passiert genau das gleiche. Ich habe nach wie vor 2 kdm-Prozesse in RL5. Vielleicht kann sich mal jemand äußern, wieviele kdm-Prozesser das bei ihm laufen? Gruß Hannes
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
init arbeitet aber doch nur das ab, was in der /etc/inittab zu finden ist und dort wiederum finde ich nur Verweise auf etc/init.d/
Init arbeitet zwar die /etc/inittab ab, es macht aber auch noch andere Dinge wie z.B. das erste mal den PATH setzen, und zwar auf /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
Ich dachte eben, man könne genau das einstellen, daher meine Frage.
Nein, das ist einkompiliert.
Okay, der relevante Auszug ist:
case "$DISPLAYMANAGER" in kdm|kde|KDM|KDE) PIDFILE="-p /var/run/xdm.pid" DISPLAYMANAGER=/opt/kde/bin/kdm test -x /opt/kde2/bin/kdm && \ DISPLAYMANAGER=/opt/kde2/bin/kdm test -x /opt/kde3/bin/kdm && \ DISPLAYMANAGER=/opt/kde3/bin/kdm ;;
Gut, so verstehe ich es auch, bei mir sah es aber wirklich so verwurschtelt aus, wie ich es geposted habe. Allerdings passiert genau das gleiche. Ich habe nach wie vor 2 kdm-Prozesse in RL5. Vielleicht kann sich mal jemand äußern, wieviele kdm-Prozesser das bei ihm laufen?
Woher hast Du denn die beiden Prozesse? aus top? Und was sagt ps aux dazu. Habe in top auch zwei kdms stehen, wovon einer laut ps aux /opt/kde3/bin/kdm ist, der andere jedoch -:0. Außerdem hab ich noch kdm_greet laufen. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
Gut, so verstehe ich es auch, bei mir sah es aber wirklich so verwurschtelt aus, wie ich es geposted habe. Allerdings passiert genau das gleiche. Ich habe nach wie vor 2 kdm-Prozesse in RL5. Vielleicht kann sich mal jemand äußern, wieviele kdm-Prozesser das bei ihm laufen?
Woher hast Du denn die beiden Prozesse? aus top? Und was sagt ps aux dazu. Habe in top auch zwei kdms stehen, wovon einer laut ps aux /opt/kde3/bin/kdm ist, der andere jedoch -:0. Außerdem hab ich noch kdm_greet laufen.
Ups, da war ich gerade etwas voreilig, es hat sich doch was geändert, habs nur mit top nicht gesehen. Jetzt ist es bei mir auch so wie bei Dir und nach einem init 3 ist der kdm weg. Vorher war nach einem init 3 immer noch einer der beiden kdms da (eigentlich müssten es dann ja 3 gewesen sein #:-? ), ebenso das kdm_greet, sowie X. Jetzt ists aber wirklich aus mit diesem dreiköpfigen Gespenst. Eine Frage schließt da allerdings gleich an: wie ist denn die Ausgabe von -:0 von ps anstelle von kdm bei top zu interpretieren? cu Hannes
* Hannes Vogelmann schrieb am 03.Dez.2002:
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Am Die, 03 Dez 2002 schrieb Hannes Vogelmann:
init arbeitet aber doch nur das ab, was in der /etc/inittab zu finden ist und dort wiederum finde ich nur Verweise auf etc/init.d/
Zumindest die mingettys gibt es auch noch.
Init arbeitet zwar die /etc/inittab ab, es macht aber auch noch andere Dinge wie z.B. das erste mal den PATH setzen, und zwar auf /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
Nö, irgendwie nicht. cat /proc/1/environ
Ich dachte eben, man könne genau das einstellen, daher meine Frage.
Wie Du selber geschrieben hast, arbeitet init die /etc/inittab ab. Nur durch diese Datei kommt es überhaupt zu irgendwelchen anderen Prozessen. Da kanst Du doch für jeden Prozeß den Pfad beliebig setzen. Wenn diese Prozesse wiederum eigene Prozesse erzeugen, dann übernehmen diese Kindprozesse das Enviroment, und somit auch den Pfad vom jeweiligen Elterprozeß. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
* Am Die, 03 Dez 2002 schrieb Bernd Brodesser:
* Hannes Vogelmann schrieb am 03.Dez.2002:
Am Die, 03 Dez 2002, schrieb Christoph Maurer:
Init arbeitet zwar die /etc/inittab ab, es macht aber auch noch andere Dinge wie z.B. das erste mal den PATH setzen, und zwar auf /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
Nö, irgendwie nicht.
cat /proc/1/environ
man init sagt das aber so, verstehe ich im Moment nicht ganz. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
participants (5)
-
Andreas Feile -
B.Brodesser＠t-online.de -
Christoph Maurer -
Hannes Vogelmann -
Manfred Tremmel