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

Groups > linux.debian.user > #204827 > unrolled thread

logout kills X

Back to article view | Back to linux.debian.user

Contents

  logout kills X hohe72@arcor.de - 2019-01-30 18:40 +0100
    Re: logout kills X deloptes <deloptes@gmail.com> - 2019-01-30 19:30 +0100
      Re: logout kills X Brian <ad44@cityscape.co.uk> - 2019-01-30 19:40 +0100
      Re: logout kills X Holger Herrlich <hohe72@arcor.de> - 2019-01-31 15:10 +0100
    Re: logout kills X Felix Miata <mrmazda@earthlink.net> - 2019-01-30 19:50 +0100
      Re: logout kills X Brian <ad44@cityscape.co.uk> - 2019-01-30 20:20 +0100
        Re: logout kills X Felix Miata <mrmazda@earthlink.net> - 2019-01-30 21:00 +0100
          Re: logout kills X Brian <ad44@cityscape.co.uk> - 2019-01-30 21:30 +0100
            Re: logout kills X Holger Herrlich <hohe72@arcor.de> - 2019-01-31 15:30 +0100
          Re: logout kills X Holger Herrlich <hohe72@arcor.de> - 2019-01-31 15:30 +0100
            Re: logout kills X Felix Miata <mrmazda@earthlink.net> - 2019-01-31 19:00 +0100
              Re: logout kills X Brian <ad44@cityscape.co.uk> - 2019-01-31 19:40 +0100
                Re: logout kills X David Wright <deblis@lionunicorn.co.uk> - 2019-01-31 20:00 +0100
                  Re: logout kills X Brian <ad44@cityscape.co.uk> - 2019-01-31 21:00 +0100
                    Re: logout kills X Greg Wooledge <wooledg@eeg.ccf.org> - 2019-01-31 21:10 +0100
                      Re: logout kills X David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 05:30 +0100
                      Re: logout kills X Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2019-02-02 22:50 +0100
                    Re: logout kills X Curt <curty@free.fr> - 2019-02-01 12:00 +0100
                      Re: logout kills X Brian <ad44@cityscape.co.uk> - 2019-02-01 23:40 +0100
                        Re: logout kills X <tomas@tuxteam.de> - 2019-02-02 11:00 +0100
                [solved] Re: logout kills X Holger Herrlich <hohe72@arcor.de> - 2019-02-01 17:20 +0100
                  [cause] Re: logout kills X Holger Herrlich <hohe72@arcor.de> - 2019-02-04 11:40 +0100
        Re: logout kills X David Wright <deblis@lionunicorn.co.uk> - 2019-01-30 21:00 +0100
          Re: logout kills X Brian <ad44@cityscape.co.uk> - 2019-01-30 21:40 +0100
            Re: logout kills X Brian <ad44@cityscape.co.uk> - 2019-01-31 00:40 +0100
            Re: logout kills X Holger Herrlich <hohe72@arcor.de> - 2019-01-31 15:20 +0100
          Re: Let's play "Where is X?" (was: logout kills X) Felix Miata <mrmazda@earthlink.net> - 2019-01-30 23:10 +0100
            Re: Let's play "Where is X?" (was: logout kills X) Brian <ad44@cityscape.co.uk> - 2019-01-30 23:40 +0100
              Re: Let's play "Where is X?" Felix Miata <mrmazda@earthlink.net> - 2019-01-31 00:00 +0100
                Re: Let's play "Where is X?" Brian Potkin <brian@copernicus.org.uk> - 2019-01-31 00:10 +0100
                  Re: Let's play "Where is X?" Felix Miata <mrmazda@earthlink.net> - 2019-01-31 03:00 +0100
            Let's play "Where is X?" (was: logout kills X) Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2019-02-02 23:30 +0100
              Re: Let's play "Where is X?" (was: logout kills X) Felix Miata <mrmazda@earthlink.net> - 2019-02-03 00:40 +0100
                Re: Let's play "Where is X?" (was: logout kills X) <tomas@tuxteam.de> - 2019-02-03 10:10 +0100
                  Re: Let's play "Where is X?" (was: logout kills X) Default User <hunguponcontent@gmail.com> - 2019-02-03 17:10 +0100
                    Re: Let's play "Where is X?" (was: logout kills X) Rusi Mody <rustompmody@gmail.com> - 2019-02-04 04:50 +0100
              Re: Let's play "Where is X?" (was: logout kills X) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-04 15:30 +0100
    Re: logout kills X Holger Herrlich <hohe72@arcor.de> - 2019-01-31 15:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#204899 — [solved] Re: logout kills X

On Thu, 31 Jan 2019 18:36:58 +0000
Brian <ad44@cityscape.co.uk> wrote:

> On Thu 31 Jan 2019 at 12:56:59 -0500, Felix Miata wrote:
> 
> > tty1 became special with the introduction of systemd. Do not use
> > tty1 for X. Instead use tty2 and/or tty3 and/or tty4 and/or tty5
> > and/or tty6. Buster may have this fixed, as upstream has apparently
> > fixed it 3 months ago.  
> 
> The behaviour on unstable is unchanged from stretch. To use tty1 for
> X, move ~/.bash_logout

That's it. In especially commenting out everything in .bash_logout. At
least for my old Laptop... and this one.

> out of the way or alter it. That doesn't mean the origin of the bug
> doesn't involve systemd or X, but it removes the problem

Thanks.

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

#204973 — [cause] Re: logout kills X

The crash happens due to a race condition in switching forth and back
using:

 ioctl(fd,VT_ACTIVATE,  tmp_tty)
 ioctl(fd,VT_WAITACTIVE,tmp_tty)
                                <- here
 ioctl(fd,VT_ACTIVATE,  org_tty)
 ioctl(fd,VT_WAITACTIVE,org_tty)

in clear_console.c's clear_console() function.
https://launchpad.net/ubuntu/+source/bash/5.0-2ubuntu1


Being offline, I couldn't check this code directly. However I wrote a
demo that mostly constitutes the clear_console() function in
clear_console.c (link above).


course:

startx on tty1
start demo on tty2
-> get an unresponsive but still running X session

however:
blindly typing: chvt 3
brings me back to tty3
(chvt 2 would do nothing, while the system thinks it's always where)

also:
[alt]+[F3] brings me back to tty3

then:
switching to tty1, whatever how, X realizes something went wrong and
crashes.



If I put sleep(1) inbetween (at the here marker) everything is fine
(you know what I mean). Henceforth and because of the input/output
split (schizophrenia) X session, I guess, this is a race condition and
at this point (missing debugging skills) I'm out.



Demo:

// gcc -Wall <whatever-you-name-it>.c

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/kd.h>
#include <linux/vt.h>


int
main() {

  char* file = "/dev/tty";  // arbitrary choosing the one that works
  int   fd   = open( file,O_RDWR );
  if( fd<0 && errno==EACCES) {
    printf("(E) open file: %s\n",file);
    return 1;
    }
  printf(":: fd: %d\n",fd);

  /* get current vt */
  int num;
  int tmp_num;
  struct vt_stat vtstat;
  if( ioctl(fd,VT_GETSTATE,&vtstat ) < 0 ) {
    fprintf(stderr, "console2: cannot get VTstate\n");
    exit(1);
    }
  num     = vtstat.v_active;    // current
  tmp_num = (num==1 ? 2 : 1);   // temporary


  fprintf(stderr, "vt_stat.v_active: %d\n",num);
  fprintf(stderr, "tmp_num: %d\n",tmp_num);
  fprintf(stderr, "console2: switching VTs\n");


  // switch forth  (this cuts scrollback buffer)
  if( ioctl(fd,VT_ACTIVATE,tmp_num) ) {
    perror("chvt: VT_ACTIVATE");
    exit(1);
    }

  if( ioctl(fd,VT_WAITACTIVE,tmp_num) ) {
    perror("VT_WAITACTIVE");
    exit(1);
    }

//  sleep(1);

  // switch back
  if( ioctl(fd,VT_ACTIVATE,num) ) {
    perror("chvt: VT_ACTIVATE");
    exit(1);
    }

  if( ioctl(fd,VT_WAITACTIVE,num) ) {
    perror("VT_WAITACTIVE");
    exit(1);
    }

  return 0;
  }

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

#204838

On Wed 30 Jan 2019 at 19:12:42 (+0000), Brian wrote:
> On Wed 30 Jan 2019 at 13:48:17 -0500, Felix Miata wrote:
> > hohe72@arcor.de composed on 2019-01-30 18:38 (UTC+0100):
> > 
> > > I logged in (to tty1)
> > > started X (startx)
> > > switched to tty2
> > > logged in (using the same name)
> > > logged out
> > 
> > > -> X on tty1 crashes
> > 
> > Same problem if you don't use tty1, instead logging in first on tty2, and after on tty3?
> 
> Did *you* try this? In fact, did *you* even try the procedure that
> hohe72 describes so well?

I've tried this every time I've seen it reported, and nothing ever
freezes, or crashes. Same just now.

But I do remember reading at one time that there's "something
different" about VC1 from the other consoles, and this change
was suggested as a possible workaround.

Whether it worked? No idea.
Whether the suggester (in the past) had had the same problem? No idea.
Does it have any effect? Not here, but then, I don't have the problem.
(Apart from the effect of a lot of 2s instead of 1s in the logs.
Oh, and a spent tty3 hanging around. I thought someone recently
posted that they got tidied up, but I've never seen that happen here.)

 1091     1     0 tty2     Ss     0:00 /bin/login --
 1193     1  1000 ?        Ss     0:00 /lib/systemd/systemd --user
 1195  1193  1000 ?        S      0:00 (sd-pam)
 1197  1091  1000 tty2     S+     0:00 -bash
 1284     1     0 ?        Ss     0:00 wpa_supplicant -B -i wlp2s0 -c /var/lib/wicd/configurations/b
 1354     1     0 ?        Ss     0:00 /sbin/dhclient -v -cf /var/lib/wicd/dhclient.conf wlp2s0
 1416  1197  1000 tty2     S      0:00 /bin/sh /usr/bin/X11/startx
 1438  1416  1000 tty2     S      0:00 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 v
 1439  1438  1000 tty2     Sl     0:01 /usr/lib/xorg/Xorg -nolisten tcp :0 vt2 -keeptty -auth /tmp/s
 1443  1439     0 tty2     S      0:00 /usr/lib/xserver-xorg-video-intel/xf86-video-intel-backlight-
 1446     1     0 ?        Ssl    0:00 /usr/lib/policykit-1/polkitd --no-debug
 1455  1438  1000 tty2     S      0:00 /bin/bash /home/david/.xsession
 1482     1  1000 tty2     S      0:00 /usr/bin/dbus-launch --exit-with-session --sh-syntax
 1483     1  1000 ?        Ss     0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 -
 1501  1455  1000 ?        Ss     0:00 /usr/bin/ssh-agent /bin/bash /home/david/.xsession

[…]

 2300     1     0 tty3     Ss+    0:00 /sbin/agetty --noclear tty3 linux

Disclaimers:
I run stretch. The OP's kernels look much newer.
I don't run a DE, just fvwm. Does the OP?
I know I've run two X sessions, but can't remember if I used the same
user. Is the OP running two sessions, or just one X and some VCs?
I don't claim to understand all the output posted here,
especially the last paragraph.

Cheers,
David.

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

#204840

On Wed 30 Jan 2019 at 13:54:14 -0600, David Wright wrote:

> On Wed 30 Jan 2019 at 19:12:42 (+0000), Brian wrote:
> > On Wed 30 Jan 2019 at 13:48:17 -0500, Felix Miata wrote:
> > > hohe72@arcor.de composed on 2019-01-30 18:38 (UTC+0100):
> > > 
> > > > I logged in (to tty1)
> > > > started X (startx)
> > > > switched to tty2
> > > > logged in (using the same name)
> > > > logged out
> > > 
> > > > -> X on tty1 crashes
> > > 
> > > Same problem if you don't use tty1, instead logging in first on tty2, and after on tty3?
> > 
> > Did *you* try this? In fact, did *you* even try the procedure that
> > hohe72 describes so well?
> 
> I've tried this every time I've seen it reported, and nothing ever
> freezes, or crashes. Same just now.

I've just tested again on unstable. The described procedure leads to
X on tty1 disappearing, A crash, if you like.
 
> But I do remember reading at one time that there's "something
> different" about VC1 from the other consoles, and this change
> was suggested as a possible workaround.
> 
> Whether it worked? No idea.
> Whether the suggester (in the past) had had the same problem? No idea.
> Does it have any effect? Not here, but then, I don't have the problem.
> (Apart from the effect of a lot of 2s instead of 1s in the logs.
> Oh, and a spent tty3 hanging around. I thought someone recently
> posted that they got tidied up, but I've never seen that happen here.)
> 
>  1091     1     0 tty2     Ss     0:00 /bin/login --
>  1193     1  1000 ?        Ss     0:00 /lib/systemd/systemd --user
>  1195  1193  1000 ?        S      0:00 (sd-pam)
>  1197  1091  1000 tty2     S+     0:00 -bash
>  1284     1     0 ?        Ss     0:00 wpa_supplicant -B -i wlp2s0 -c /var/lib/wicd/configurations/b
>  1354     1     0 ?        Ss     0:00 /sbin/dhclient -v -cf /var/lib/wicd/dhclient.conf wlp2s0
>  1416  1197  1000 tty2     S      0:00 /bin/sh /usr/bin/X11/startx
>  1438  1416  1000 tty2     S      0:00 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 v
>  1439  1438  1000 tty2     Sl     0:01 /usr/lib/xorg/Xorg -nolisten tcp :0 vt2 -keeptty -auth /tmp/s
>  1443  1439     0 tty2     S      0:00 /usr/lib/xserver-xorg-video-intel/xf86-video-intel-backlight-
>  1446     1     0 ?        Ssl    0:00 /usr/lib/policykit-1/polkitd --no-debug
>  1455  1438  1000 tty2     S      0:00 /bin/bash /home/david/.xsession
>  1482     1  1000 tty2     S      0:00 /usr/bin/dbus-launch --exit-with-session --sh-syntax
>  1483     1  1000 ?        Ss     0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 -
>  1501  1455  1000 ?        Ss     0:00 /usr/bin/ssh-agent /bin/bash /home/david/.xsession
> 
> […]
> 
>  2300     1     0 tty3     Ss+    0:00 /sbin/agetty --noclear tty3 linux
> 
> Disclaimers:
> I run stretch. The OP's kernels look much newer.

Maybe he is on unstable or testing. He should say.

> I don't run a DE, just fvwm. Does the OP?

My experience is with jvm, but I have seen it with fvwm.

-- 
Brian.

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

#204845

On Wed 30 Jan 2019 at 20:33:44 +0000, Brian wrote:

> On Wed 30 Jan 2019 at 13:54:14 -0600, David Wright wrote:
> 
> > On Wed 30 Jan 2019 at 19:12:42 (+0000), Brian wrote:
> > > On Wed 30 Jan 2019 at 13:48:17 -0500, Felix Miata wrote:
> > > > hohe72@arcor.de composed on 2019-01-30 18:38 (UTC+0100):
> > > > 
> > > > > I logged in (to tty1)
> > > > > started X (startx)
> > > > > switched to tty2
> > > > > logged in (using the same name)
> > > > > logged out
> > > > 
> > > > > -> X on tty1 crashes
> > > > 
> > > > Same problem if you don't use tty1, instead logging in first on tty2, and after on tty3?
> > > 
> > > Did *you* try this? In fact, did *you* even try the procedure that
> > > hohe72 describes so well?
> > 
> > I've tried this every time I've seen it reported, and nothing ever
> > freezes, or crashes. Same just now.
> 
> I've just tested again on unstable. The described procedure leads to
> X on tty1 disappearing, A crash, if you like.

1. Installed an utterly minimal stretch. Base system only.

2. Installed xorg and fvwm.

3. startx on tty2. Logged in on tty3. Logged out on tty3 and was
   returned to tty3. All other terminals available.

   This answers Felix Miata's query.

4. startx on tty1. Logged in on tty2. Logged out on tty2 and was
   returned to tty1. No other terminals available. ALT+CTL+F1 sees
   X exiting.

There you are. Four straightforward steps to triage this issue.

What hohe72 observed was buggy behaviour. Nothing more; nothing less.

-- 
Brian.

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

#204861

On Wed, 30 Jan 2019 20:33:44 +0000
Brian <ad44@cityscape.co.uk> wrote:

> On Wed 30 Jan 2019 at 13:54:14 -0600, David Wright wrote:
> 
> > On Wed 30 Jan 2019 at 19:12:42 (+0000), Brian wrote:  
> > > On Wed 30 Jan 2019 at 13:48:17 -0500, Felix Miata wrote:  
> > > > hohe72@arcor.de composed on 2019-01-30 18:38 (UTC+0100):
> > > >   
> > > > > I logged in (to tty1)
> > > > > started X (startx)
> > > > > switched to tty2
> > > > > logged in (using the same name)
> > > > > logged out  
> > > >   
> > > > > -> X on tty1 crashes  
> > > > 
> > > > Same problem if you don't use tty1, instead logging in first on
> > > > tty2, and after on tty3?  
> > > 
> > > Did *you* try this? In fact, did *you* even try the procedure that
> > > hohe72 describes so well?  
> > 
> > I've tried this every time I've seen it reported, and nothing ever
> > freezes, or crashes. Same just now.  
> 
> I've just tested again on unstable. The described procedure leads to
> X on tty1 disappearing, A crash, if you like.
>  
> > But I do remember reading at one time that there's "something
> > different" about VC1 from the other consoles, and this change
> > was suggested as a possible workaround.
> > 
> > Whether it worked? No idea.
> > Whether the suggester (in the past) had had the same problem? No
> > idea. Does it have any effect? Not here, but then, I don't have the
> > problem. (Apart from the effect of a lot of 2s instead of 1s in the
> > logs. Oh, and a spent tty3 hanging around. I thought someone
> > recently posted that they got tidied up, but I've never seen that
> > happen here.)
> > 
> >  1091     1     0 tty2     Ss     0:00 /bin/login --
> >  1193     1  1000 ?        Ss     0:00 /lib/systemd/systemd --user
> >  1195  1193  1000 ?        S      0:00 (sd-pam)
> >  1197  1091  1000 tty2     S+     0:00 -bash
> >  1284     1     0 ?        Ss     0:00 wpa_supplicant -B -i wlp2s0
> > -c /var/lib/wicd/configurations/b 1354     1     0 ?        Ss
> > 0:00 /sbin/dhclient -v -cf /var/lib/wicd/dhclient.conf wlp2s0 1416
> > 1197  1000 tty2     S      0:00 /bin/sh /usr/bin/X11/startx 1438
> > 1416  1000 tty2     S      0:00 xinit /etc/X11/xinit/xinitrc
> > -- /etc/X11/xinit/xserverrc :0 v 1439  1438  1000 tty2     Sl
> > 0:01 /usr/lib/xorg/Xorg -nolisten tcp :0 vt2 -keeptty -auth /tmp/s
> > 1443  1439     0 tty2     S
> > 0:00 /usr/lib/xserver-xorg-video-intel/xf86-video-intel-backlight-
> > 1446     1     0 ?        Ssl    0:00 /usr/lib/policykit-1/polkitd
> > --no-debug 1455  1438  1000 tty2     S
> > 0:00 /bin/bash /home/david/.xsession 1482     1  1000 tty2
> > S      0:00 /usr/bin/dbus-launch --exit-with-session --sh-syntax
> > 1483     1  1000 ?        Ss     0:00 /usr/bin/dbus-daemon --fork
> > --print-pid 5 --print-address 7 - 1501  1455  1000 ?        Ss
> > 0:00 /usr/bin/ssh-agent /bin/bash /home/david/.xsession
> > 
> > […]
> > 
> >  2300     1     0 tty3     Ss+    0:00 /sbin/agetty --noclear tty3
> > linux
> > 
> > Disclaimers:
> > I run stretch. The OP's kernels look much newer.  
> 
> Maybe he is on unstable or testing. He should say.

Backporting (but I have skipped that yet. I had problems with the last
three kernels: slab, blank screen on boot and this.)

> > I don't run a DE, just fvwm. Does the OP?  
> 
> My experience is with jvm, but I have seen it with fvwm.
> 

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

#204841 — Re: Let's play "Where is X?" (was: logout kills X)

David Wright composed on 2019-01-30 13:54 (UTC-0600):

> On Wed 30 Jan 2019 at 19:12:42 (+0000), Brian wrote:

>> On Wed 30 Jan 2019 at 13:48:17 -0500, Felix Miata wrote:

>>> Same problem if you don't use tty1, instead logging in first on tty2, and after on tty3?

>> Did *you* try this? In fact, did *you* even try the procedure that
>> hohe72 describes so well?

> I've tried this every time I've seen it reported, and nothing ever
> freezes, or crashes. Same just now.

> But I do remember reading at one time that there's "something
> different" about VC1 from the other consoles

Indeed. It's what I had in mind when I responded. I'll give one guess where it came from.....


Time's up. Yes, systemd. Who couldn't have guessed. It imposed a notion that I first noticed....
(wish to guess where?)


Yup, on Fedora, home of Leonard P, under the aegis of RedHat, and Gnome.

....that X somehow belongs on tty1 instead of tty7. So, there is something different about tty1 (if
one is not still using sysvinit). How different depends I'm sure on more than I have any clue
about, but surely must include whether and which dm is installed, or used, or which distro. Not all
distros or dms accepted the systemd notion that tty users are happy to have one less tty available
than they were used to having in previous decades, as well as having tty1 cleared of all boot
messages, and avoiding encountering a dastardly video mode switch known as "flicker" before a GUI
login greeter appeared. How ungrateful!

As one who had years earlier learned to prevent clearing of tty1 at the end of init, this change
was quite apparent. It's been years since I've purposely logged in on tty1, back around the time I
got to understand that the first X session goes to tty7, the second to tty8, the third to tty9,
etc. Seeing those boot messages again after having logged in somewhere occasionally reminds me I've
lost my way. I expect those messages to stay put until a reboot or shutdown process is initiated.

I still don't know how to recover a full six ttys now that startx keeps X on the tty run from,
while login prompts never appear on tty7 & up. I'll get by on less than 6. Some changes do not need
to be accommodated. Life's too short.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#204842 — Re: Let's play "Where is X?" (was: logout kills X)

On Wed 30 Jan 2019 at 17:06:31 -0500, Felix Miata wrote:

> David Wright composed on 2019-01-30 13:54 (UTC-0600):
> 
> > On Wed 30 Jan 2019 at 19:12:42 (+0000), Brian wrote:
> 
> >> On Wed 30 Jan 2019 at 13:48:17 -0500, Felix Miata wrote:
> 
> >>> Same problem if you don't use tty1, instead logging in first on tty2, and after on tty3?
> 
> >> Did *you* try this? In fact, did *you* even try the procedure that
> >> hohe72 describes so well?
> 
> > I've tried this every time I've seen it reported, and nothing ever
> > freezes, or crashes. Same just now.
> 
> > But I do remember reading at one time that there's "something
> > different" about VC1 from the other consoles
> 
> Indeed. It's what I had in mind when I responded. I'll give one guess where it came from.....
> 
> Time's up. Yes, systemd. Who couldn't have guessed. It imposed a notion that I first noticed....
> (wish to guess where?)

You really should contribute to #80625 and let the systemd maintainers
know where they have gone wrong with this issue. Get them to acknowledge
where reponsibility really lies. Technical arguments are always welcome
in -systemd.

> Yup, on Fedora, home of Leonard P, under the aegis of RedHat, and Gnome.

The OP posted in an entirely technical context. Please try to follow
suit.

-- 
Brian.

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

#204843 — Re: Let's play "Where is X?"

Brian composed on 2019-01-30 17:33 (UTC-0500):

> You really should contribute to #80625 and let the systemd maintainers
> know where they have gone wrong with this issue.

???
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=80625 not
https://bugzilla.kernel.org/show_bug.cgi?id=80625 not
https://bugs.freedesktop.org/show_bug.cgi?id=80625 not
???
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#204844 — Re: Let's play "Where is X?"

On Wed 30 Jan 2019 at 17:56:09 -0500, Felix Miata wrote:

> Brian composed on 2019-01-30 17:33 (UTC-0500):
> 
> > You really should contribute to #80625 and let the systemd maintainers
> > know where they have gone wrong with this issue.
> 
> ???
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=80625 not

I don't know how that got there. My ineptitude. I gave the bug number
earlier in this thread. All you had to to do was read back and use
some initiative.

#791342

-- 
Brian.

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

#204849 — Re: Let's play "Where is X?"

Brian Potkin composed on 2019-01-30 23:03 (UTC):

> On Wed 30 Jan 2019 at 17:56:09 -0500, Felix Miata wrote:

>> Brian composed on 2019-01-30 22:33 (UTC):

>> > You really should contribute to #80625 and let the systemd maintainers
>> > know where they have gone wrong with this issue.

>> ???
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=80625 not

> I don't know how that got there. My ineptitude.

Bad copy of 806256. No ppl is perfect. :-)

> I gave the bug number
> earlier in this thread. All you had to to do was read back and use
> some initiative.

> #791342

Maybe a habit of more complete referencing would avoid this. Apparently when I looked back earlier
I stopped one short of finding anything. Which did you actually mean, 791342 (yours earlier filed),
or 806256 (more activity).

Based on activity at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858073 and the mailing list threads therein
referred to it would seem a better location would need be found in order for systemd/logind
maintainers to take notice. Both reports are assigned to bash.

Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806256 also assigned to bash should
have been a useful place, where you actually meant? But, Michael Biebl referred 806256 back to your
791342. :-(

It looks like upstream may have fixed this on 30 October:
https://github.com/systemd/systemd/issues/2061
https://github.com/systemd/systemd/issues/2198
https://github.com/systemd/systemd/pull/2463

Maybe you could check Buster as you did earlier for Stretch. I don't know how to navigate github
well enough to know what transpired subsequent to 2463's October reference.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#204936 — Let's play "Where is X?" (was: logout kills X)

[Multipart message — attachments visible in raw view] — view raw

Felix Miata:

> Indeed. It's what I had in mind when I responded. I'll give one guess 
> where it came from..... Time's up. Yes, systemd. Who couldn't have 
> guessed. It imposed a notion that I first noticed.... (wish to guess 
> where?) Yup, on Fedora, home of Leonard P, under the aegis of RedHat, 
> and Gnome. ....that X somehow belongs on |tty1| instead of |tty7|.
>
This is quite wrong.  Neither systemd nor Lennart Poettering imposed 
such a notion.  The RedHat people had the idea of moving the X server to 
|tty1| in 2008.  It wasn't Lennart Poettering's idea, as can be seen by 
reading the list of people on the Fedora doco of the idea, and it 
pre-dates systemd's /very invention/ by two years.  It was motivated by 
reducing mode-change flicker during the boot process, by avoiding KVT 
switching, and at the time Fedora was using upstart.  Ironically, the 
idea /was imposed upon/ systemd and Lennart Poettering, which had to 
adjust to accommodate it.

  *

    https://news.ycombinator.com/item?id=12772915

  *

    https://news.ycombinator.com/item?id=16104343

The problem with the Bourne Again shell package's |clear_console| /is/ 
KVT switching, and /similarly eliminating KVT switching/ fixes it (as I 
explained back in 2015, when I published a replacement |clear_console| 
<http://jdebp.eu./Softwares/nosh/guide/commands/clear_console.xml> that 
did not do KVT switching).  There is nothing special about |tty1| here; 
and this is everything to do with a Bourne Again shell package tool that 
uses a bodge to clear KVTs, and nothing to do with systemd.

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

#204937 — Re: Let's play "Where is X?" (was: logout kills X)

Jonathan de Boyne Pollard composed on 2019-02-02 22:01 (UTC):

> Felix Miata:

>> Indeed. It's what I had in mind when I responded. I'll give one guess 
>> where it came from..... Time's up. Yes, systemd. Who couldn't have 
>> guessed. It imposed a notion that I first noticed.... (wish to guess 
>> where?) Yup, on Fedora, home of Leonard P, under the aegis of RedHat, 
>> and Gnome. ....that X somehow belongs on |tty1| instead of |tty7|.

> This is quite wrong.  Neither systemd nor Lennart Poettering imposed 
> such a notion.  The RedHat people had the idea of moving the X server to 
> |tty1| in 2008.  It wasn't Lennart Poettering's idea, as can be seen by 
> reading the list of people on the Fedora doco of the idea, and it 
> pre-dates systemd's /very invention/ by two years.  It was motivated by 
> reducing mode-change flicker during the boot process, by avoiding KVT 
> switching, and at the time Fedora was using upstart.  Ironically, the 
> idea /was imposed upon/ systemd and Lennart Poettering, which had to 
> adjust to accommodate it.

The devil is in the details. This was around 10 years ago and I was writing from fuzzy memory. Is
it really wrong in an overall sense when you do not omit from the quote all that I wrote, in
particular this part?:

"and avoiding encountering a dastardly video mode switch known as "flicker" before a GUI login
greeter appeared."

Fedora wanted to get rid of a /horrible/ /demon/ called flicker, as well as move the GUI to tty1,
and later in ancient history, Redhat instrumentality Leonnart's systemd incorporated
TTYVTDisallocate=yes as a partial means to accommodate it. No?

>   *

>     https://news.ycombinator.com/item?id=12772915

>   *

>     https://news.ycombinator.com/item?id=16104343

> The problem with the Bourne Again shell package's |clear_console| /is/ 
> KVT switching, and /similarly eliminating KVT switching/ fixes it (as I 
> explained back in 2015, when I published a replacement |clear_console| 
> <http://jdebp.eu./Softwares/nosh/guide/commands/clear_console.xml> that 
> did not do KVT switching).  There is nothing special about |tty1| here; 
> and this is everything to do with a Bourne Again shell package tool that 
> uses a bodge to clear KVTs, and nothing to do with systemd.

Indeed the original thread's complaint's cause was/is clear_console, but only on Debian and
whichever of its derivatives follow suit. AFAIK, none of the non-.deb distros I've used (e.g.
Fedora, {open}SUSE) have ever utilized it. It's never bothered me on Debian or anywhere else
because I like what shows up, when allowed, on tty1, leaving it remain uncleared, reminding me this
is not Windows, and logging in intentionally only on tty2 and up.

Thanks for the history refresh from "The world wants you to clean your screen" and mailing list
links. I had no idea there were so many gettys, and Greg W's
http://mywiki.wooledge.org/SystemdNoClear is now bookmarked so I can switch to accepted practice
for overriding stupid settings when the urge strikes.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#204945 — Re: Let's play "Where is X?" (was: logout kills X)

[Multipart message — attachments visible in raw view] — view raw

On Sat, Feb 02, 2019 at 06:34:33PM -0500, Felix Miata wrote:
> Jonathan de Boyne Pollard composed on 2019-02-02 22:01 (UTC):
> 
> > Felix Miata:
> 
> >> Indeed. It's what I had in mind when I responded. I'll give one guess 
> >> where it came from..... Time's up. Yes, systemd [...]

> > This is quite wrong.  Neither systemd nor Lennart Poettering imposed 
> > such a notion.  The RedHat people had the idea of moving the X server to 
> > |tty1| in 2008 [...]

> The devil is in the details. This was around 10 years ago and I was writing from fuzzy memory. Is
> it really wrong in an overall sense when you do not omit from the quote all that I wrote, in
> particular this part?:

No but it is kinda wrong in a more diffuse sense: depicting
Lennart Poettering as the Devil Incarnate with half-facts just
adds a lot of noise to a discussion which should be carried
with a cool head and lots of good will towards each other.

Personally I don't like systemd and have /my/ good reasons to
avoid it, but hey, Lennart is writing free software after all,
so I'm thankful for that.

/And/ when you're critizicing things, do make an effort to get
facts right. And try to be fair in your critique: there's often
a human being at the other end. Otherwise we end up being
Facebook or 4chan.

Now getting off my soapbox. Next, please :-)

Cheers
-- tomás

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

#204955 — Re: Let's play "Where is X?" (was: logout kills X)

[Multipart message — attachments visible in raw view] — view raw

On Sun, Feb 3, 2019, 04:04 <tomas@tuxteam.de wrote:

> On Sat, Feb 02, 2019 at 06:34:33PM -0500, Felix Miata wrote:
> > Jonathan de Boyne Pollard composed on 2019-02-02 22:01 (UTC):
> >
> > > Felix Miata:
> >
> > >> Indeed. It's what I had in mind when I responded. I'll give one guess
> > >> where it came from..... Time's up. Yes, systemd [...]
>
> > > This is quite wrong.  Neither systemd nor Lennart Poettering imposed
> > > such a notion.  The RedHat people had the idea of moving the X server
> to
> > > |tty1| in 2008 [...]
>
> > The devil is in the details. This was around 10 years ago and I was
> writing from fuzzy memory. Is
> > it really wrong in an overall sense when you do not omit from the quote
> all that I wrote, in
> > particular this part?:
>
> No but it is kinda wrong in a more diffuse sense: depicting
> Lennart Poettering as the Devil Incarnate with half-facts just
> adds a lot of noise to a discussion which should be carried
> with a cool head and lots of good will towards each other.
>
> Personally I don't like systemd and have /my/ good reasons to
> avoid it, but hey, Lennart is writing free software after all,
> so I'm thankful for that.
>
> /And/ when you're critizicing things, do make an effort to get
> facts right. And try to be fair in your critique: there's often
> a human being at the other end. Otherwise we end up being
> Facebook or 4chan.
>
> Now getting off my soapbox. Next, please :-)
>
> Cheers
> -- tomás
>


Depicting Lennart Poettering as the Devil Incarnate would definitely unfair
to the Devil Incarnate.

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

#204967 — Re: Let's play "Where is X?" (was: logout kills X)

https://www.facebook.com/381862631937250/posts/1867044320085733

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

#204979 — Re: Let's play "Where is X?" (was: logout kills X)

On Sat, Feb 02, 2019 at 10:01:17PM +0000, Jonathan de Boyne Pollard wrote:
> The problem with the Bourne Again shell package's |clear_console| /is/ KVT
> switching, and /similarly eliminating KVT switching/ fixes it (as I
> explained back in 2015, when I published a replacement |clear_console|
> <http://jdebp.eu./Softwares/nosh/guide/commands/clear_console.xml> that did
> not do KVT switching).  There is nothing special about |tty1| here; and this
> is everything to do with a Bourne Again shell package tool that uses a bodge
> to clear KVTs, and nothing to do with systemd.

For those who are only following along on debian-user and not digging
into the packages and bug reports and source code, I would simply like
to add that the clear_console program shipped in Debian's package of
bash is provided entirely by Debian.  It does not come from the GNU
project's bash at all.

The comment at the top of the clear_console.c source code says:

  Copyright (C) 2006-2017 Canonical Ltd.

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

#204865

systemd is very aware the state:
loginctl list-sessions
   SESSION        UID USER             SEAT             TTY             
         1       1000 addams           seat0            /dev/tty1       
        25       1000 addams           seat0            /dev/tty2       

2 sessions listed.


But it seems that drivers, used by X, will be canceled.
How can I check the udev state. I'm not that familiar with udev and the
way it is integrated into a debian system.



On Wed, 30 Jan 2019 18:38:26 +0100
hohe72@arcor.de wrote:

> I logged in (to tty1)
> started X (startx)
> switched to tty2
> logged in (using the same name)
> logged out
> 
> -> X on tty1 crashes  
> 
> 
> some info:
> 
> .local/share/xorg/Xorg.0.log:
> 
> [ 41948.035] (EE) modeset(0): failed to set mode: Permission denied
> [ 41948.035] (EE) 
> Fatal server error:
> [ 41948.035] (EE) EnterVT failed for screen 0
> [ 41948.035] (EE) 
> [ 41948.035] (EE) 
> Please consult the The X.Org Foundation support 
> 	 at http://wiki.x.org
>  for help. 
> [ 41948.035] (EE) Please also check the log file at
> "$HOME/.local/share/xorg/Xorg.0.log" for additional information.
> [ 41948.035] (EE)
> 
> what modeset(0) usually goes:
> 
> [ 41937.630] (II) modeset(0): EDID vendor "LEN", prod id 16401
> [ 41937.630] (II) modeset(0): Printing DDC gathered Modelines:
> [ 41937.630] (II) modeset(0): Modeline "1280x800"x0.0   68.94  1280
> 1296 1344 1408  800 801 804 816 -hsync -vsync (49.0 kHz eP)
> [ 41937.630] (II) modeset(0): Modeline "1280x800"x0.0   60.96  1280
> 1328 1360 1478  800 803 809 825 -hsync -vsync (41.2 kHz e)
> 
> uname -a
> Linux bivalve 4.19.0-0.bpo.1-amd64 #1 SMP Debian 4.19.12-1~bpo9+1
> (2018-12-30) x86_64 GNU/Linux
> 
> 
> terminal output:
> 
> X.Org X Server 1.19.2
> Release Date: 2017-03-02
> X Protocol Version 11, Revision 0
> Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
> Current Operating System: Linux bivalve 4.19.0-0.bpo.1-amd64 #1 SMP
>  Debian 4.19.12-1~bpo9+1 (2018-12-30) x86_64
> Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-0.bpo.1-amd64
>  root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ro
> Build Date: 03 November 2018  03:09:11AM
> xorg-server 2:1.19.2-1+deb9u5 (https://www.debian.org/support)
> Current version of pixman: 0.34.0
>  Before reporting problems, check http://wiki.x.org to make sure that
>  you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
> (++) from command line, (!!) notice, (II) informational, (WW)
> warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/home/addams/.local/share/xorg/Xorg.0.log", Time: Wed
> Jan 30 15:24:19 2019
> (==) Using config directory: "/etc/X11/xorg.conf.d"
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> xf86EnableIOPorts: failed to set IOPL for I/O (Operation not
> permitted) (II) AIGLX: Suspending AIGLX clients for VT switch
> [dix] couldn't enable device 7
> [dix] couldn't enable device 8
> [dix] couldn't enable device 9
> [dix] couldn't enable device 10
> [dix] couldn't enable device 12
> [dix] couldn't enable device 13
> [dix] couldn't enable device 14
> [dix] couldn't enable device 15
> [dix] couldn't enable device 17
> [dix] couldn't enable device 6
> [dix] couldn't enable device 11
> [dix] couldn't enable device 16
> (II) AIGLX: Suspending AIGLX clients for VT switch
> (EE) 
> Fatal server error:
> (EE) EnterVT failed for screen 0
> (EE) 
> (EE) 
> Please consult the The X.Org Foundation support 
> 	 at http://wiki.x.org
>  for help. 
> (EE) Please also check the log file at
> "/home/addams/.local/share/xorg/Xorg.0.log" for additional
> information. (EE) (II) AIGLX: Suspending AIGLX clients for VT switch
> (EE) Server terminated with error (1). Closing log file.
> xinit: connection to X server lost
> 
> waiting for X server to shut down 
> 
> 
> ----
> 
> loading an older kernel, X doesn't crash, instead all input devices
> have vanished from X.
> 
> uname -a:
>  Linux bivalve 4.17.0-0.bpo.3-amd64 #1 SMP Debian 4.17.17-1~bpo9+1
>  (2018-08-27) x86_64 GNU/Linux
> 
> Then I doesn't get control anymore.
> 
> ----
> I finally want to know how to separate the sessions.
> 
> /etc/systemd/logind.conf:
>  KillUserProcesses=no
> 
> allready done.
> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web