Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #120395 > unrolled thread

[lightdm] Kein grafisches User-Login

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 08:29 -0500
    Re: [lightdm] Kein grafisches User-Login Tim Ritberg <tim@server.invalid> - 2022-01-01 15:09 +0100
      Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-02 08:30 +0100
        Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 11:24 -0500
    Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-01 15:14 +0100
      Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 15:09 -0500
        Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-01 22:07 +0100
          Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 16:22 -0500
            Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-01 23:14 +0100
              Re: [lightdm] Kein grafisches User-Login Arno Lutz <invalid@freakmail.de> - 2022-01-02 00:32 +0100
                Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 23:18 -0500
              Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 22:13 -0500
                Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-02 08:54 +0100
                  Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-02 09:55 +0100
                    Re: [lightdm] Kein grafisches User-Login Michael Brand <brandm@gmx.net> - 2022-01-02 10:18 +0100
                      Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 10:30 -0500
                        Re: [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-02 21:08 +0100
                          Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 10:56 -0500
                        Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-03 03:30 +0100
                          Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 11:02 -0500
                Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-02 09:36 +0100
                  Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 10:54 -0500
                Re: [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-02 21:13 +0100
                  Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 11:44 -0500
                    Re: [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-03 20:37 +0100
    Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-02 08:17 +0100
      Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 11:08 -0500
        Re: [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-03 02:59 +0100
          Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 11:36 -0500
            Re: [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-03 21:31 +0100
              [Gelöst] [lightdm] Kein grafisches User-Login (was: [lightdm] Kein grafisches User-Login) Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 18:07 -0500
                Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 19:25 -0500
                  Debian bullseye xkbset-gui defekt? (was: [Gelöst] [lightdm] Kein grafisches User-Login) Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-04 08:27 +0100
                    Re: Debian bullseye xkbset-gui defekt? Andreas Kohlbach <ank@spamfence.net> - 2022-01-04 08:58 -0500
                      Re: Debian bullseye xkbset-gui defekt? Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-05 03:36 +0100
                        Re: Debian bullseye xkbset-gui defekt? Andreas Kohlbach <ank@spamfence.net> - 2022-01-05 06:05 -0500
                Wie funktioniert "${HOME}/.xsession"? (was: [Gelöst] [lightdm] Kein grafisches User-Login) Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-04 08:58 +0100
                  Re: Wie funktioniert "${HOME}/.xsession"? (was: [Gelöst] [lightdm] Kein grafisches User-Login) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-04 20:29 +0100
                    Re: Wie funktioniert "${HOME}/.xsession"? Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-05 03:30 +0100
                      Re: Wie funktioniert "${HOME}/.xsession"? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-05 22:11 +0100
                        Re: Wie funktioniert "${HOME}/.xsession"? Juergen Ilse <news@usenet-verwaltung.de> - 2022-01-05 21:37 +0000
                        Re: Wie funktioniert "${HOME}/.xsession"? Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-06 23:24 +0100
                          Re: Wie funktioniert "${HOME}/.xsession"? Friedhelm Waitzmann <usenetf2022.fwnsp@spamgourmet.com> - 2022-01-07 01:03 +0000
                Re: [Gelöst] [lightdm] Kein grafisches User-Login (was: [lightdm] Kein grafisches User-Login) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-04 20:24 +0100
                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-04 18:32 -0500
                    Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-05 22:38 +0100
                      Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-05 19:20 -0500
                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-07 20:55 +0100
                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-07 18:23 -0500
                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Thomas Noll <-_tn_-@web.de> - 2022-01-08 12:56 +0000
                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-08 22:29 +0100
                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-08 19:28 -0500
                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-09 08:16 +0100
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-09 08:25 -0500
                                    Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-09 22:47 +0100
                                      Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-09 18:34 -0500
                                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Thomas Dorner <de.comp.os.unix.linux.misc.220110.dorner@spamgourmet.com> - 2022-01-10 18:52 +0100
                                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-10 19:56 +0100
                                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-10 20:24 +0100
                                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-10 19:44 -0500
                                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Thomas Dorner <de.comp.os.unix.linux.misc.220111.dorner@spamgourmet.com> - 2022-01-11 18:05 +0100
                                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-11 15:33 -0500
                                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-12 01:08 +0100
                                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-12 00:04 +0100
                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-08 22:33 +0100
                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-08 22:45 +0100
                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-08 19:37 -0500
                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-09 03:02 +0100
                      Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-08 22:18 +0100
                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-09 21:05 +0100
                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-10 20:48 +0100
                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-12 19:53 +0100
                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-13 07:04 -0500
                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-13 23:37 +0100
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Hans CraueI <crauel_usenet@freenet.de> - 2022-01-13 23:40 +0000
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 04:13 -0500
                                    Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-15 21:46 +0100
                                      Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-16 09:53 -0500
                                        Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-17 23:39 +0100
                                          Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-21 23:01 -0500
                                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Paul Muster <exp-311222@news.muster.net> - 2022-01-22 08:11 +0100
                                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-22 15:12 -0500
                                            Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-23 01:19 +0100
                                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-22 22:59 -0500
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-14 20:24 +0100
                              Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-13 23:12 +0100
                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 03:50 -0500
                                  apthängigkeiten (was: Re: [Gelöst] [lightdm] Kein grafisches User-Login) Thomas Noll <-_tn_-@web.de> - 2022-01-14 15:57 +0000
                                    Re: apthängigkeiten (was: Re: [Gelöst] [lightdm] Kein grafisches User-Login) Paul Muster <exp-311222@news.muster.net> - 2022-01-14 17:11 +0100
                                      Re: apthängigkeiten Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 12:07 -0500
                                        Re: apthängigkeiten Paul Muster <exp-311222@news.muster.net> - 2022-01-14 21:31 +0100
                                          Re: apthängigkeiten Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 18:09 -0500
                                            Re: apthängigkeiten Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-01-16 11:15 +0100
                                        Re: apthängigkeiten Bernd Mayer <beam.bam.boom@knuut.de> - 2022-01-14 22:07 +0100
                                          Re: apthängigkeiten Bernd Mayer <beam.bam.boom@knuut.de> - 2022-01-14 22:19 +0100
                                            Re: apthängigkeiten Andreas Kohlbach <ank@spamfence.net> - 2022-01-14 18:21 -0500
                                        Re: apthängigkeiten Jens Schüßler <j.schuess@nurfuerspam.de> - 2022-01-14 23:39 +0100
                                          Re: apthängigkeiten Andreas Kohlbach <ank@spamfence.net> - 2022-01-15 07:03 -0500
                                      Re: apthängigkeiten Thomas Noll <-_tn_-@web.de> - 2022-01-14 19:39 +0000
                                        Re: apthängigkeiten Paul Muster <exp-311222@news.muster.net> - 2022-01-14 21:31 +0100
                                Re: [Gelöst] [lightdm] Kein grafisches User-Login Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-14 20:35 +0100
                                  Re: [Gelöst] [lightdm] Kein grafisches User-Login Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-15 21:46 +0100
            Wer mit "root" zuendelt... (was: [lightdm] Kein grafisches User-Login) Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-04 09:11 +0100
              Re: Wer mit "root" zuendelt... Andreas Kohlbach <ank@spamfence.net> - 2022-01-04 09:17 -0500
                Re: Wer mit "root" zuendelt... Kay Martinen <usenet@martinen.de> - 2022-01-04 22:42 +0100
                  Re: Wer mit "root" zuendelt... Andreas Kohlbach <ank@spamfence.net> - 2022-01-05 05:30 -0500
                Re: Wer mit "root" zuendelt... Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-01-05 03:37 +0100
    Re: [lightdm] Kein grafisches User-Login Gert Link <gertlink_nospam@gmx.de> - 2022-01-02 08:49 +0100
      Re: [lightdm] Kein grafisches User-Login Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 11:09 -0500
        Re: [lightdm] Kein grafisches User-Login Tim Ritberg <tim@server.invalid> - 2022-01-03 18:50 +0100

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#120556 — Re: Wie funktioniert "${HOME}/.xsession"?

Hallo,

Sieghard Schicktanz <Sieghard.Schicktanz@schs.de> wrote:
> Hallo Helmut Waitzmann,
> 
> Du schriebst am Wed, 05 Jan 2022 03:30:35 +0100:
> 
>> >> Wenn du keinen Window‐Manager starten lässt, ist die logische 
> ...
>> > Aber _wird_ der (schon) in der ".xsession" gestartet? Bei Dir? 
> ...
>>  Absolut.  Bei mir wird in der Datei «~/.xsession» der 
>>  Window‐Manager (im Hintergrund) gestartet.  Im Vordergrund starte 
>>  ich zum Schluss ein «xterm».  Schließe ich das, wird die X‐Sitzung 
>>  beendet.  (Ich mache das so, weil ich innerhalb einer X‐Sitzung den 
> 
> Und warum läuft sie nicht weiter, wenn doch der Window‐Manager im
> Hintergrund laufen sollte? _Der_ müßte die doch auch offenhalten?
> Oder wird der von der Shell, die die .xsession abarbeitet, nach deren
> Ende mit "abgeräumt"?
 
"xinit" (was dem ganzen zu Grunde liegt) startet den X-Server, arbeitet
ein Kommando (i.d.R. ein shell-scrript) ab und killt anschliessend den
X-Server. Wenn der X-Server gekillt wird, bekommen alle Clients, die 
auf das zugehoerige Display ausgeben, ein "SIGPIPE", was i.d.R. dazu
fuehrt, dass sie sich beenden. Auch der Windowmanager ist ein X-Client
(wenn auch ein "besonderer").

>>  Window‐Manager wechseln können möchte, ohne, dass mir die X‐Sitzung 
>>  beendet wird.  Aber prinzipiell kann man eine X‐Sitzung auch an 
>>  einen Window‐Manager statt an ein «xterm» hängen.)

Ich hatte mal was mit einem TCL/TK Script gebastelt, dass ein Menu anzeigte,
um einen Windowmanager auszuwaehlen, diesen dann startete und nach Beendigung
diesen dann wieder das Menu anzeigte. In dem Menu gab es auch einen "exit"
Button, der das script beendete. Bau dir ein solche script (meins ist mir
irgendwann verloren gegangen) und starte das statt dem Windowmanager in dem
script, dass die X-Session am laufen haelt.

> Üblicherweise (? Hier jedenfalls...) läuft das doch so, daß der
> _Window‐Manager_ den X-Server solange festhält, bis er über einen
> eigenen Mechanismus (Menü o.w.a.i.) beendet wird.

Auch wenn es so aussieht: es ist nicht ganz so (siehe oben).

> Für das Wechseln des Window‐Managers ist dann der Display-Manager (dm)
> zuständig, der dafür ein Auswahlmenü anbietet|n kann.

Der Display-Manager macht deutlich mehr (und bietet nicht unbedingt die
Auswahl des Windowmanagers, bei geeigneter Konfiguration aber das starten
von X-Sessions auf verschiedenen Maschinen im Netz).

Tschuess,
	Juergen Ilse			(juergen@usenet-verwaltung.de)

[toc] | [prev] | [next] | [standalone]

#120601 — Re: Wie funktioniert "${HOME}/.xsession"?

Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de>:
>Hallo Helmut Waitzmann, 
>Du schriebst am Wed, 05 Jan 2022 03:30:35 +0100:
>
>>>> Wenn du keinen Window‐Manager starten lässt, ist die logische 
>>>>
>...
>>> Aber _wird_ der (schon) in der ".xsession" gestartet? Bei Dir? 
>>>
>...
>>  Absolut.  Bei mir wird in der Datei «~/.xsession» der 
>>  Window‐Manager (im Hintergrund) gestartet.  Im Vordergrund 
>>  starte ich zum Schluss ein «xterm».  Schließe ich das, wird die 
>>  X‐Sitzung beendet.
>
>Und warum läuft sie nicht weiter, wenn doch der Window‐Manager im 
>Hintergrund laufen sollte?

Weil «xinit» nur auf den Prozess wartet, den er gestartet hat.  
Alles weiteren Prozess‐Enkel kümmern ihn nicht.  Er raubt der 
X‐Sitzung einfach den X‐Server.  Das Shell‐Kommando

   MANWIDTH=64 man --no-hyphenation --no-justification \
     -- 1 xinit |
   sed -e '/^DESCRIPTION$/,/^$/!d' -e '/[[:graph:]]/s/^/  /'

auf Debian Buster stimmt dem zu: 


   DESCRIPTION
          The xinit program is used to start the X Window System
          server and a first client program on systems that are
          not using a display manager such as xdm(1) or in
          environments that use multiple window systems.  When
          this first client exits, xinit will kill the X server
          and then terminate.

[Es geht um den Window‐Manager und die X‐Sitzung:] 

>_Der_ müßte die doch auch offenhalten? 
>

Wie sollte das gehen, wenn «xinit» den X‐Server beendet? 


>Oder wird der von der Shell, die die .xsession abarbeitet, nach 
>deren Ende mit "abgeräumt"?

Das könnte man so machen, dass «~/.xsession» am Ende den 
Window‐Manager beendet, ist aber nicht nötig, denn auch der 
Window‐Manager verliert den X‐Server (und ist hoffentlich wie alle 
anderen X11‐Programme so schlau, dann die Segel zu streichen und 
nicht sinnlos, Fehlermeldungen spucken, weiterzulaufen).

>>  Window‐Manager wechseln können möchte, ohne, dass mir die 
>>  X‐Sitzung beendet wird.  Aber prinzipiell kann man eine 
>>  X‐Sitzung auch an einen Window‐Manager statt an ein «xterm» 
>>  hängen.)
>
>Üblicherweise (? Hier jedenfalls...) läuft das doch so, daß der 
>_Window‐Manager_ den X-Server solange festhält, bis er über einen 
>eigenen Mechanismus (Menü o.w.a.i.) beendet wird.

Bist du sicher?  Wie soll ein X11‐Programm einen X‐Server, der 
beendet wird, festhalten können?  Wenn der X‐Server‐Prozess alle 
Verbindungen trennt und keine neuen mehr annimmt oder einfach zu 
Ende kommt, kann auch kein Window‐Manager mehr etwas ausrichten.

>>  Zeigst du mal deine Dateien «~/.xinitrc» und «~/.xession»? 
>>
>
>.xinitrc:
>--------------------------------------------
>#!/bin/sh
>
>userresources=$HOME/.Xresources
>userdefaults=$HOME/.Xdefaults
>usermodmap=$HOME/.Xmodmap
>sysresources=/usr/lib/X11/xinit/.Xresources
>sysmodmap=/usr/lib/X11/xinit/.Xmodmap
>
># merge in defaults and keymaps
>[ -f $sysresources ] && xrdb -merge $sysresources

[…]

># start the openbox session, if possible attached to consolekit
>if [ -e /usr/bin/ck-launch-session ] && [ -e /usr/bin/dbus-launch ];
>then
>exec /usr/bin/ck-launch-session /usr/bin/dbus-launch /usr/bin/openbox-session
>else exec /usr/bin/openbox-session
>fi
>--------------------------------------------

Danke.  Dann startet «/usr/bin/openbox-session» u. a. zuerst 
«~/.xsession» und schließlich einen Window‐Manager, auf den es 
wartet?  Verrät das Handbuch irgendetwas dazu, wie «openbox-session» 
«~/.xsession» nutzt?

So weit ich sehen kann, kommt dein «~/.xsession» ja sofort zu Ende, 
nachdem es einen «gpg-agent» gestartet hat:

>.xsession:
>--------------------------------------------
># This program, based on code found in the gpg-agent man page, is
># presumably licensed under the GPL.

[…]

>    eval $(gpg-agent --daemon)

[…]

>Hilft Dir das weiter? Anmerkung: "OOTB" (heißt das AFAIK). 
>

Das ist in der Tat sehr anders als das, was Debian macht. 


>Da kommt's auch darauf an, wie der X-Server selber aufgerufen wird 
>und was da sonst noch einzurichten ist. Ich habe da nicht groß 
>weiter dran rumgedreht, sondern das mehr oder weniger so genommen, 
>wie es die Distribution angeboten hat.

Welche Distribution ist das? 


>>  «startx» (eigentlich: «xinit») beendet die X‐Sitzung, wenn der 
>>  Prozess, den es als «"${HOME%/}"/.xinitrc» gestartet hat, zu 
>>  Ende kommt.
>
>Eigentlich doch der Prozess, den es als .xinitrc gestartet hat? 
>

Nein.  Der muss bei Debian die X‐Sitzung nicht beenden.  
Er kommt nur selber zu Ende.  Den X‐Server beendet «xinit».

Man könnte den Prozess beispielsweise mit «xwininfo» alle Fenster 
ausfindig machen und sie mit «xkill» alle abschießen lassen.  Das 
ist im Fall von «xinit» aber nicht nötig, weil «xinit» den X‐Server 
beendet.

>Die .xsession ist ja nur ein Unter- bzw. Nachfolgeprozess davon, 
>soweit ich das verstanden habe?

Hier sind «~/.xinitrc», «/etc/X11/Xsession» und «~/.xsession» alle 
nacheinander der selbe Prozess.

>> Wenn ich mich am grafischen Zugang (xdm) einlogge, dann wird 
>> ebenfalls das Shell‐Skript «/etc/X11/Xsession» abgearbeitet.
>
>Das ist aber was anderes als die .xsession, das ist ein 
>systemweites Start-Skript

Ja sicher, und das bestreite ich auch nicht.  In meiner 
«~/.xinitrc»‐Datei steht folgendes:

  #!/bin/sh
  set -u &&
  exec /etc/X11/Xsession "${HOME%/}"/.xsession

Trotzdem bleibt der von «xinit» gestartete Prozess – dank «exec» – 
über «/etc/X11/Xsession» bis zu «~/.xsession» derselbe Prozess.


>und evtl. sogar xdm-spezifisch - das gibt es hier garnicht, mit dem 
>lxdm.

Auf

   exec $STARTUP

in «/etc/X11/Xsession» läuft es bei mir auch hinaus, wenn nicht 
«~/.xinitrc» sondern der XDM «/etc/X11/Xsession» startet.

[Wenn «~/.xsession» schließlich den Window‐Manager startet…] 

>>> Dann fehlt dem evtl. am Ende noch einiges an Vorbereitung? 
>>>
>>
>>  Woran denkst du da?  Bei mir ist vor dem abschließenden Start 
>>  des Xterms alles an Vorbereitung geschehen.
>
>Bei einem anderen System halt ggfs. nicht - die Flexibilität des 
>Start-Vorgangs von X11 bietet da umfangreiche 
>Variationsmöglichkeiten. In Andreas' Fall kann es aber schon auch 
>sein, daß sein komisches Tastaturverbiegungsprogramm da Unsinn 
>angestellt hat und statt einen Eintrag _in_ ein Start-Skript 
>einzufügen das gleich komplett _über_- schrieben hat, so daß dessen 
>wesentliche Funktionen verloren gingen.

Möglich ist auch, dass er vor dem Unfall mit «xkbset-gui» die Datei 
«~/.xsession» gar nicht hatte und deshalb sein Display‐Manager ein 
sinnvolles Default betrieben hat.  Nach dem Unfall war sie aber da, 
und da hat sein Display‐Manager entschieden:  Aha, er hat 
«~/.xsession», also nehm' ich die und nicht mein Default.

Bisher hat Andreas sich nicht genauer dazu geäußert, wie es dazu 
kommt, dass «xkbset-gui» etwas in seine «~/.xsession» reinschreibt.

Wenn «xkbset-gui» nur ein Frontend zu «xkbset» ist, wundert mich das 
schon, denn «xkbset» schreibt meines Wissens nichts im 
HOME‐Verzeichnis.

Und da «~/.xsession» ja üblicherweise ein Shell‐Skript ist, ist es 
für ein Programm (also auch für «xkbset-gui») im Allgemeinen 
unmöglich, zu ermitteln, an welche Stelle da ein «xkbset»‐Kommando 
sinnvoll hineinzuschreiben wäre.

[toc] | [prev] | [next] | [standalone]

#120602 — Re: Wie funktioniert "${HOME}/.xsession"?

Helmut Waitzmann:
>Möglich ist auch, dass er vor dem Unfall mit «xkbset-gui» die Datei 
>«~/.xsession» gar nicht hatte und deshalb sein Display‐Manager ein 
>sinnvolles Default betrieben hat.  Nach dem Unfall war sie aber da, 
>und da hat sein Display‐Manager entschieden:  Aha, er hat 
>«~/.xsession», also nehm' ich die und nicht mein Default.

Sehr wahrscheinlich.

>Bisher hat Andreas sich nicht genauer dazu geäußert, wie es dazu 
>kommt, dass «xkbset-gui» etwas in seine «~/.xsession» reinschreibt.

>Wenn «xkbset-gui» nur ein Frontend zu «xkbset» ist, wundert mich das 
>schon, denn «xkbset» schreibt meines Wissens nichts im 
>HOME‐Verzeichnis.

xkbset-gui ist – jedenfalls in Debian buster – tatsächlich so
unsinnig programmiert, dass es an der Datei .xsession
herumpfuscht.  Zitat aus diesem Perl‐Programm:

>sub apply_changes {
>  system "xkbset " . ($mousekeys?"":"-") . "m " . ($mousekeysaccel?"":"-") . "ma $mk_delay $mk_interval $mk_time_to_max $mk_max_speed $mk_curve";
>}
>
>sub save_in_xsession {
>  if (defined($ENV{"HOME"})) {
>   if (-e "$ENV{'HOME'}/.xsession") {
>    system "perl -i -ne \"print if !/^xkbset /\" $ENV{'HOME'}/.xsession";
>   }
>   system "xkbset w >> $ENV{'HOME'}/.xsession";
>  }
>#  system "xkbset " . ($mousekeys?"":"-") . "m " . ($mousekeysaccel?"":"-") . "ma $mk_delay $mk_interval $mk_time_to_max $mk_max_speed $mk_curve";
>}

Genauer habe ich es nicht durchgesehen, aber apply_changes dürfte
die interaktiv gewählten Einstellungen in den X‐Server
übertragen, und save_in_xsession speichert die im X‐Server
vorhandenen Einstellungen in der Datei .xsession.

>Und da «~/.xsession» ja üblicherweise ein Shell‐Skript ist, ist es 
>für ein Programm (also auch für «xkbset-gui») im Allgemeinen 
>unmöglich, zu ermitteln, an welche Stelle da ein «xkbset»‐Kommando 
>sinnvoll hineinzuschreiben wäre.

Klar.


Friedhelm

[toc] | [prev] | [next] | [standalone]

#120521 — Re: [Gelöst] [lightdm] Kein grafisches User-Login (was: [lightdm] Kein grafisches User-Login)

Hallo Andreas Kohlbach,

Du schriebst am Mon, 03 Jan 2022 18:07:38 -0500:

> Brat mir einer einen Storch!
> 
> Es war die .xsession. Die habe ich nach /tmp geschoben und nun kann
> ich mich mit allen Usern, auch root, wieder in der GUI einloggen.

Na, das ist ja ein gewaltiger Fortschritt. Bliebe noch der Grund zu
finden.

> Die .xsession sah mir eher unspektakulär aus. Hier der Inhalt
> (eigentlich eine Zeile):
> 
> xkbset -b r rate 500 33 perkeyrepeat
> 00ffffffdffffbbffadfffefffedffff9ffffffffffffffffff7ffffffffffff m 1
...
Häh? Das schaut mir einigermaßen chaotisch aus. Bei mir ist die 
".xsession" ein Skript, das ein paar Voreinstellungen macht - gut, der
Aufruf von "xbset" könnte eine davon sein. Das kann ich nicht
beurteilen, weil es bei mir überhaupt kein "xkbset" gibt...

> Warum würde xinit die Verbindung verweigern? Vielleicht weil etwas wie
> 
> exec fvwm

Nicht, wenn das ähnlich wie hier läuft, der window/session/o.w.a.i.
manager wird da (indirekt) von der ".xinitrc" gestartet und macht dann
den "Befehlsinterpreter".

> am Ende fehlte? Dann wäre es schwach von der xkbset-gui gewesen, dafür
> beim Erstellen (bzw. Beschreiben) selbst keine Sorge getragen zu
> haben.

Was ist denn "xkbset-gui" wieder? Hast Du Dir da vielleicht ein
Malware-Ding eingefangen, das Gooeys^WGUIs kaputt macht? Deiner
Beschreibung nach könnte das gut sein...

> Hinweis: Mittels xkbset-gui aktivierte ich die "Keyboard Mouse",und
> erlaubte das Abspeichern der Konfig in die .xsession. Interessant,
> dass auch nach Wegschieben die Keyboard Mouse nun noch funktioniert.

Das müßte dann AFAIK doch aber eine "xmodmap" schreiben und die dann
laden? Macht das Laden etwa dieses seltsame "xkbset" mit den Unmengen
an Schaltern bei Dir, und noch dazu noch "xmodmap"?  Dann hat zumindest
das Erstellungsprogramm dafür Mist gebaut.
Hast Du ggfs. noch ein Backup von der ".xsession" und kannst mal
vergleichen, was da vorher drin stand? Sonst könnten da u.U. noch ein
paar "lu|ästige Effekte" damit auftauchen.
Wie o.g., bei mir ist das ein einfaches, lesbares Shellskript mit ein
paar einfach verständlichen Shell-Befehlen (und viel Kommentar).

> >> ich, wie schon beim anderen User, eingeloggt via *ssh* ein "startx"
> >> absetzte.
...
> Ich wollte nur sehen, ob das entweder funktioniert, oder brauchbare
> Fehlermeldungen bringt.

So sicher nicht.

> Problem gelöst. Danke an alle.

Nicht so eilig - Du hast eine Fehlerstelle gefunden und vorläufig
abgestellt. Sieh'erstmal zu, ob da nicht noch mehr aufgerissen ist, was
mit der korrumpierten ".xsession" zusammenhängt.

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

[toc] | [prev] | [next] | [standalone]

#120524 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Tue, 4 Jan 2022 20:24:04 +0100, Sieghard Schicktanz wrote:
>
> Hallo Andreas Kohlbach,
>
> Du schriebst am Mon, 03 Jan 2022 18:07:38 -0500:
>
>> Brat mir einer einen Storch!
>> 
>> Es war die .xsession. Die habe ich nach /tmp geschoben und nun kann
>> ich mich mit allen Usern, auch root, wieder in der GUI einloggen.
>
> Na, das ist ja ein gewaltiger Fortschritt. Bliebe noch der Grund zu
> finden.

Das Tool hatte keinen Aufruf für den Start der GUI in der Datei angefügt.

>> am Ende fehlte? Dann wäre es schwach von der xkbset-gui gewesen, dafür
>> beim Erstellen (bzw. Beschreiben) selbst keine Sorge getragen zu
>> haben.
>
> Was ist denn "xkbset-gui" wieder? Hast Du Dir da vielleicht ein
> Malware-Ding eingefangen, das Gooeys^WGUIs kaputt macht? Deiner
> Beschreibung nach könnte das gut sein...

"xkbset-gui" war direkt nach der Installation verfügbar.

[...]

>> Problem gelöst. Danke an alle.
>
> Nicht so eilig - Du hast eine Fehlerstelle gefunden und vorläufig
> abgestellt. Sieh'erstmal zu, ob da nicht noch mehr aufgerissen ist, was
> mit der korrumpierten ".xsession" zusammenhängt.

Die .xsession, die von "xkbset-gui" erstellt wurde, wurde entfernt. Ich
kann in ~/ keine verdächtige Einträge finden.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#120558 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Hallo Andreas Kohlbach,

Du schriebst am Tue, 04 Jan 2022 18:32:58 -0500:

> >> Es war die .xsession. Die habe ich nach /tmp geschoben und nun kann
...
> Das Tool hatte keinen Aufruf für den Start der GUI in der Datei
> angefügt.

Na, offenbar hat es ja die Datei überhaupt einfach völlig übergebügelt,
ohne Rücksicht auf irgendwas, was dort ggfs. vorher drinstand.
Das könnte man IMHO wohl durchaus der Kategorie "schwerwiegender
Software-Fehler" zuordnen.
BTW, wie sieht denn eine _funktionierende_ .xsession aus? Du hast da
ja jetzt (wieder) einen Vergleich. Oder gibt es die auf Deinem System
im Normalfall evtl. garnicht?

...
> > Was ist denn "xkbset-gui" wieder? Hast Du Dir da vielleicht ein
> > Malware-Ding eingefangen, das Gooeys^WGUIs kaputt macht? Deiner
> > Beschreibung nach könnte das gut sein...
> 
> "xkbset-gui" war direkt nach der Installation verfügbar.

Und woher kam diese Installation? Wenn das eine offizielle Distribution
ist, dann wäre da schonmal ein Käfer-Bericht ("Bug report") angebracht.
Und am besten dazu gleich eine entsprechende Mitteilung im zugehörigen
Forum, so vorhanden...

> [...]
> 
> >> Problem gelöst. Danke an alle.
> >
> > Nicht so eilig - Du hast eine Fehlerstelle gefunden und vorläufig
> > abgestellt. Sieh'erstmal zu, ob da nicht noch mehr aufgerissen ist,
> > was mit der korrumpierten ".xsession" zusammenhängt.
> 
> Die .xsession, die von "xkbset-gui" erstellt wurde, wurde entfernt.
> Ich kann in ~/ keine verdächtige Einträge finden.

Aber _gibt_ es im regulären System denn eine .xsession, und was _tut_
die dort, wenn ja? Wenn das System _ohne_ .xsession läuft, wie wird
_dann_ die "GUI" gestartet? Irgendwo muß die ja über den X-Server
aufgerufen werden - und wenn das nicht in der .xsession geht, muß es ja
wohl anderswo sein. Gibt es regulär auch eine .xsession mit Inhalt, der
nicht nur Kommentar iat, dann _fehlt_ dem System ohne diese doch wohl
"irgendetwas", und wenn Du nicht feststellst, _was_, dann kann es halt
sein, daß Du irgendwann unvermutet wieder tagelang 'rumsuchen mußt, um
auf die Ursache (keine .xsession, hätt' ich nie vermutet...) zu kommen.
Schnellfertig fällt halt auch schnell mal auf die Nase.

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

[toc] | [prev] | [next] | [standalone]

#120565 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Wed, 5 Jan 2022 22:38:17 +0100, Sieghard Schicktanz wrote:
>
> Hallo Andreas Kohlbach,
>
> Du schriebst am Tue, 04 Jan 2022 18:32:58 -0500:
>
>> >> Es war die .xsession. Die habe ich nach /tmp geschoben und nun kann
> ...
>> Das Tool hatte keinen Aufruf für den Start der GUI in der Datei
>> angefügt.
>
> Na, offenbar hat es ja die Datei überhaupt einfach völlig übergebügelt,
> ohne Rücksicht auf irgendwas, was dort ggfs. vorher drinstand.

Die Datei wurde neu angelegt.

> Das könnte man IMHO wohl durchaus der Kategorie "schwerwiegender
> Software-Fehler" zuordnen.
> BTW, wie sieht denn eine _funktionierende_ .xsession aus? Du hast da
> ja jetzt (wieder) einen Vergleich. Oder gibt es die auf Deinem System
> im Normalfall evtl. garnicht?

Derzeit gibt es keine, trotzdem funktioniert es (nun). Braucht man nicht,
wenn man keine speziellen Bedürfnisse hat.

> ...
>> > Was ist denn "xkbset-gui" wieder? Hast Du Dir da vielleicht ein
>> > Malware-Ding eingefangen, das Gooeys^WGUIs kaputt macht? Deiner
>> > Beschreibung nach könnte das gut sein...
>> 
>> "xkbset-gui" war direkt nach der Installation verfügbar.
>
> Und woher kam diese Installation? Wenn das eine offizielle Distribution
> ist, dann wäre da schonmal ein Käfer-Bericht ("Bug report") angebracht.
> Und am besten dazu gleich eine entsprechende Mitteilung im zugehörigen
> Forum, so vorhanden...

xkbset-gui wurde bei der initialen Installation (aus einem Debian Image)
zusammen mit xkbset (gleicher Zeitstempel) angelegt. Daher sollte ich in
der Tat einen Käfer-Bericht einreichen.

>> [...]
>> 
>> >> Problem gelöst. Danke an alle.
>> >
>> > Nicht so eilig - Du hast eine Fehlerstelle gefunden und vorläufig
>> > abgestellt. Sieh'erstmal zu, ob da nicht noch mehr aufgerissen ist,
>> > was mit der korrumpierten ".xsession" zusammenhängt.
>> 
>> Die .xsession, die von "xkbset-gui" erstellt wurde, wurde entfernt.
>> Ich kann in ~/ keine verdächtige Einträge finden.
>
> Aber _gibt_ es im regulären System denn eine .xsession, und was _tut_
> die dort, wenn ja? Wenn das System _ohne_ .xsession läuft, wie wird
> _dann_ die "GUI" gestartet?

Ja. Gravierender wird die GUI mit der (kaputten) .xsession nicht gestartet.

> Irgendwo muß die ja über den X-Server aufgerufen werden - und wenn das
> nicht in der .xsession geht, muß es ja wohl anderswo sein. Gibt es
> regulär auch eine .xsession mit Inhalt, der nicht nur Kommentar iat,
> dann _fehlt_ dem System ohne diese doch wohl "irgendetwas", und wenn Du
> nicht feststellst, _was_, dann kann es halt sein, daß Du irgendwann
> unvermutet wieder tagelang 'rumsuchen mußt, um auf die Ursache (keine
> .xsession, hätt' ich nie vermutet...) zu kommen.  Schnellfertig fällt
> halt auch schnell mal auf die Nase.

Hmm. Aus der Ferne betrachtet scheint das derzeitige Konzept einer
.xsession fragwürdig. Meiner bescheidenen Meinung nach sollte eine
existierende .xsession beachtet werden, auch wenn am Ende keine
"exec"-Zeile steht. Und das System einfach nach derer Abarbeitung selbst
die GUI starten sollte.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#120630 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Hallo Andreas Kohlbach,

Du schriebst am Wed, 05 Jan 2022 19:20:03 -0500:

> > BTW, wie sieht denn eine _funktionierende_ .xsession aus? Du hast da
> > ja jetzt (wieder) einen Vergleich. Oder gibt es die auf Deinem
> > System im Normalfall evtl. garnicht?
> 
> Derzeit gibt es keine, trotzdem funktioniert es (nun). Braucht man
> nicht, wenn man keine speziellen Bedürfnisse hat.

Mag sein. Wenn Du das sichergestellt hast, dann kannst Du damit
zufrieden sein.

> > ...
> > Aber _gibt_ es im regulären System denn eine .xsession, und was
> > _tut_ die dort, wenn ja? Wenn das System _ohne_ .xsession läuft,
> > wie wird _dann_ die "GUI" gestartet?
> 
> Ja. Gravierender wird die GUI mit der (kaputten) .xsession nicht
> gestartet.

"Ja" ist keine Antwort auf die Fragen. Andererseits mußt Du die nicht
hier, aber Du solltest sie Dir selber beantworten, 

> > Irgendwo muß die ja über den X-Server aufgerufen werden - und wenn
...
> Hmm. Aus der Ferne betrachtet scheint das derzeitige Konzept einer
> .xsession fragwürdig. Meiner bescheidenen Meinung nach sollte eine

Warum? Kannst Du das mit Sicherheit sagen, oder bist Du jetzt nur
sauer, weil Dir dieses komische Programm Dein Gooey verbastelt hat?
_Kennst_ Du alle Gründe für oder gegen eine solche Datei, und kannst Du
deshalb definitiv deren Sinnfälligkeit ausschließen? Das solltest Du
schon mal überlegen. Weitere Kommentare spar' ich mir dann...

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

[toc] | [prev] | [next] | [standalone]

#120634 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Fri, 7 Jan 2022 20:55:18 +0100, Sieghard Schicktanz wrote:
>
> Du schriebst am Wed, 05 Jan 2022 19:20:03 -0500:
>
>> > Irgendwo muß die ja über den X-Server aufgerufen werden - und wenn
> ...
>> Hmm. Aus der Ferne betrachtet scheint das derzeitige Konzept einer
>> .xsession fragwürdig. Meiner bescheidenen Meinung nach sollte eine
>
> Warum? Kannst Du das mit Sicherheit sagen, oder bist Du jetzt nur
> sauer, weil Dir dieses komische Programm Dein Gooey verbastelt hat?
> _Kennst_ Du alle Gründe für oder gegen eine solche Datei, und kannst Du
> deshalb definitiv deren Sinnfälligkeit ausschließen? Das solltest Du
> schon mal überlegen. Weitere Kommentare spar' ich mir dann...

Es macht aus der Ferne betrachtet - wie erwähnt - IMO keine Sinn: Will
ich X starten, sei es über startx oder lightdm, KDM, GDM etc., will ich X
starten. Wenn eine existierende .xsession das verhindert, nur weil am
Ende dieser kein Aufruf für den X-Server steht, halte ich das für einen
Design-Flaw.

Also sollte der X-Server auch mit einer "kaputten" .xsession starten. So
wie beispielsweise Linux selbst in der Regel auch durchbootet, wenn der
eine oder andere dabei aufgerufene Service eine kaputte Konfig, oder ein
anderes Problem hat.

Beispiel der Aufruf eines "Netzlaufwerks" in der /etc/fstab. Hatte ich
(dabei die Option "_netdev" nicht bedacht) mal. Aber mein ISP war
offline. Linux bootete, blieb stehen, als es das Laufwerk verbinden
wollte, bis es in einen Timeout lief, um dann doch erfolgreich zu Ende zu
booten. Man stelle sich vor, Linux würde sich aufgrund der
Nichterreichbarkeit eines Laufwerks weigern, komplett zu booten.

Wer immer der Maintainer der .xsession ist, sollte sich daran IMO ein
Beispiel nehmen: X starten, egal ob die .xsession kaputt ist, auch wenn
nur ein "exec"-Aufruf am Ende fehlt.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#120649 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Fri, 07 Jan 2022 18:23:22 -0500, Andreas Kohlbach wrote:

 
> Wer immer der Maintainer der .xsession ist, sollte sich daran IMO ein
> Beispiel nehmen: X starten, egal ob die .xsession kaputt ist, auch wenn
> nur ein "exec"-Aufruf am Ende fehlt.

Der Maintainer der ~/.xsession bist du. Wenn du eine hast, behauptest du
damit, besser zu wissen als die Distribution, wie deine Session zu starten hat.

Analog dazu könntest du in deine ~/.bash_profile ein logout einfügen.
Dann kannst du dich nur noch in der GUI anmelden, nicht mehr auf der Konsole.
Wer soll also deine .bash_profile auf Tauglichkeit prüfen?



-- 
Now, look. No one is to stone anyone until I blow this whistle.
Do you understand?
Even, an I want to make this absolutely clear...
...even if they do say the J-Word.

[toc] | [prev] | [next] | [standalone]

#120655 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Thomas Noll <-_tn_-@web.de>:
>Der Maintainer der ~/.xsession bist du. Wenn du eine hast, 
>behauptest du damit, besser zu wissen als die Distribution, wie 
>deine Session zu starten hat.
>
>Analog dazu könntest du in deine ~/.bash_profile ein logout 
>einfügen. Dann kannst du dich nur noch in der GUI anmelden,

Ich habe schon mal einen Display‐Manager gesehen (weiß nicht mehr, 
bei welcher Geschmacksrichtung von Unix das war), der beim 
grafischen Login nach dem Wechsel der Benutzerkennung auf den sich 
gerade einloggenden Benutzer einen nicht‐interaktiven Login‐Shell 
startet.  Wer da in der Benutzerdatenbank «bash» als Shell stehen 
hat, bei dem wird die Datei «~/.bash_profile» auch beim Start der 
X‐Sitzung abgearbeitet.  Ein «logout» darin führt dann direkt zum 
Logout.  Der Effekt ist dann genau derselbe wie bei einer 
«~/.xsession», die zu Ende kommt, ohne einen Session‐Manager, 
Window‐Manager oder Terminal‐Emulator zu starten.

[toc] | [prev] | [next] | [standalone]

#120662 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Sat, 8 Jan 2022 12:56:12 -0000 (UTC), Thomas Noll wrote:
>
> On Fri, 07 Jan 2022 18:23:22 -0500, Andreas Kohlbach wrote:
>
>  
>> Wer immer der Maintainer der .xsession ist, sollte sich daran IMO ein
>> Beispiel nehmen: X starten, egal ob die .xsession kaputt ist, auch wenn
>> nur ein "exec"-Aufruf am Ende fehlt.
>
> Der Maintainer der ~/.xsession bist du. Wenn du eine hast, behauptest du
> damit, besser zu wissen als die Distribution, wie deine Session zu starten hat.

*sigh*

OK, war nicht perfekt gesagt, aber ich hoffte, man versteht trotzdem.

Xsession hat eine Man Page, die unten auch Autoren nennt; und ich bin
nicht darunter.

| /etc/X11/Xsession is a Bourne shell (sh(1)) script which is run when an
| X Window System session is begun by startx or a display manager such as
| xdm.

> Analog dazu könntest du in deine ~/.bash_profile ein logout einfügen.
> Dann kannst du dich nur noch in der GUI anmelden, nicht mehr auf der Konsole.
> Wer soll also deine .bash_profile auf Tauglichkeit prüfen?

Die .bash_profile dürfte, analog zur .xsession, mit der bash zu tun
haben. Man stelle sich vor, man müsste am Ende der .bash_profile noch
eine bash aufrufen. Wenn man denn Aufruf nicht hätte, würde das Einloggen
verweigert. Catch 22, denn ohne sich einloggen zu können, könnte man die
.bash_profile nicht bearbeiten - damit man sich einloggen kann.

Für X aber ist das der Status-Quo.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#120665 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>On Sat, 8 Jan 2022 12:56:12 -0000 (UTC), Thomas Noll wrote: 
>
>> Der Maintainer der ~/.xsession bist du. Wenn du eine hast, 
>> behauptest du damit, besser zu wissen als die Distribution, wie 
>> deine Session zu starten hat.
>
>*sigh*
>
>OK, war nicht perfekt gesagt, aber ich hoffte, man versteht 
>trotzdem.
>
>Xsession hat eine Man Page, die unten auch Autoren nennt; und ich 
>bin nicht darunter.
>
>| /etc/X11/Xsession is a Bourne shell (sh(1)) script which is run
>| when an X Window System session is begun by startx or a display
>| manager such as xdm.
>
>> Analog dazu könntest du in deine ~/.bash_profile ein logout 
>> einfügen. Dann kannst du dich nur noch in der GUI anmelden, nicht 
>> mehr auf der Konsole. Wer soll also deine .bash_profile auf 
>> Tauglichkeit prüfen?
>
>Die .bash_profile dürfte, analog zur .xsession, mit der bash zu tun 
>haben. Man stelle sich vor, man müsste am Ende der .bash_profile 
>noch eine bash aufrufen.

Ihr vergleicht hier einander nicht entsprechendes:  
«~/.bash_profile» ist eine Startup‐Datei für einen Bash, den man als 
Login‐Shell startet.  «~/.xsession» ist keine Startup‐Datei für 
«/etc/X11/Xsession», sondern wird von ihm gestartet.  Eine Art 
Konfigurations‐Datei für «/etc/X11/Xsession» ist «~/.xsessionrc».  
Schaut im Handbuch «Xsession(5)» nach, wofür sie gedacht ist.


Richtig wäre der Vergleich so: 


Analog zur Datei «~/.xsession» ist das Feld «user command 
interpreter» in der Benutzerdatenbank (siehe das Handbuch 
«passwd(5)»).

Da dürfte bei den meisten Anwendern so etwas wie «/bin/bash» 
drinstehen.  Auch da kann man etwas anderes eintragen, etwa 
«/bin/true».

Wer das tut, braucht sich nicht zu wundern, warum er anschließend 
bei jedem Einloggen sofort wieder ausgeloggt wird, weil «/bin/true» 
nicht viel mehr tut, als sich mit Exit‐Status 0 zu beenden.

Und wie bei «~/.xsession» müsste das System das Halteproblem lösen, 
um entscheiden zu können, ob nach Beendigung des als «user command 
interpreter» eingetragenen Programms anschließend noch ein «/bin/sh» 
gestartet werden soll.

>Für X aber ist das der Status-Quo. 
>

=> Nicht nur für X, sondern für jeglichen Login‐Zugang ist das der 
Status‐Quo.


So ist das halt:  Der Anwender hat drei Möglichkeiten:  Entweder, er 
macht sich kundig – du bist ja gerade dabei – und kann dann nach 
Belieben Anpassungen vornehmen, oder, er lässt die Finger davon und 
begnügt sich mit den vom Administrator installierten Desktops und 
Login‐Shells, oder, er fummelt ohne Verständnis für die 
Zusammenhänge daran herum und fällt unter Umständen auf die 
Schnauze.

Ja, ich weiß, du wurdest von «xkbset-gui» hintergangen.  Insofern 
ist dein Auf‐die‐Schnauze‐Fallen nicht deine Schuld.  Steh trotzdem 
auf, schüttle den Staub vom Jacket, atme tief durch und reiche einen 
Bug‐Report für «xkbset-gui» ein.

Bis «xkbset-gui» dann zur Vernunft gekommen ist, kannst du folgendes 
machen:

Leg dir die Datei «~/.xsessionrc» an.  Sie muss nur lesbar, nicht 
ausführbar sein und soll «sh»‐Kommandos (suche im Handbuch 
«Xsession(5)» nach dem Text «.xsessionrc», um mehr zu 
erfahren) enthalten.

Schreib folgende Zeile hinein (das ist strenggenommen ein Missbrauch 
der Datei, weil es nicht um eine Umgebungs‐ sondern um eine interne 
Shell‐Variable von «/etc/X11/Xsession» geht, funktioniert aber):

USERXSESSION=$HOME/.Xsession

Dadurch übernimmt die Datei «~/.Xsession» die Rolle, die die Datei 
«~/.xsession» hätte übernehmen sollen, wenn «xkbset-gui» nicht 
dazwischengefunkt hätte, und die Datei «~/.xsession» wird frei für 
«xkbset-gui».

Natürlich legst du dann keine Datei «~/.Xsession» an, genau so, wie 
du keine Datei «~/.xsession» hattest, ehe «xkbset-gui» 
dazwischenfunkte.

Wenn du dann in «xkbset-gui» den «Save»‐Knopf drückst, wird zwar 
weiterhin in «~/.xsession» geschrieben.  Es bleibt aber beim 
grafischen Login wirkungslos.

Wenn du dann in die erste Zeile der Datei «~/.xsession» 


#!/bin/sh

einträgst und die Datei les‐ und ausführbar machst, kannst du das 
Ergebnis des «Save»‐Knopfs von «xkbset-gui» durch den Kommandoaufruf

   ~/.xsession

zur Wirkung bringen. 


Vorschlag für den Bug‐Report: 


Problembeschreibung:

«xkbset-gui» zerstört dem Anwender die Konfiguration der X‐Sitzung, 
wenn er beim Aufruf von «xkbset-gui» entweder noch keine Datei 
«~/.xsession» hat (denn das ist etwas anderes, als eine leere 
«~/.xsession» zu haben, siehe das Handbuch «Xsession(5)»), oder eine 
hat, bei der das Hinzufügen eines «xkbset»‐Aufrufs nicht sinnvoll 
machbar ist.


Abhilfe:

Der Anwender sollte «xkbset-gui» den Namen der Datei, die 
bearbeitet wird, per Aufruf‐Option mitteilen können

   xkbset-gui --modify-file=FILE

oder alternativ «xkbset-gui» anweisen können, die zu schreibenden 
Daten nur nach Standard Output zu schicken, damit er «xkbset-gui» 
mit passender Ausgabeumleitung starten kann:

   xkbset-gui --to-stdout

[toc] | [prev] | [next] | [standalone]

#120674 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Sun, 09 Jan 2022 08:16:18 +0100, Helmut Waitzmann wrote:
>
> Andreas Kohlbach <ank@spamfence.net>:
>> On Sat, 8 Jan 2022 12:56:12 -0000 (UTC), Thomas Noll wrote: 
>>> Der Maintainer der ~/.xsession bist du. Wenn du eine hast,
>>> behauptest du damit, besser zu wissen als die Distribution, wie 
>>> deine Session zu starten hat.
>>
>>*sigh*
>>
>> OK, war nicht perfekt gesagt, aber ich hoffte, man versteht
>> trotzdem.
>>
>> Xsession hat eine Man Page, die unten auch Autoren nennt; und ich
>> bin nicht darunter.
>>
>>| /etc/X11/Xsession is a Bourne shell (sh(1)) script which is run
>>| when an X Window System session is begun by startx or a display
>>| manager such as xdm.
>>
>>> Analog dazu könntest du in deine ~/.bash_profile ein logout
>>> einfügen. Dann kannst du dich nur noch in der GUI anmelden, nicht 
>>> mehr auf der Konsole. Wer soll also deine .bash_profile auf
>>> Tauglichkeit prüfen?
>>
>> Die .bash_profile dürfte, analog zur .xsession, mit der bash zu tun
>> haben. Man stelle sich vor, man müsste am Ende der .bash_profile 
>>noch eine bash aufrufen.
>
> Ihr vergleicht hier einander nicht entsprechendes:  «~/.bash_profile»
> ist eine Startup‐Datei für einen Bash, den man als Login‐Shell
> startet.  «~/.xsession» ist keine Startup‐Datei für
> «/etc/X11/Xsession», sondern wird von ihm gestartet.  Eine Art 
> Konfigurations‐Datei für «/etc/X11/Xsession» ist «~/.xsessionrc». 
> Schaut im Handbuch «Xsession(5)» nach, wofür sie gedacht ist.
>
>
> Richtig wäre der Vergleich so: 

Kann niemand dass eigentliche Problem verstehen?

Wenn ich früher bereits gesagt hätte, dass hier Erbsen von einigen
gezählt werden, hättest Du vielleicht geantwortet, dass es richtigerweise
Rosinen sein müssen.

> Analog zur Datei «~/.xsession» ist das Feld «user command interpreter»
> in der Benutzerdatenbank (siehe das Handbuch «passwd(5)»).

Datei != Feld

> Da dürfte bei den meisten Anwendern so etwas wie «/bin/bash»
> drinstehen.  Auch da kann man etwas anderes eintragen, etwa 
> «/bin/true».
>
> Wer das tut, braucht sich nicht zu wundern, warum er anschließend bei
> jedem Einloggen sofort wieder ausgeloggt wird, weil «/bin/true» nicht
> viel mehr tut, als sich mit Exit‐Status 0 zu beenden.

Das Beispiel sehe ich dazu als unpassend. Die /etc/passwd (oder welche *Datei*
Du auch immer meinst) wird vermutlich nur beim Aufruf von passwd
beschrieben. Die wenigsten User werden sie per Texteditor bearbeiten -
oder gar /bin/bash in /bin/true ändern.

> Und wie bei «~/.xsession» müsste das System das Halteproblem lösen, um
> entscheiden zu können, ob nach Beendigung des als «user command
> interpreter» eingetragenen Programms anschließend noch ein «/bin/sh» 
> gestartet werden soll.

Genau!

Besser IMHO, mögliche Fehler (auch Fehlendes) ignorieren.

>> Für X aber ist das der Status-Quo. 
>
> => Nicht nur für X, sondern für jeglichen Login‐Zugang ist das der
> Status‐Quo.
>
>
> So ist das halt:  Der Anwender hat drei Möglichkeiten:  Entweder, er
> macht sich kundig – du bist ja gerade dabei – und kann dann nach 
> Belieben Anpassungen vornehmen, oder, er lässt die Finger davon und
> begnügt sich mit den vom Administrator installierten Desktops und 
> Login‐Shells, oder, er fummelt ohne Verständnis für die Zusammenhänge
> daran herum und fällt unter Umständen auf die Schnauze.
>
> Ja, ich weiß, du wurdest von «xkbset-gui» hintergangen.  Insofern ist
> dein Auf‐die‐Schnauze‐Fallen nicht deine Schuld.  Steh trotzdem auf,
> schüttle den Staub vom Jacket, atme tief durch und reiche einen
> Bug‐Report für «xkbset-gui» ein.

Habe ich gerade.

[...]
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#120699 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>On Sun, 09 Jan 2022 08:16:18 +0100, Helmut Waitzmann wrote: 
>
>> Andreas Kohlbach <ank@spamfence.net>:
>>> On Sat, 8 Jan 2022 12:56:12 -0000 (UTC), Thomas Noll wrote: 
>>>
>> Ihr vergleicht hier einander nicht entsprechendes:  
>> «~/.bash_profile» ist eine Startup‐Datei für einen Bash, den man 
>> als Login‐Shell startet.  «~/.xsession» ist keine Startup‐Datei 
>> für «/etc/X11/Xsession», sondern wird von ihm gestartet.  Eine 
>> Art Konfigurations‐Datei für «/etc/X11/Xsession» ist 
>> «~/.xsessionrc».
>>
>>
>> Richtig wäre der Vergleich so: 
>>
>
>Kann niemand dass eigentliche Problem verstehen? 
>

Das frage ich mich auch.  Das eigentliche Problem ist, dass du 
Unmögliches von deinem Rechner verlangst.  Alle Versuche, dir zu 
erklären, warum das, was du verlangst, nicht erfüllt werden kann, 
sind anscheinend bisher gescheitert.

>> Analog zur Datei «~/.xsession» ist das Feld «user command 
>> interpreter» in der Benutzerdatenbank (siehe das Handbuch 
>> «passwd(5)»).
>
>Datei != Feld 
>

Das spielt für die theoretische Informatik keine Rolle.  Worauf es 
ankommt, ist folgendes:  Sowohl der Inhalt von «~/.xsession» als 
auch der Inhalt des Feldes «user command interpreter» in der 
Benutzerdatenbank können ein beliebiges Programm darstellen.

Das bedeutet, dass das System, um überprüfen zu können, ob das 
jeweils angegebene Programm noch irgendeine Nachhilfe braucht, um 
den Loginvorgang nicht (versehentlich) sofort zu Ende kommen zu 
lassen, das Halteproblem (siehe bei Wikipedia 
<https://de.wikipedia.org/wiki/Halteproblem#top>) lösen müsste.  Und 
wenn du jetzt den ersten Abschnitt des Wikipedia‐Artikels liest, 
erfährst du, dass das Halteproblem nicht für jedes beliebige 
Programm lösbar ist.

=> Dein Wunsch, das Starten einer X‐Sitzung soll doch bitte tolerant 
sein und bei «~/.xsession»‐Programmen, die sich beenden, 
entscheiden, ob nachträglich noch ein Session‐Manager gestartet 
werden soll oder nicht, überfordert die Fähigkeiten des Systems:  Es 
gibt keinen Algorithmus, der diese Entscheidung für jedes mögliche 
«~/.xsession»‐Programm und für jedes im Feld «user command 
interpreter» eingetragene Programm fällen könnte.

>> Da dürfte bei den meisten Anwendern so etwas wie «/bin/bash» 
>> drinstehen.  Auch da kann man etwas anderes eintragen, etwa 
>> «/bin/true».
>>
>> Wer das tut, braucht sich nicht zu wundern, warum er anschließend 
>> bei jedem Einloggen sofort wieder ausgeloggt wird, weil 
>> «/bin/true» nicht viel mehr tut, als sich mit Exit‐Status 0 zu 
>> beenden.
>
>Das Beispiel sehe ich dazu als unpassend. Die /etc/passwd (oder 
>welche *Datei* Du auch immer meinst)

Ich meine die Benutzerdatenbank, in der für jedes Benutzerkonto 
vermerkt ist, welches Programm beim Einloggen als Shell gestartet 
werden soll.  Ob die Datenbank nun aus einer Datei («/etc/passwd») 
oder aus mehreren Dateien und Verzeichnissen besteht, ob sie mit 
einem Texteditor oder mit dem Programm «chsh» (siehe das Handbuch 
«chsh(1)») bearbeitet wird, spielt keine Rolle.  Fehlerhafte 
Einträge kann sie so oder enthalten, wenn man mit dem Texteditor 
oder mit «chsh» einen Fehler macht.

>wird vermutlich nur beim Aufruf von passwd beschrieben. Die 
>wenigsten User werden sie per Texteditor bearbeiten - oder gar 
>/bin/bash in /bin/true ändern.

Also nochmal im Einzelnen:  Wer in seine Datei «~/.bash_profile» aus 
Versehen irgend etwas hineinschreibt, das dazu führt, dass der Bash 
gleich zu Ende kommt, kann vom System nicht verlangen, dass es das 
erkennt und den Anwender deshalb nicht ausloggt, sondern ihm 
beispielsweise (als Ersatz) einen «/bin/sh» startet, damit er die 
Möglichkeit hat, seinen Fehler (mit einem Texteditor) zu beheben.

Ebensowenig kann jemand verlangen, dass das System seine 
«~/.xsession»‐Datei als fehlerhaft erkennt und ihm eine rudimentäre 
X‐Sitzung gibt, damit er den Fehler beheben kann.

Der Grund, dass er das vom System nicht verlangen kann, ist, dass 
das System dazu prinzipiell nicht in der Lage ist, zu entscheiden, 
ob die Datei «~/.bash_profile» (oder «~/.xsession») dazu führt, dass 
man gleich wieder ausgeloggt wird oder nicht.

Das System könnte versuchen, einfach eine Stoppuhr zu benutzen und 
dann zu entscheiden:  Wenn das Ausloggen innerhalb einer 
Zehntelsekunde geschieht, dann war es sicher eine fehlerhafte Datei 
«~/.bash_profile», und deshalb wird noch ein «/bin/sh» gestartet.  
(Entsprechend bei «~/.xsession»).

Das kann aber zu falschen Entscheidungen führen:  Lass auf deinem 
System mal das Kommando

grep -E -e '^([^:]*:){6}/bin/(true|false)($|:)' -- /etc/passwd

laufen.  Erhältst du eine Ausgabe?  Ich erhalte hier auf Debian 
Buster eine.

=> Es gibt Benutzer in der Datenbank, bei denen als Shell 
tatsächlich «/bin/true» oder «/bin/false» eingetragen ist – und das 
mit voller Absicht.

Einen ähnlichen Effekt wie «/bin/false» in der Datenbank hätte man, 
wenn die Datei «~/.bash_profile» ein (möglicherweise fehlerhaftes) 
Shell‐Kommando enthielte, das dazu führt, dass der Bash sich gleich 
beendet.

Ein automatisches anschließendes Starten eines «/bin/sh», weil 
«/bin/true», «/bin/false» oder ein «/bin/bash» innerhalb einer 
Zehntelsekunde bereits beendet waren, wäre ein scheunentorgroßes 
Sicherheitsloch.

Kein Algorithmus kann entscheiden, ob das Beenden nach kurzer Zeit 
beabsichtigt oder ein Fehler ist.  Deshalb kann es auch kein 
fehlertolerantes Login‐ oder X‐Sitzungssystem geben.

>> Und wie bei «~/.xsession» müsste das System das Halteproblem 
>> lösen, um entscheiden zu können, ob nach Beendigung des als «user 
>> command interpreter» eingetragenen Programms anschließend noch 
>> ein «/bin/sh» gestartet werden soll.
>
>Genau!

Du hast den Wikipedia‐Artikel zum Halteproblem nicht angesehen.  
Stimmt's?  Sonst hättest du gleich im ersten Abschnitt lesen können, 
dass das «Genau!» eine unerfüllbare Forderung an dein System 
darstellt.  Die müsste es aber erfüllen, um Fehler von 
beabsichtigtem Verhalten trennen zu können.  Ohne Fehlererkennung 
gibt es auch keine Fehlerbehebung, deshalb ist 

>Besser IMHO, mögliche Fehler (auch Fehlendes) ignorieren. 
>

nicht machbar. 


>> reiche einen Bug‐Report für «xkbset-gui» ein. 
>>
>
>Habe ich gerade. 
>

Gut.  Und bis der Fehler bei «xkbset-gui» behoben ist, machst du, 
was ich dir mit «~/.xsessionrc», «~/.Xsession» und «~/.xsession» 
vorgeschlagen habe.  Dann kannst du «xkbset-gui» verwenden, ohne, 
dass es dir die X‐Sitzung zerstört.

[toc] | [prev] | [next] | [standalone]

#120703 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Sun, 09 Jan 2022 22:47:44 +0100, Helmut Waitzmann wrote:
>
> Andreas Kohlbach <ank@spamfence.net>:
>> On Sun, 09 Jan 2022 08:16:18 +0100, Helmut Waitzmann wrote: 
>>> Andreas Kohlbach <ank@spamfence.net>:
>>>> On Sat, 8 Jan 2022 12:56:12 -0000 (UTC), Thomas Noll wrote: 
>>> Ihr vergleicht hier einander nicht entsprechendes: 
>>> «~/.bash_profile» ist eine Startup‐Datei für einen Bash, den man 
>>> als Login‐Shell startet.  «~/.xsession» ist keine Startup‐Datei für
>>> «/etc/X11/Xsession», sondern wird von ihm gestartet.  Eine Art
>>> Konfigurations‐Datei für «/etc/X11/Xsession» ist «~/.xsessionrc».
>>>
>>>
>>> Richtig wäre der Vergleich so: 
>>
>> Kann niemand dass eigentliche Problem verstehen? 
>
> Das frage ich mich auch.  Das eigentliche Problem ist, dass du
> Unmögliches von deinem Rechner verlangst.  Alle Versuche, dir zu 
> erklären, warum das, was du verlangst, nicht erfüllt werden kann, sind
> anscheinend bisher gescheitert.

Nein. Dass ich nicht erkennen will, warum eine existierende, aber kaputte
.xsession das Starten der GUI verhindert.

>>> Analog zur Datei «~/.xsession» ist das Feld «user command
>>> interpreter» in der Benutzerdatenbank (siehe das Handbuch 
>>> «passwd(5)»).
>>
>> Datei != Feld 
>
> Das spielt für die theoretische Informatik keine Rolle.  Worauf es
> ankommt, ist folgendes:  Sowohl der Inhalt von «~/.xsession» als 
> auch der Inhalt des Feldes «user command interpreter» in der
> Benutzerdatenbank können ein beliebiges Programm darstellen.
>
> Das bedeutet, dass das System, um überprüfen zu können, ob das jeweils
> angegebene Programm noch irgendeine Nachhilfe braucht, um den
> Loginvorgang nicht (versehentlich) sofort zu Ende kommen zu lassen,
> das Halteproblem (siehe bei Wikipedia
> <https://de.wikipedia.org/wiki/Halteproblem#top>) lösen müsste.  Und 
> wenn du jetzt den ersten Abschnitt des Wikipedia‐Artikels liest,
> erfährst du, dass das Halteproblem nicht für jedes beliebige 
> Programm lösbar ist.

Die Erwähnung des Halteproblems mag angebracht, seine Erwähnung macht
allerdings das eigentliche unnötig komplex.

> => Dein Wunsch, das Starten einer X‐Sitzung soll doch bitte tolerant
> sein und bei «~/.xsession»‐Programmen, die sich beenden, 
> entscheiden, ob nachträglich noch ein Session‐Manager gestartet werden
> soll oder nicht, überfordert die Fähigkeiten des Systems:  Es gibt
> keinen Algorithmus, der diese Entscheidung für jedes mögliche
> «~/.xsession»‐Programm und für jedes im Feld «user command 
> interpreter» eingetragene Programm fällen könnte.

Mein Wunsch überfordert in der Tat die Fähigkeiten des System. Daher
sollte es IMO angepasst werden. Denn andere "Einlog-Methoden" sind
gegenüber Fehlern in ihren Konfigs auch tolerant.

So steht eine kaputte .bash_profile nie im Weg, den User trotzdem
einloggen zu lassen.

Warum nicht auch für X?

[...]

Gelöscht.

Du scheinst dass "ganz platte" Problem nicht zu sehen: Mit einer kaputten
.bash_profile wird dem User trotzdem ein Login erlaubt. Mit einer
kaputten .xsession wird ihm das Einloggen in eine GUI dagegen verwert.

Mein Fazit: eine kaputte .xsession sollte ignoriert werden.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#120741 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net> writes:

> So steht eine kaputte .bash_profile nie im Weg, den User trotzdem
> einloggen zu lassen.

Dann mache doch mal das Experiment und mache Deine .bash_profile kaputt,
indem Du ein

exit

ans Ende schreibst.

Viele Grüße, Thomas
PS: Probiere aber bitte NICHT hinterher als root aus, ob das Problem
reproduzierbar ist.
-- 
Adresse gilt nur kurzzeitig!

[toc] | [prev] | [next] | [standalone]

#120743 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Hallo Andreas Kohlbach,

Du schriebst am Sun, 09 Jan 2022 18:34:54 -0500:

> > Unmögliches von deinem Rechner verlangst.  Alle Versuche, dir zu 
> > erklären, warum das, was du verlangst, nicht erfüllt werden kann,
> > sind anscheinend bisher gescheitert.
> 
> Nein. Dass ich nicht erkennen will, warum eine existierende, aber
> kaputte .xsession das Starten der GUI verhindert.

Tja, manchne Leuten kann man auch nicht erklären, warum eine kaputte
Brücke das Erreichen des anderen Ufers verhindern soll. Bevorzugt
denen, die ausschließlch Comic-Videos anschauen.

...
> Die Erwähnung des Halteproblems mag angebracht, seine Erwähnung macht
> allerdings das eigentliche unnötig komplex.

Wenn Du an den Grundlagen der Funktion von Computern interessiert wärst,
wäre das für Dich eine schöne Möglichkeit, über diese eine Menge zu
erfahren. Bist Du halt offensichtlich nicht. Dann mußt Du Dich halt mit
dem Befolgen von Rezepten und der Erklärung "das hilft bei Deiner
Krankheit sicher" begnügen.

...
> Mein Wunsch überfordert in der Tat die Fähigkeiten des System. Daher
                                                               ^s
> sollte es IMO angepasst werden. Denn andere "Einlog-Methoden" sind
> gegenüber Fehlern in ihren Konfigs auch tolerant.

Du kannst es selber anpassen, wenn Du dasanderen nicht zutraust.

> So steht eine kaputte .bash_profile nie im Weg, den User trotzdem
> einloggen zu lassen.

Dann probiere doch mal die folgende, besteht nur aus einem einzigen
Befehl:
------
logout
------
(BTW: Hier gibt es nichtmal eine ".bash_profile"...)

> Warum nicht auch für X?

Aus demselben Grund.

> [...]
> 
> Gelöscht.
> 
> Du scheinst dass "ganz platte" Problem nicht zu sehen: Mit einer
> kaputten .bash_profile wird dem User trotzdem ein Login erlaubt. Mit
> einer kaputten .xsession wird ihm das Einloggen in eine GUI dagegen
> verwert.
> 
> Mein Fazit: eine kaputte .xsession sollte ignoriert werden.

Dann schreib' halt ein Programm, das "eine kaputte .xsession"
zuverlässig erkennt und stelle das zur Verfügung. Oder nutz' es halt
nur für Dich allein privat. Sollte ja kein Problem sein, wenn das ein
"ganz plattes" Problem ist.

ODER?

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

[toc] | [prev] | [next] | [standalone]

#120746 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

Andreas Kohlbach <ank@spamfence.net>:
>On Sun, 09 Jan 2022 22:47:44 +0100, Helmut Waitzmann wrote: 
>>
>> Andreas Kohlbach <ank@spamfence.net>:

>>> Kann niemand dass eigentliche Problem verstehen? 
>>>
>>
>> Das frage ich mich auch.  Das eigentliche Problem ist, dass du 
>> Unmögliches von deinem Rechner verlangst.  Alle Versuche, dir zu 
>> erklären, warum das, was du verlangst, nicht erfüllt werden kann, 
>> sind anscheinend bisher gescheitert.
>
>Nein. Dass ich nicht erkennen will, warum eine existierende, aber 
>kaputte .xsession das Starten der GUI verhindert.
>

Also momentan ist es ja so, dass eine Datei «~/.xsession», in der 
nur ein «xkbset»‐Aufruf (hineingesetzt von «xkbset-gui») drinsteht, 
dem Benutzer eine X‐Sitzung gibt, die nur den «xkbset»‐Aufruf macht 
und sich danach sofort beendet, anstatt eine Grafik‐Umgebung 
hochzuziehen.  Dadurch ist sie kaputt.

Wie müsste ein System konkret reagieren, das so eine Datei 
«~/.xsession», in der nur dieser eine «xkbset»‐Aufruf drinsteht, 
vorfindet?

Müsste es die Datei beim Einloggen untersuchen?  Welche Fragen 
müsste es bei der Untersuchung stellen und beantworten?  Wie müssten 
die Antworten ausfallen, damit das System Handlungsbedarf sieht?

Falls das System dabei Handlungsbedarf erkennt: 


Soll es die Datei anpassen?  Wo soll es Text ein‐ oder anfügen?  
Soll es Text löschen?

Oder alternativ, wenn das System die Datei nicht verändern, nur 
anders auf sie reagieren soll:  Wie müsste es die X‐Sitzung 
anpassen?  Sollte es die Datei einfach links liegenlassen und so 
verfahren, als gäbe es sie nicht?

Oder soll es die Datei ausführen und, wenn es damit fertig ist, die 
X‐Sitzung nicht beenden, sondern noch eine Grafik‐Umgebung 
hinterherschieben, so, als hätte ein entsprechender Aufruf in der 
Datei «~/.xsession» bereits drin gestanden?

Kannst du – meinetwegen gerne in eigenen Worten oder als 
Shell‐Skript‐Idee – beschreiben, wonach beispielsweise das System in 
der Datei «~/.xsession» suchen soll?  Wie kommt es zum Ergebnis «die 
Datei ist in Ordnung» oder «die Datei ist defekt»?

>Die Erwähnung des Halteproblems mag angebracht, seine Erwähnung 
>macht allerdings das eigentliche unnötig komplex.

Meiner Meinung nach ist das Eigentliche exakt so komplex wie das 
Halteproblem.  Aber ich möchte nicht einfach mit dem Fuß aufstampfen 
sondern gerne deine Vorschläge zur Vereinfachung hören und 
diskutieren.

>Mein Wunsch überfordert in der Tat die Fähigkeiten des System. 
>Daher sollte es IMO angepasst werden. Denn andere "Einlog-Methoden" 
>sind gegenüber Fehlern in ihren Konfigs auch tolerant.
>
>So steht eine kaputte .bash_profile nie im Weg, den User trotzdem 
>einloggen zu lassen.

Mach bitte den Versuch, den Thomas Dorner vorgeschlagen hat:  Mach 
deine Datei «~/.bash_profile» kaputt, indem du vor die erste Zeile 
eine Zeile mit dem Inhalt

   exit

einfügst.

Log dich nicht aus, sondern wechsle auf eine weitere virtuelle 
Konsole und log dich dort textorientiert ein.

Wechsle zu der Sitzung, in der der Editor läuft, zurück.  Nimm die 
Änderung an der Datei «~/.bash_profile» zurück.

Berichte vom Versuchsergebnis.  Dann kann man die Frage 


>Warum nicht auch für X? 
>

in der Tat stellen. 

[toc] | [prev] | [next] | [standalone]

#120755 — Re: [Gelöst] [lightdm] Kein grafisches User-Login

On Mon, 10 Jan 2022 20:24:07 +0100, Helmut Waitzmann wrote:
>
> Andreas Kohlbach <ank@spamfence.net>:
>> On Sun, 09 Jan 2022 22:47:44 +0100, Helmut Waitzmann wrote: 
>>>
>>> Andreas Kohlbach <ank@spamfence.net>:
>
>>>> Kann niemand dass eigentliche Problem verstehen? 
>>>
>>> Das frage ich mich auch.  Das eigentliche Problem ist, dass du
>>> Unmögliches von deinem Rechner verlangst.  Alle Versuche, dir zu 
>>> erklären, warum das, was du verlangst, nicht erfüllt werden kann,
>>> sind anscheinend bisher gescheitert.
>>
>> Nein. Dass ich nicht erkennen will, warum eine existierende, aber
>> kaputte .xsession das Starten der GUI verhindert.
>>
>
> Also momentan ist es ja so, dass eine Datei «~/.xsession», in der nur
> ein «xkbset»‐Aufruf (hineingesetzt von «xkbset-gui») drinsteht, dem
> Benutzer eine X‐Sitzung gibt, die nur den «xkbset»‐Aufruf macht und
> sich danach sofort beendet, anstatt eine Grafik‐Umgebung
> hochzuziehen.  Dadurch ist sie kaputt.
>
> Wie müsste ein System konkret reagieren, das so eine Datei
> «~/.xsession», in der nur dieser eine «xkbset»‐Aufruf drinsteht, 
> vorfindet?
>
> Müsste es die Datei beim Einloggen untersuchen?  Welche Fragen müsste
> es bei der Untersuchung stellen und beantworten?  Wie müssten die
> Antworten ausfallen, damit das System Handlungsbedarf sieht?

Wenn am Ende der .xsession keine

exec $IRGENDWAS

steht, sollten alle Einträge in .xsession verworfen werden, um X trotzdem
zu starten.

> Falls das System dabei Handlungsbedarf erkennt: 
>
> Soll es die Datei anpassen?  Wo soll es Text ein‐ oder anfügen?  Soll
> es Text löschen?
>
> Oder alternativ, wenn das System die Datei nicht verändern, nur anders
> auf sie reagieren soll:  Wie müsste es die X‐Sitzung anpassen?  Sollte
> es die Datei einfach links liegenlassen und so verfahren, als gäbe es
> sie nicht?
>
> Oder soll es die Datei ausführen und, wenn es damit fertig ist, die
> X‐Sitzung nicht beenden, sondern noch eine Grafik‐Umgebung 
> hinterherschieben, so, als hätte ein entsprechender Aufruf in der
> Datei «~/.xsession» bereits drin gestanden?

Es sollte einfach eine existieren und möglicherweise kaputte .xsession
ignorieren.

> Kannst du – meinetwegen gerne in eigenen Worten oder als
> Shell‐Skript‐Idee – beschreiben, wonach beispielsweise das System in 
> der Datei «~/.xsession» suchen soll?  Wie kommt es zum Ergebnis «die
> Datei ist in Ordnung» oder «die Datei ist defekt»?

Wenn eine Xsession (oder .xsession eines Users) Fehler aufweist und damit
nicht zuverlässig geparst werden kann, sollte X deren Inhalt ignorieren,
und trotzdem starten.

[...]

Ganz platt: eine kaputte .bash_profile erlaubt es jedem Benutzer eine
Shell zu erlangen. Eine kaputte .xsession verwehrt einem User aber das
Einloggen in eine GUI.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web