xdm Unknown session exit code 256 from process 917

[Marco Moock]

Hallo zusammen!
Manchmal wird XDM bei mir (Debian Sid) nicht richtig beendet.

Sat Mar 18 06:46:17 2023 xdm info (pid 917): sourcing /etc/X11/xdm/Xsetup
Sat Mar 18 06:46:28 2023 xdm info (pid 917): sourcing /etc/X11/xdm/Xstartup
Sat Mar 18 06:46:30 2023 xdm info (pid 953): executing session /etc/X11/xdm/Xsession
Sat Mar 18 22:39:28 2023 xdm error (pid 788): Sat Mar 18 22:39:28 2023 xdm info (pid 788): Shutting down
Unknown session exit code 256 from process 917
(II) Server terminated successfully (0). Closing log file.
Sat Mar 18 22:39:30 2023 xdm info (pid 788): Exiting

Das hat dann zur Folge, dass die Sperrdatei /var/run/xdm.pid nicht
gelöscht wird und ich die manuell löschen muss, damit ich das nächste
mal xdm starten kann.

Der Exit-Code 256 kommt mir komisch vor.
Sollte doch nur bis 255 gehen, oder?

--
Gruß
Marco

[Andreas Kohlbach]

On Sun, 19 Mar 2023 09:58:46 +0100, Marco Moock wrote:
>
> Manchmal wird XDM bei mir (Debian Sid) nicht richtig beendet.
>
> Sat Mar 18 06:46:17 2023 xdm info (pid 917): sourcing /etc/X11/xdm/Xsetup
> Sat Mar 18 06:46:28 2023 xdm info (pid 917): sourcing /etc/X11/xdm/Xstartup
> Sat Mar 18 06:46:30 2023 xdm info (pid 953): executing session /etc/X11/xdm/Xsession
> Sat Mar 18 22:39:28 2023 xdm error (pid 788): Sat Mar 18 22:39:28 2023 xdm info (pid 788): Shutting down
> Unknown session exit code 256 from process 917
> (II) Server terminated successfully (0). Closing log file.
> Sat Mar 18 22:39:30 2023 xdm info (pid 788): Exiting
>
> Das hat dann zur Folge, dass die Sperrdatei /var/run/xdm.pid nicht
> gelöscht wird und ich die manuell löschen muss, damit ich das nächste
> mal xdm starten kann.

Hast Du die /etc/X11/xdm/Xsession selbst erstellt/bearbeitet?

IIRC (ich habe keine mehr) braucht die am Ende ein

exit 0;
--
Andreas

https://news-commentaries.blogspot.com/

[Marco Moock]

Am 19.03.2023 um 13:04:12 Uhr schrieb Andreas Kohlbach:

> Hast Du die /etc/X11/xdm/Xsession selbst erstellt/bearbeitet?

Nein.

#!/bin/sh
#

# invoke global X session script
. /etc/X11/Xsession

Davor noch haufenweise Leerzeilen.
/etc/X11/Xsession hat am ende ein exit 0.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

> On Sun, 19 Mar 2023 20:44:08 +0100, Marco Moock wrote:
>> Am 19.03.2023 um 13:04:12 Uhr schrieb Andreas Kohlbach:
>>
>>> Hast Du die /etc/X11/xdm/Xsession selbst erstellt/bearbeitet?
>>>
>>
>> Nein.
>

> OK. Ich nutze lightdm. Habe in /etc/X11/ aber keinen lightdm.

>
>
>> #!/bin/sh
>> #
>>
>> # invoke global X session script
>> . /etc/X11/Xsession
>>
>> Davor noch haufenweise Leerzeilen.
>> /etc/X11/Xsession hat am ende ein exit 0.
>

> Die habe ich auch.
>
>
> Braucht xdm die /etc/X11/xdm/Xsession überhaupt? Schiebe die
> doch mal woanders hin (Backup). Vielleicht startet X dann noch,
> und das Problem ist weg?

A: Bei meinem Auto „singt“ das Getriebe im vierten Gang.  Was kann
ich tun?

B: Vielleicht hast du das falsche Öl eingefüllt?


A: Ich habe das Originalöl gelassen, wie es ist, und es ist laut
Betriebshandbuch noch kein Ölwechsel angesagt.

B: Braucht das Getriebe überhaupt Öl?  Lass es doch mal ab! (Fang
es aber auf, damit du es wieder einfüllen kannst, falls nötig.) 
Vielleicht kannst du danach noch schalten, und das Problem ist
weg?

Also manchmal zweifel' ich an deinem Verstand:  Ob der XDM eine
Konfigurationsdatei «/etc/X11/xdm/Xsession» benutzt, steht
sicherlich in der XDM‐Dokumentation.  Das muss man nicht
ausprobieren.

Darüber hinaus könntest du einfach mal auf deinem System
nachsehen, was in der Datei «/etc/X11/Xsession» steht, und dir
überlegen, was geschieht, wenn du sie weglässt.  Du kannst davon
ausgehen, dass diese Datei auf Marcos System eine ähnliche
Funktion haben wird.  Nachdem alles, was die Datei
«/etc/X11/xdm/Xsession» auf Marcos System tut, ist, die Datei
«/etc/X11/Xsession» einzulesen und abzuarbeiten, kannst du davon
ausgehen, dass das Entfernen der Datei «/etc/X11/xdm/Xsession»
ähnlich sinnvoll wie das Entfernen der Datei «/etc/X11/Xsession»
ist.

[Helmut Waitzmann]

Marco Moock <mo...@posteo.de>:

> Am 19.03.2023 um 13:04:12 Uhr schrieb Andreas Kohlbach:
>
>> Hast Du die /etc/X11/xdm/Xsession selbst erstellt/bearbeitet?
>>
>
> Nein.
>
> #!/bin/sh
> #
>
> # invoke global X session script
> . /etc/X11/Xsession
>
> Davor noch haufenweise Leerzeilen.
>

Wovor noch haufenweise Leerzeilen?  Leerzeilen vor der Zeile
«#!/bin/sh» könnten auf einen Fehler bei der Erstellung der Datei
«/etc/X11/Xdm/Xsession» hindeuten.

[Marco Moock]

Am 20.03.2023 um 00:28:34 Uhr schrieb Helmut Waitzmann:


> Wovor noch haufenweise Leerzeilen?  Leerzeilen vor der Zeile
> «#!/bin/sh» könnten auf einen Fehler bei der Erstellung der Datei
> «/etc/X11/Xdm/Xsession» hindeuten.

Exakt das ist der Inhalt (runterscrollen!)
Die Leerzeilen sind da.

Die Originaldatei im DEB-Paket hat die Leerzeilen auch drin:
https://packages.debian.org/sid/amd64/xdm/download

m@ryz:~$ cat /etc/X11/xdm/Xsession

#!/bin/sh
#

# invoke global X session script
. /etc/X11/Xsession

m@ryz:~$

[Marco Moock]

Am 20.03.2023 um 14:33:44 Uhr schrieb Andreas Kohlbach:

> @Marco: Wenn es gar keine Lösung hier geben wird, ersetze doch XDM
> durch lightdm.

Nein, denn so schlimm ist das dann auch nicht, auch wenn ich ser Sache
jetzt auf den Grund gehe.

[Christian Weisgerber]

On 2023-03-19, Marco Moock <mo...@posteo.de> wrote:

> Sat Mar 18 22:39:28 2023 xdm error (pid 788): Sat Mar 18 22:39:28 2023 xdm info (pid 788): Shutting down
> Unknown session exit code 256 from process 917

> Der Exit-Code 256 kommt mir komisch vor.
> Sollte doch nur bis 255 gehen, oder?

Funktionen wie wait() liefern einen Prozessstatus zurück, in dem
traditionell ein Feld von acht Bits für den Exit-Status reserviert
ist. Ein Wert von 256 ist damit schlicht unmöglich; siehe die Makros
in <sys/wait.h>. Erst mit der relativ neu von POSIX eingeführten
Funktion waitid() ist eine Übermittlung des Exit-Status mit vollem
int-Wertebereich möglich.

Ich würde also erst einmal schauen, wer überhaupt diese Meldung
generiert und wie dort der Exit-Status des Kindprozesses ermittelt
wird.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Mon, 20 Mar 2023 08:36:09 +0100:

> Exakt das ist der Inhalt (runterscrollen!)
> Die Leerzeilen sind da.
>
> Die Originaldatei im DEB-Paket hat die Leerzeilen auch drin:
> https://packages.debian.org/sid/amd64/xdm/download

Dann ist die Originaldatei kaputt. Ist die wenigstens als ausführbar
gesetzt? Dann würde sie wenigstens vom voreingestellten Befehlsinterpreter
(aka der Shell, wahrscheinlich der bash) ausgeführt. Sie sollte aber eine
(die weit unten als erste stehene Zeile) Kopfzeile _als allererste Zeile_
mit "!/bin/sh" enthalten, wodurch die allgemeine / eingeschränkte "sh"
benutzt würde. Das sollte im Normalfall nicht groß was ausmachen,
_könnte_ aber, nachdem die einzige Zeile ein Aufruf mit "." vorneweg,
gleichbedeutend mit "source", also unmittelbare Übernahme des Inhalts und
dessen Ausführung, darstellt, gewisse Funktionen leicht anders bearbeiten
als intendiert (aka vorgesehen...).
Oder, kurz gesagt, lösch'mal die Leerzeilen und schau', was passiert.
Normalerweise sollte sich nix am Vrhalten ändern, falls doch: Zeter und
Mordio (aka "bug report").

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Christian Weisgerber]

On 2023-03-20, Christian Weisgerber <na...@mips.inka.de> wrote:

>> Sat Mar 18 22:39:28 2023 xdm error (pid 788): Sat Mar 18 22:39:28 2023 xdm info (pid 788): Shutting down
>> Unknown session exit code 256 from process 917
>

> Ich würde also erst einmal schauen, wer überhaupt diese Meldung
> generiert und wie dort der Exit-Status des Kindprozesses ermittelt
> wird.

Also:

https://gitlab.freedesktop.org/xorg/app/xdm

Die Meldung kommt von xdm(8) und zwar xdm/dm.c:WaitForChild().
Der "exit code" ist waitVal(status), wobei status der von waitpid()
gelieferte Prozessstatus ist.

Was macht waitVal()? Die relevanten Auszüge aus include/dm.h:

# define waitCode(w) (WIFEXITED(w) ? WEXITSTATUS(w) : 0)
# define waitSig(w) (WIFSIGNALED(w) ? WTERMSIG(w) : 0)
# define waitCore(w) 0 /* not in POSIX. so what? */

# define waitCompose(sig,core,code) ((sig) * 256 + (core) * 128 + (code))
# define waitVal(w) waitCompose(waitSig(w), waitCore(w), waitCode(w))

Der Wert 256 bedeutet also, dass der Kindprozess durch Signal 1
beendet wurde. Das ist SIGHUP.

[Marco Moock]

Am 20.03.2023 um 23:19:02 Uhr schrieb Christian Weisgerber:

> Die Meldung kommt von xdm(8) und zwar xdm/dm.c:WaitForChild().
> Der "exit code" ist waitVal(status), wobei status der von waitpid()
> gelieferte Prozessstatus ist.
>
> Was macht waitVal()? Die relevanten Auszüge aus include/dm.h:
>
> # define waitCode(w) (WIFEXITED(w) ? WEXITSTATUS(w) : 0)
> # define waitSig(w) (WIFSIGNALED(w) ? WTERMSIG(w) : 0)
> # define waitCore(w) 0 /* not in POSIX. so what? */
>
> # define waitCompose(sig,core,code) ((sig) * 256 + (core) * 128 +
> (code)) # define waitVal(w) waitCompose(waitSig(w),
> waitCore(w), waitCode(w))
>
> Der Wert 256 bedeutet also, dass der Kindprozess durch Signal 1
> beendet wurde. Das ist SIGHUP.

Die erste Frage wäre, ob die 256 hier als Rückgabewert erwünscht ist.
Das kann ich leider nicht beurteilen.

Die zweite Frage wäre, ob das Beenden durch SIGHUP normal ist.
Beim Shutdown sollen die Prozesse ja kontrolliert beendet werden.
Wird das per SIGHUP gemacht?

[Peter J. Holzer]

On 2023-03-20 23:19, Christian Weisgerber <na...@mips.inka.de> wrote:
> Die Meldung kommt von xdm(8) und zwar xdm/dm.c:WaitForChild().
> Der "exit code" ist waitVal(status), wobei status der von waitpid()
> gelieferte Prozessstatus ist.
>
> Was macht waitVal()? Die relevanten Auszüge aus include/dm.h:
>
> # define waitCode(w) (WIFEXITED(w) ? WEXITSTATUS(w) : 0)
> # define waitSig(w) (WIFSIGNALED(w) ? WTERMSIG(w) : 0)
> # define waitCore(w) 0 /* not in POSIX. so what? */
>
> # define waitCompose(sig,core,code) ((sig) * 256 + (core) * 128 + (code))
> # define waitVal(w) waitCompose(waitSig(w), waitCore(w), waitCode(w))

Autsch. Die Bits in genau der anderen Reihenfolge zusammenzusetzen wie
Unix das traditionellerweise macht (gerade in der Man-Page eines Unix
aus der 80er-Jahren nachgelesen) und dabei noch einen Overflow
einzubauen, ist schon ein ziemlicher Schuss ins Knie.

hp

[Marco Moock]

Ist das deiner Meinung nach ein Problem in xdm?
Wenn ja mache ich nen Bugreport auf.

[Peter J. Holzer]

Da Christian hier aus dem Source-Code des xdm zitiert: Ja,
offensichtlich.

Ob das wirklich ein Problem ist, hängt davon ab, was mit dem so
berechneten Wert außer einer Fehlermeldung sonst noch passiert.

Wenn der Wert nur ausgegeben bzw. ins Logfile geschrieben wird, ist die
einzige Konsequenz, dass der User verwirrt wird. (Aber User, die nicht
jahrzehntelang in C und Perl programmiert haben, sind von Exit-Codes >
255 ohnehin verwirrt :-)).

Wenn der Wert weiterverwendet wird, könnte z.B. xdm fälschlicherweise
glauben, dass ein Programm mit einem Core-Dump beendet wurde, obwohl es
nur einen Exit-Code >= 128 hatte (wobei es einen echten Core-Dump nicht
feststellen kann, aber da das den Programmierer wenig kümmert ("so
what?"), wird das wohl im weiteren Code keine Bedeutung haben.)

hp

[Marco Moock]

Am 21.03.2023 um 21:52:45 Uhr schrieb Peter J. Holzer:

> On 2023-03-21 20:36, Marco Moock <mo...@posteo.de> wrote:
> > Ist das deiner Meinung nach ein Problem in xdm?
>
> Da Christian hier aus dem Source-Code des xdm zitiert: Ja,
> offensichtlich.

Ich habe das jetzt mal gemeldet:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033309

Mal sehen, was rauskommt.

[Christian Weisgerber]

On 2023-03-21, Marco Moock <mo...@posteo.de> wrote:

> Die erste Frage wäre, ob die 256 hier als Rückgabewert erwünscht ist.
> Das kann ich leider nicht beurteilen.

Es ist ja nun gerade keine Rückgabewert, sondern eine von xdm intern
synthetisierte Zahl, um den Beendigungsstatus des Kindprozesses
zusammenzufassen.

> Die zweite Frage wäre, ob das Beenden durch SIGHUP normal ist.
> Beim Shutdown sollen die Prozesse ja kontrolliert beendet werden.
> Wird das per SIGHUP gemacht?

Die klassische Art, das System runterzufahren, ist dass init(8)
erstmal das rc(8)-System entsprechend anstößt. Wenn anschließend
noch Prozesse laufen, dann bekommen sie ein SIGHUP geschickt; was
dann noch läuft nach zehn Sekunden ein SIGTERM; und was dann immer
noch läuft nach zehn weiteren Sekunden ein SIGKILL. Die Details
sind aber systemspezifisch - bei Linux sicherlich distributions-
spezifisch - und insbesondere ins rc(8)-System werden ja gerne
beliebig komplexe Dinge eingeklinkt. Wie das bei Linux-Systemen mit
systemd aussieht, weiß ich erst gar nicht.

Ebenfalls stellt sich die Frage, was sich eigentlich an einem alten
/var/run/xdm.pid stört.

Die ganze Angelegenheit betrifft also spezielle Details von Debian
Sid, die ich nicht kenne, und lässt sich nicht allgemein beantworten.

[Marco Moock]

Am 22.03.2023 um 16:12:31 Uhr schrieb Christian Weisgerber:

> Ebenfalls stellt sich die Frage, was sich eigentlich an einem alten
> /var/run/xdm.pid stört.

Vor dem Start von xdm wird geprüft, ob es diese Datei gibt, damit xdm
nicht 2x gestartet wird.
Beim Beenden muss die Datei daher gelöscht werden.

[Christian Weisgerber]

On 2023-03-22, Marco Moock <mo...@posteo.de> wrote:

>> Ebenfalls stellt sich die Frage, was sich eigentlich an einem alten
>> /var/run/xdm.pid stört.
>
> Vor dem Start von xdm wird geprüft, ob es diese Datei gibt,

Ja, aber wer genau prüft das? Irgendein rc-Skript? Ich kann mich
jetzt nicht erinnern, deinem Problem in den letzten dreißig Jahren
selber begegnet zu sein.

> Beim Beenden muss die Datei daher gelöscht werden.

Klassischerweise prüft man beim Start, ob ein Prozess mit dieser
PID überhaupt existiert. Wenn nicht, dann wird ein solches "stale
lock" einfach verworfen.

Wie gesagt, der Teufel steckt in irgendwelchen systemspezifischen
Details. Ich schreibe solche "ich weiß es auch nicht"-Postings ja
nur ungerne, aber die sachkundigen Antworten der Debian-Anwender
lassen leider auf sich warten.

[Laurenz Trossel]

On 2023-03-22, Marco Moock <mo...@posteo.de> wrote:

> Vor dem Start von xdm wird geprüft, ob es diese Datei gibt, damit xdm
> nicht 2x gestartet wird.

Es wird nicht geprüft, ob es auch einen xdm-Prozess mit dieser PID gibt?
Wenn nicht, ist das der Bug den du melden musst.

> Beim Beenden muss die Datei daher gelöscht werden.

Sauber programmierte Software erkennt stale pid files.

[Helmut Waitzmann]

Marco Moock <mo...@posteo.de>:

> Am 20.03.2023 um 00:28:34 Uhr schrieb Helmut Waitzmann:
>
>
>> Wovor noch haufenweise Leerzeilen?  Leerzeilen vor der Zeile
>> «#!/bin/sh» könnten auf einen Fehler bei der Erstellung der
>> Datei «/etc/X11/Xdm/Xsession» hindeuten.
>
> Exakt das ist der Inhalt (runterscrollen!)
> Die Leerzeilen sind da.
>
> Die Originaldatei im DEB-Paket hat die Leerzeilen auch drin:
> https://packages.debian.org/sid/amd64/xdm/download
>
> m@ryz:~$ cat /etc/X11/xdm/Xsession
>

[Viele Leerzeilen in der Datei, dann]

> #!/bin/sh
> #
>
> # invoke global X session script
> . /etc/X11/Xsession

Danke für die Klarstellung.  Sieghard hat ja einiges dazu
geschrieben.  Nochmal ganz kurz:  Damit die Kommentarzeile
«#!/bin/sh» wirklich eine Wirkung hat (also in der Tat mehr als
ein Kommentar ist!), muss sie die absolut erste Zeile einer
ausführbaren Shell‐Skript‐Datei sein.  Dass sie es in deinem Fall
(wegen der vorausgehenden Leerzeilen) nicht ist, bewirkt, dass
sie zur Kommentarzeile verkommt und damit (ziemlich) sinnlos
ist.  Deshalb vermute ich einen Fehler in der Datei.

Probiere Sieghards Rat:  Lösche alle Leerzeilen vor dieser
Kommentarzeile und mach' die Datei ausführbar:

chmod -- a+x /etc/X11/xdm/Xsession

Bei Debian Sid, das ja die neu entstehende, noch unfertige
Debian‐Distribution darstellt, kann so ein Fehler schon 'mal
passieren.

[Marco Moock]

Am 22.03.2023 um 20:36:38 Uhr schrieb Helmut Waitzmann:

> Bei Debian Sid, das ja die neu entstehende, noch unfertige
> Debian‐Distribution darstellt, kann so ein Fehler schon 'mal
> passieren.

xdm ist seit 2015 nicht mehr aktualisiert worden bei Debian, ergo hat
das mit sid nix zu tun.

[Marco Moock]

Hier war es nicht der Fall.
Ich habe in der virtuellen Konsole geschaut, xdm lief nicht.
Dann versucht, den zu starten, das ging schief mit der Meldung, dass
das Lockfile existiert.
Es wird also scheinbar nicht geschaut, ob es diese PID gibt.
Dazu kommt, dass ja nach einem Neustart ein anderer Prozess diese PID
haben könnte, ein sicherer Indikator ist das daher nicht, dass der
Dienst läuft, sehr wohl aber, dass er nicht läuft.

[Laurenz Trossel]

On 2023-03-22, Marco Moock <mo...@posteo.de> wrote:

> Dann versucht, den zu starten, das ging schief mit der Meldung, dass
> das Lockfile existiert.

Dann ist der Bug, daß xdm kein stale pid file erkennt. Das ist auch erst
Standard seit es PIDs gibt.

> Dazu kommt, dass ja nach einem Neustart ein anderer Prozess diese PID
> haben könnte,

Nich mit dem Namen und/oder Executable xdm. Die PID alleine reicht
natürlich nicht.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:
> On Mon, 20 Mar 2023 00:23:21 +0100, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:

>>>
>>> Braucht xdm die /etc/X11/xdm/Xsession überhaupt? Schiebe die doch
>>> mal woanders hin (Backup). Vielleicht startet X dann noch, und das
>>> Problem ist weg?
>

> [...]

>
>> Also manchmal zweifel' ich an deinem Verstand:  Ob der XDM eine
>> Konfigurationsdatei «/etc/X11/xdm/Xsession» benutzt, steht
>> sicherlich in der XDM‐Dokumentation.  Das muss man nicht
>> ausprobieren.
>

> Ich halte Trial and Error
> <https://de.wikipedia.org/wiki/Versuch_und_Irrtum> für besser. Es wird
> sofort Ergebnisse liefern (geht oder geht nicht),

Da habe ich so meine Zweifel.  Beispielsweise habe ich in meinem
HOME‐Verzeichnis eine Datei «.xsession», die auch vom XDM
(mittels «/etc/X11/Xsession») verwendet wird.

Allerdings nutze ich den XDM nicht, sondern logge mich an einer
virtuellen Konsole textorientiert ein und starte meine X‐Sitzung
mittels «startx» von Hand.  Dafür habe ich im HOME‐Verzeichnis
die Datei «.xinitrc», ein Shell‐Skript, stehen, in der im
wesentlichen nur das Kommando

exec /etc/X11/Xsession "${HOME%/}"/.xsession

steht.

Ich könnte auf «/etc/X11/Xsession» verzichten und statt dessen
das Kommando

exec "${HOME%/}"/.xsession

verwenden.  Das würde mir ebenfalls eine X‐Sitzung starten – eine
X‐Sitzung, der Verschiedenes, das man nicht auf den ersten Blick
erkennen wird («geht oder geht nicht»), fehlt.

Ein einfaches Vorgehen nach Versuch und Irrtum wird da nicht zum
Ziel führen.

> sodass man sich nicht erst in die doch recht komplexe Mechanik
> von X (XDM, KDM, LightDM...) einlesen muss, und vielleicht doch
> die Lösung findet.
>
> Ich weiß, dass Du das anders sieht (RTFM). Ich auch, *wenn* man zum
> Verstehen kein Raketenwissenschaftler werden muss.

Man muss auch kein Raketenwissenschaftler sein.  Es genügt, die
Programmiersprache «POSIX‐Shell» so weit zu verstehen, dass man
eine Ahnung davon bekommt, dass «/etc/X11/Xsession» die frisch
gestartete X‐Sitzung unter Beachtung verschiedener
Konfigurationsdateien des HOME‐Verzeichnisses (oder bestimmter
Defaults bei Abwesenheit derselben) konfiguriert und schließlich
den vom Anwender gewählten Desktop startet.

>> Darüber hinaus könntest du einfach mal auf deinem System
>> nachsehen, was in der Datei «/etc/X11/Xsession» steht, und dir
>> überlegen, was geschieht, wenn du sie weglässt. Du kannst davon
>> ausgehen, dass diese Datei auf Marcos System eine ähnliche
>> Funktion haben wird. Nachdem alles, was die Datei
>> «/etc/X11/xdm/Xsession» auf Marcos System tut, ist, die Datei
>> «/etc/X11/Xsession» einzulesen und abzuarbeiten, kannst du
>> davon ausgehen, dass das Entfernen der Datei
>> «/etc/X11/xdm/Xsession» ähnlich sinnvoll wie das Entfernen der
>> Datei «/etc/X11/Xsession» ist.
>

> Ende 2021 hatte ich hier die Frage wegen setxkbmap (Xorg/Keyboard
> Konfiguration) gestellt.

Ja, ich erinnere mich.  «setxkbmap» zerschoss dir die Datei
«.xsession» im HOME‐Verzeichnis.  Dadurch verwendete
«/etc/X11/Xsession» nicht mehr einen Default sondern die
zerschossene Datei.  Und das war die Folge:

> Durch das Anwenden startete X beim nächsten Mal nicht mehr. Am
> Ende lief es darauf hinaus, dass es ein Bug war (der
> mittlerweile gefixt ist). Abhilfe schaffte das Entfernen der
> erzeugten Datei.

Ja, und zwar deshalb, weil du keine Datei «"$HOME"/.xsession»
haben wolltest (und durftest), damit der von dir gewählte Desktop
startet.  «"$HOME"/.xsession» war in deinem Fall nicht nur nicht
obligatorisch sondern sogar störend.

Etwas anders verhält es sich doch mit einer vom
Systemadministrator (oder Distributor) erstellten Datei.  Da kann
man einerseits nicht davon ausgehen, dass sie optional ist, und
sollte andererseits davon ausgehen können, dass sie vom
Administrator oder Distributor mit Sorgfalt erstellt und geprüft
worden ist.  Im Fall von Debian Sid scheint die Datei
«/etc/X11/xdm/Xsession» nach der letzten Prüfung nochmal
verändert worden zu sein.  (Möglicherweise fiel irgend etwas
Schweres auf die Return‐Taste, als die Datei im Editor stand.) 
Optional wird sie aber dennoch eher nicht sein.

> Damit gelangte ich zur Meinung, mögliche Schuldige erst mal aus
> dem Weg zu räumen. Wenn es dann noch klappt, und man mit keinen
> oder nicht zu vielen Einschränkungen leben muss: prima.

Bei meinem Fall wird das Unterlassen der Abarbeitung von
«/etc/X11/Xsession» zu Einschränkungen führen, die man auf den
ersten Blick nicht erkennt.  Beispielsweise könnte es dann sein,
dass «gpg» (mit dem «gpg-agent») nicht mehr richtig
funktioniert.  Das wird man aber beim schnellen Versuch und
Irrtum nicht entdecken und erst später, wenn man es dann entdeckt
haben wird, nicht mehr damit in Verbindung bringen.

> Wie erwähnt habe ich keine /etc/X11/lightdm/Xsession (ich nutze
> lightdm statt xdm). Auch dass die Xsession (die habe ich
> woanders) dann nicht grundsätzlich mit einem Display Manager zu
> tun hat gab mir die Idee, diese Datei doch zu entfernen.

Sie kommt erst dann ins Spiel, wenn der Display‐Manager seine
Arbeit getan und eine neue X‐Sitzung gestartet hat.

Der Distributor oder Administrator kann nicht unbedingt davon
ausgehen, dass jeder Anwender in seinem HOME‐Verzeichnis alle
möglichen Konfigurationsdateien bereits hat.  Deshalb wird in den
Programmen in der Regel dieser Fall berücksichtigt.  Bei Dateien
unter «/etc/» sieht das etwas anders aus.

«/etc/X11/Xsession», in Marcos Fall von «/etc/X11/xdm/Xsession»
aufgerufen, initialisiert die X‐Sitzung und startet den vom
Anwender gewählten Desktop.

Ohne «/etc/X11/xdm/Xsession» wird der XDM sie nicht aufrufen.  In
Folge wird vermutlich weder die X‐Sitzung initialisiert noch der
vom Anwender gewählte Desktop gestartet, und die X‐Sitzung wird,
kaum gestartet, gleich zu Ende kommen.

> Weder Marco (vermutlich) noch ich haben das Wissen/Zeit, um sich
> ausführlich mit dem Thema zu beschäftigen. Hast Du?

Ich habe mir mal die Zeit genommen, in den Handbüchern
nachzulesen, was «xinit» (und das Frontend «startx» dazu) tun. 
Weil mir das Standardverhalten von «startx» nicht in allen
Punkten gefallen hat, habe ich eine Datei «"$HOME"/.xinitrc»
angelegt, um ein abgeändertes Verhalten hinzubekommen.

> Xsession hat eine man page.
>

«Xsession(5)».  Daraus:


NAME
Xsession - initialize X session

Das lässt mich vermuten, dass eine X‐Sitzung ohne Xsession eher
nicht richtig initialisiert sein wird.

SYNOPSIS
Xsession [ session-type ]

DESCRIPTION
/etc/X11/Xsession is a Bourne shell (sh(1)) script
which is run when an X Window System session is begun
by startx(1) or a display manager such as xdm(1).
(Some display managers only invoke Xsession when
specifically directed to so by the user; see the
documentation for your display manager to find out
more.) Administrators unfamiliar with the Bourne
shell will likely find the Xsession.options(5)
configuration file easier to deal with than Xsession
itself.

Das ist ein Indiz dafür, dass «/etc/X11/Xsession» nicht nur eine
optionale Konfigurationsdatei sondern eher ein Programm ist, das
seinerseits eine Konfigurationsdatei, «Xsession.options», nutzt.

Xsession is not intended to be invoked directly by
the user; to be effective it needs to run in a
special environment associated with X server
initialization. startx, xdm, xinit(1), and other
similar programs handle this.

By default on a Debian system, Xsession is used by
both common methods of starting the X Window System,
xdm (or another X display manager) and startx.

«/etc/X11/Xsession» scheint also eine Aufgabe zu erfüllen, auf
die die meisten X‐Sitzungen zurückgreifen.

> Vielleicht kannst Du dann eine mögliche Lösung daraus
> extrahieren?

Man könnte versuchsweise mal an einer virtuellen Konsole
textorientiert einloggen und dann mit «startx» eine X‐Sitzung
starten.  Wenn die nicht auch den Exit‐Status 256 meldet, ist der
Verdacht groß, dass das Problem nicht «/etc/X11/Xsession» ist. 
Dann kann man sich «/etc/X11/xdm/Xsession» ansehen, über die
Leerzeilen am Anfang stolpern und dort (wie beschrieben) einen
Fehler in der Datei vermuten.

> @Marco: Wenn es gar keine Lösung hier geben wird, ersetze doch
> XDM durch lightdm.

Debian Sid ist work in progress.  Deshalb sehe ich eher die zwei
folgenden Möglichkeiten, wenn etwas nicht funktioniert: 
Entweder, man kniet sich rein, findet den Fehler (Danke,
Christian und Peter!) und kümmert sich darum, dass er behoben
wird, oder, man lässt die Finger von «Sid».

[Marco Moock]

Am 19.03.2023 schrieb Marco Moock <mo...@posteo.de>:

> Manchmal wird XDM bei mir (Debian Sid) nicht richtig beendet.
>
> Sat Mar 18 06:46:17 2023 xdm info (pid 917): sourcing
> /etc/X11/xdm/Xsetup Sat Mar 18 06:46:28 2023 xdm info (pid 917):
> sourcing /etc/X11/xdm/Xstartup Sat Mar 18 06:46:30 2023 xdm info (pid
> 953): executing session /etc/X11/xdm/Xsession Sat Mar 18 22:39:28
> 2023 xdm error (pid 788): Sat Mar 18 22:39:28 2023 xdm info (pid
> 788): Shutting down Unknown session exit code 256 from process 917
> (II) Server terminated successfully (0). Closing log file. Sat Mar 18
> 22:39:30 2023 xdm info (pid 788): Exiting
>
> Das hat dann zur Folge, dass die Sperrdatei /var/run/xdm.pid nicht
> gelöscht wird und ich die manuell löschen muss, damit ich das nächste
> mal xdm starten kann.

Das passiert übrigens immer Samstags, wenn ich dann Sonntags den PC
boote, tritt der Fehler auf.

Die Frage ist, ob das mit
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948346
zusammenhängt.

Was auch auffällt: xdm wurde in Debian seit 2015 nicht mehr angefasst,
obwohl es neuere Versionen gab.

[Christian Garbs]

Mahlzeit!

Marco Moock <mo...@posteo.de> wrote:
> Am 19.03.2023 schrieb Marco Moock <mo...@posteo.de>:

>> Manchmal wird XDM bei mir (Debian Sid) nicht richtig beendet.
>>
>> Sat Mar 18 06:46:17 2023 xdm info (pid 917): sourcing
>> /etc/X11/xdm/Xsetup Sat Mar 18 06:46:28 2023 xdm info (pid 917):
>> sourcing /etc/X11/xdm/Xstartup Sat Mar 18 06:46:30 2023 xdm info (pid
>> 953): executing session /etc/X11/xdm/Xsession Sat Mar 18 22:39:28
>> 2023 xdm error (pid 788): Sat Mar 18 22:39:28 2023 xdm info (pid
>> 788): Shutting down Unknown session exit code 256 from process 917
>> (II) Server terminated successfully (0). Closing log file. Sat Mar 18
>> 22:39:30 2023 xdm info (pid 788): Exiting
>>
>> Das hat dann zur Folge, dass die Sperrdatei /var/run/xdm.pid nicht
>> gelöscht wird und ich die manuell löschen muss, damit ich das nächste
>> mal xdm starten kann.
>
> Das passiert übrigens immer Samstags, wenn ich dann Sonntags den PC
> boote, tritt der Fehler auf.

Eine Lösug wäre, die PID-Datei beim Booten zu löschen (da kann der
alte Prozess ja nicht mehr da sein). Oder vielleicht im "stop" vom
xdm-Initskript?

Ist aber alles Symptom-Doktorei, keine Ursachenbehebung.

> Die Frage ist, ob das mit
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948346
> zusammenhängt.

Das sieht sehr danach aus, siehe Message 20:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948346#20

> Was auch auffällt: xdm wurde in Debian seit 2015 nicht mehr angefasst,
> obwohl es neuere Versionen gab.

Irgendwie ging es mit dem Bug nicht weiter, aber ich hab noch nicht
entfusselt, wer da wer ist (Maintainer, Bugersteller, Bugfixer,
potenzieller Uploader).

Gruß
Christian

PS: Ich bin aus mir nicht mehr ganz nachvollziehbaren Gründen
inzwischen auf allen Rechnern von xdm zu lightdm gewechselt, auch
wenn ich dessen Konfiguration nicht mag. Da gibt's das Problem
nicht, aber auch das ist ja kein Fix.
--
....Christian.Garbs....................................https://www.cgarbs.de
Why waste time learning when ignorance is instantaneous?
(Hobbes)