[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SOLVED] Hilfe! Maus tot, Tastatur tot in X



Hallo Manfred,

On 22.03.2012 01:41, Manfred Schmitt wrote:
[...]
Wie viele Prozesse laufen ist, wie es ja schon mehrfach hier im thread
erwahent wurde, voellig irrelvant wenn es nur einen Hauptprozess mit
Unterprozessen gibt. Hier in Squeeze laeuft z.B ein udevd mit aktuell
zwei Unterprozessen, mag sein das es in wheezy mehr sind.
Schau halt mal z.B. in htop in der Baumansicht oder mit pstree -p nach
ob da wirklich mehrere Daemonen laufen.

pstree -p auf meinem funktionierenden Wheezy System sagt zu udev folgendes:

 ├─udevd(302)─┬─udevd(1547)
        │            └─udev d(1876)
        ├─udevd(1345)─┬─udevd(1494)
        │             └─udevd(1875)
In Wheezy habe ich nicht bewußt Änderungen in dem Bereich vorgenommen, da wird ein Prozess in rc2.d aufgerufen, ohne merklichen Schaden anzurichten.

von dem SQUEEZE tower kann ich es eigenartigerweise (über ssh) nicht hierher kopieren:
--udevd(491)─┬─udevd(598)
                       └─udevd(1530)
also ein Hauptprozess mit zwei Kindprozessen.
Aber ich habe keinen "udev"-Link in /etc/rc2.d auf dem SQUEEZE-Tower.
Da gehoert der ja wie u.a. ich schon sagte auch nicht hin sondern als
S03udev nach /etc/rcS.d.

Es muss also ein Update für ein Paket gewesen sein, das auf dem Netbook
installiert ist, aber nicht auf dem Tower, welches diesn Link gesetzt hat.
Nein, muss es nicht.
Ansonsten halt mal Butter bei die Fische, zeig halt mal bei welchem
update das Du eingespielt hast links in rc2.d fuer udev angelegt werden.

Mal eine Minimalanalyse zum Einstieg:
$ grep update-rc.d /var/lib/dpkg/info/* | grep udev
/var/lib/dpkg/info/udev.postinst:	update-rc.d udev start 03 S .>/dev/null || exit $?
/var/lib/dpkg/info/udev.postinst:	update-rc.d udev-mtab start 36 S .>/dev/null || exit $?
/var/lib/dpkg/info/udev.postrm:	update-rc.d udev remove>/dev/null
/var/lib/dpkg/info/udev.postrm:	update-rc.d udev-mtab remove>/dev/null
(So sah das auch schon in lenny aus)
sieht auf meinem Netbook absolut identisch aus. Aber ich könnte den langen Auszug aus /var/log/apt/history.log posten.
Vielleicht hast Du den oder die links ja doch selber, vielleicht schon
vor Monaten und aus Versehen angelegt, und nun, nachdem Du eine unbekannte
Anzahl Pakete aktualisiert hast wirkt sich das eben doch negativ aus.
(Btw: Hast Du backups von /etc?)
weder noch, Das /etc Backup ist eine gute Idee, die ich aufgreifen werde aber dann muss ich mich zur Fehlersuche auch noch mit "diff" beschäftigen oder womit finde ich Unterschied in Konfigurationasfiles und in Verzeichnissen wie rc2.d?
Des weiteren ist ja auch relevant wie Xorg konfiguriert ist, man muss
nicht zwingend udev fuer Eingabegeraete nutzen (bei Dir ist es aber
zumindest auf dem netbook aber wohl so und das ist ja prinzipiell auch
nicht verkehrt). Vielleicht reagieren unterschiedliche Versionen (bzw.
bei stable meisst "Patchstaende", koennte aber auch sein das ueber proposed
updates doch auch eine neue Xorg-Version nach stable kam, muesste man mal
schauen) von Xorg auch unterschiedlich wenn mehrere udevd laufen (mal vom
Rest des Systems abgesehen...).

Es bleibt Dir (oder Christian Knoke, bei dem war es aber laut seiner
Beschreinbung wohl ein zweiter Link in rcS.d) aber unbenommen einen
Bugreport (gegen welches Paket?) einzureichen oder Dich an den schon
vorhandenen gegen udev, bei dem ebenso wie hier Details fehlen, anzuhaengen.
Den Bugreport kennst Du ja sicherlich auch schon?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663057

Letztlich koennt eben nur Ihr das Problem analysieren, ich kann hier so
lange suchen wie ich will, ich werde wohl nichts finden das einen link
fuer udev an falscher Stelle anlegt, hier ist nun einmal alles OK.

OK, mein Teil geht demnächst zum Service, danach wird SQUEEZE wie gehabt von der vorhandenen DVD aufgesetzt und dann online upgedatet. Mal sehen, ob der Effekt dann wieder auftritt. Ich weiss ja jetzt dank Christian, wie man ihn beheben kann.

MfG
Hugo


Reply to: