ein rant zur fehlersuche und findung bei computer-setups, etwas lang ...
Artikel ansehen
Zusammenfassung ansehen
ich habe zu hause u.a. zwei pcs, einer davon als arbeits- und spielerechner, der andere, ein nuc , als miniserver: musik, bücher, nextcloud, ldap, sprungrechner und dergleichen. zwischen diesen habe ich einen keyboard-video-mouse-switch, mit dem ich die entsprechenden geräte zwischen den beiden rechnern umschalten kann. dabei zerhaut es mir aber oft die monitor-konfig meines hauptrechners, die ich dann wieder rekonstruieren muss. dazu, dachte ich mir schon länger, wäre doch eine vnc-rdp verbindung ideal, ein remote-desktop. kein ärger mehr; einfach schnell mal umschalten und wieder zurück. das ist mir aber in den letzten 4 bis 5 jahren nicht gelungen einzurichten.
es ging einfach nicht. was mit anderen rechner völlig problemlos funktionierte, hat bei der genannten kombination nicht geklappt. ich benutze linux, kde/plasma und krfb/KRDC und das ist kinderleicht; eigentlich. man sagt auf serverseite ja, ich will und gibt auf client-seite die adresse des servers an und schon funktioniert der remote-desktop. problematisch war, dass es nirgendwo logs gibt, die irgendetwas anzeigen. es kam einfach keine verbindung zustande. und die meldung am monitor lautete: der entfernte server hat die verbindung geschlossen.
nach einem update heute, wollte ich es dann wieder einmal versuchen. es kann doch gar nicht sein, dass so ein kinderkram einfach nicht geht! an den rechnern gibt es sonst keinerlei fehler! außerdem ist schönes wetter, die sonne scheint, ich könnte eine radtour machen und deswegen kann man schnell mal eben kurz etwas debuggen. und es ging wieder nicht! ich habe an allem herumgebastelt, firewall, netzconfig, konfig-skripte, sogar alternative setups versucht; das war alles nichts. die alternativen setups haben mir nicht den laufenden desktop geliefert, waren also nicht so ohne weiteres nutzbar und beim rest gab es einfach keine fehler.
weil es keine logs in dem system zu der verbindung gibt, habe ich am schluss sogar mit einem strace dem serverprozess (krfb) zugehört. die ausgabe in eine datei umgeleitet, mehrere verbindungssversuche gestartet und dann nur mal kurz in die datei reingeschaut. strace produziert ja massenweise mitschnitt, das wollte ich mir bis morgen aufheben. nur mal kurz reinschauen in den mitschnitt und dann aufs rad, den kopf wieder frei bekommen. tja, die datei war so gut wie leer! da war nichts mitgeschnitten!
auf der client-seite hat mir der rechner bei jedem versuch gemeldet: der server hat die verbindung abgebrochen. auf der serverseite hat der server aber von diesem verbindungsversuch nichts mitbekommen, hat also auch nichts abgebrochen. deswegen war der strace-mitschnitt leer. also doch keine radtour.
die fehlermeldung auf der client-seite ist einfach falsch. nicht der server hat die verbindung abgebrochen, sondern der client hat einfach keinen server gefunden! und dann irgendetwas von verbindungsabbruch halluziniert. als wärs eine ki. warum aber keinen server gefunden? auf server-seite ließ sich der kde-vnc-server krfb problemlos starten, stoppen und wieder starten.
dann bin ich auf die idee gekommen, mir die port-belegung des netzwerks auf dem server anzusehen. und dort war es komisch. auf dem vnc-standardport bei ipv4 des servers lauschte ein xinit-prozess. auf ipv6 der krfb. der blöde krfb ist also jedesmal problemlos gestartet, obwohl ihm irgend ein anderes programm einen port blockiert. und das macht krfb natürlich ohne irgend eine beschwerde, oder gar einen absturz. ich vermute, dass ich davon in dem mitschnitt nichts gesehen habe, liegt daran, dass ich den strace erst an das laufende programm angeflanscht hatte und krfb vielleicht nur beim starten meckert. tja.
und daher die titelzeile. der xinit-prozess am ipv4-port gehörte zu einem programm xrdc. die konfig-dateien dieses programms haben als jüngstes änderungsdatum 2017. da habe ich offensichtlich versucht, diesen xrdc zum selben zweck einzubauen, wie danach den krfb von kde. in den 7 jahren hatte ich das natürlich vollkommen vergessen. und nach dem basteln 2017 nicht richtig aufgeräumt. und alle systeme immer nur upgedatet, nicht neu installiert (bravo debian!), mit der unangenehmen folge, dass diese relikte auch immer mitgeschleppt wurden.
und jetzt läuft alles soweit. ich muss mir das mit dem aufräumen mal ernsthaft vornehmen wenn ich etwas ausprobiert habe. das mit dem aufschreiben ist vielleicht auch eine idee, aber würde ich jemals 7 jahre alte dateien lesen, ob da nicht eventuell die ursache für einen fehler in meinem jetzigen rechner versteckt ist? das radeln verschiebe ich wohl auf morgen. ich schätze, ich gönne mir jetzt mal einen vorsommerlichen pastis auf dem balkong und sonne mich in dem gefühl, wieder einmal einen großen erfolg erzielt zu habe. dass der darin besteht, ein problem beseitigt zu haben, das ich vor 7 jahren selber verursacht hatte, wird hoffentlich nach ein paar getränken im dämmer versinken ...
