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 1 of 2  [1] 2  Next page →

#204827 — logout kills X

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] | [next] | [standalone]

#204828

hohe72@arcor.de wrote:

> I finally want to know how to separate the sessions.

why don't you use a window manager. Most of them offer the option to log in
as different user, which will open a new session on the next console.
I have not heard of same user logged in in two different X sessions on same
PC - they most likely step on each others feet.

Very interesting, what exactly you want to achieve (goal).

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

#204829

On Wed 30 Jan 2019 at 19:23:43 +0100, deloptes wrote:

> hohe72@arcor.de wrote:
> 
> > I finally want to know how to separate the sessions.
> 
> why don't you use a window manager. Most of them offer the option to log in
> as different user, which will open a new session on the next console.
> I have not heard of same user logged in in two different X sessions on same
> PC - they most likely step on each others feet.
> 
> Very interesting, what exactly you want to achieve (goal).

This sounds very much like #791342.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342

Whether bash is the culprit is debatable, but it has lingered there
without being reassigned. See #806256 also.

-- 
Brian. 

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

#204859

On Wed, 30 Jan 2019 19:23:43 +0100
deloptes <deloptes@gmail.com> wrote:

> hohe72@arcor.de wrote:
> 
> > I finally want to know how to separate the sessions.  
> 
> why don't you use a window manager. Most of them offer the option to
> log in as different user, which will open a new session on the next
> console.

My window manager hasn't session features integrated. I have no use for
it anyway.

> I have not heard of same user logged in in two different X
> sessions on same PC - they most likely step on each others feet.
> 
> Very interesting, what exactly you want to achieve (goal).

I try to get ride of xmodmap independently of the running session.

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

#204831

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?
-- 
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]

#204835

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?

--
Brian.

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

#204837

Brian composed on 2019-01-30 19:12 (UTC):

> 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?

Not so well. He left out the part about what he's actually using, what else he has installed from
backports, or what gfx, so I don't know that I could match his configuration. I don't have any
Stretch installations using backport kernels, so no, even though I was initially inclined to, I
didn't try, which is why I asked instead of saying WFM or confirming.
-- 
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]

#204839

On Wed 30 Jan 2019 at 14:57:59 -0500, Felix Miata wrote:

> Brian composed on 2019-01-30 19:12 (UTC):
> 
> > 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?
> 
> Not so well. He left out the part about what he's actually using, what else he has installed from
> backports, or what gfx, so I don't know that I could match his configuration. I don't have any
> Stretch installations using backport kernels, so no, even though I was initially inclined to, I
> didn't try, which is why I asked instead of saying WFM or confirming.

Fair enough; you have a reasonable number of points to be answered. We
should await hohe72's response.

And, yes; you did query. My bad not to take that into account.

-- 
Brian.

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

#204862

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

> On Wed 30 Jan 2019 at 14:57:59 -0500, Felix Miata wrote:
> 
> > Brian composed on 2019-01-30 19:12 (UTC):
> >   
> > > 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?  
> > 
> > Not so well. He left out the part about what he's actually using,
> > what else he has installed from backports, or what gfx, so I don't
> > know that I could match his configuration. I don't have any Stretch
> > installations using backport kernels, so no, even though I was
> > initially inclined to, I didn't try, which is why I asked instead
> > of saying WFM or confirming.  
> 
> Fair enough; you have a reasonable number of points to be answered. We
> should await hohe72's response.

I'm not on a steady line.

> And, yes; you did query. My bad not to take that into account.
> 

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

#204863

On Wed, 30 Jan 2019 14:57:59 -0500
Felix Miata <mrmazda@earthlink.net> wrote:

> Brian composed on 2019-01-30 19:12 (UTC):
> 
> > 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?  
> 
> Not so well. He left out the part about what he's actually using,

aewm (I may switch to jwm. However no need yet.) 

> what else he has installed from backports,

aptitude search '~i\.bpo\.'
i   linux-headers-4.12.0-0.bpo.2-amd64                               -
Header files for Linux 4.12.0-0.bpo.2-amd64 i A
linux-headers-4.12.0-0.bpo.2-common                              -
Common header files for Linux 4.12.0-0.bpo.2 i
linux-headers-4.13.0-0.bpo.1-amd64                               -
Header files for Linux 4.13.0-0.bpo.1-amd64 i A
linux-headers-4.13.0-0.bpo.1-common                              -
Common header files for Linux 4.13.0-0.bpo.1 i
linux-headers-4.14.0-0.bpo.3-amd64                               -
Header files for Linux 4.14.0-0.bpo.3-amd64 i A
linux-headers-4.14.0-0.bpo.3-common                              -
Common header files for Linux 4.14.0-0.bpo.3 i
linux-headers-4.15.0-0.bpo.2-amd64                               -
Header files for Linux 4.15.0-0.bpo.2-amd64 i A
linux-headers-4.15.0-0.bpo.2-common                              -
Common header files for Linux 4.15.0-0.bpo.2 i
linux-headers-4.16.0-0.bpo.1-amd64                               -
Header files for Linux 4.16.0-0.bpo.1-amd64 i A
linux-headers-4.16.0-0.bpo.1-common                              -
Common header files for Linux 4.16.0-0.bpo.1 i
linux-headers-4.16.0-0.bpo.2-amd64                               -
Header files for Linux 4.16.0-0.bpo.2-amd64 i A
linux-headers-4.16.0-0.bpo.2-common                              -
Common header files for Linux 4.16.0-0.bpo.2 i
linux-headers-4.17.0-0.bpo.1-amd64                               -
Header files for Linux 4.17.0-0.bpo.1-amd64 i A
linux-headers-4.17.0-0.bpo.1-common                              -
Common header files for Linux 4.17.0-0.bpo.1 i
linux-headers-4.17.0-0.bpo.3-amd64                               -
Header files for Linux 4.17.0-0.bpo.3-amd64 i A
linux-headers-4.17.0-0.bpo.3-common                              -
Common header files for Linux 4.17.0-0.bpo.3 i A
linux-image-4.12.0-0.bpo.2-amd64                                 -
Linux 4.12 for 64-bit PCs i A
linux-image-4.13.0-0.bpo.1-amd64                                 -
Linux 4.13 for 64-bit PCs i A
linux-image-4.14.0-0.bpo.2-amd64                                 -
Linux 4.14 for 64-bit PCs i A
linux-image-4.14.0-0.bpo.3-amd64                                 -
Linux 4.14 for 64-bit PCs i A
linux-image-4.15.0-0.bpo.2-amd64                                 -
Linux 4.15 for 64-bit PCs i A
linux-image-4.16.0-0.bpo.1-amd64                                 -
Linux 4.16 for 64-bit PCs i A
linux-image-4.16.0-0.bpo.2-amd64                                 -
Linux 4.16 for 64-bit PCs i A
linux-image-4.17.0-0.bpo.1-amd64                                 -
Linux 4.17 for 64-bit PCs i A
linux-image-4.17.0-0.bpo.3-amd64                                 -
Linux 4.17 for 64-bit PCs i A
linux-image-4.18.0-0.bpo.1-amd64                                 -
Linux 4.18 for 64-bit PCs i A
linux-image-4.18.0-0.bpo.3-amd64                                 -
Linux 4.18 for 64-bit PCs i A
linux-image-4.19.0-0.bpo.1-amd64-unsigned                        -
Linux 4.19 for 64-bit PCs 

> or what gfx,

??

> so I don't know that I could match his configuration. I don't have
> any Stretch

I'm using debian 9.<current>--always having problems with toy story
names.

> installations using backport kernels, so no, even though
> I was initially inclined to, I didn't try, which is why I asked
> instead of saying WFM or confirming.

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

#204867

Holger Herrlich composed on 2019-01-31 15:22 (UTC+0100):

> On Wed, 30 Jan 2019 14:57:59 -0500 Felix Miata wrote:

>> or what gfx,

> ??

Common shorthand for *graphics* hardware. AMD/ATI? Intel? NVidia? Matrox? Other?

Model? e.g.
# inxi -GxxSM
System:    Host: big31 Kernel: 4.9.0-8-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0 Desktop: Trinity R14.0.6
           tk: Qt 3.5.0 wm: Twin dm: startx Distro: Debian GNU/Linux 9 (stretch)
Machine:   Type: Desktop Mobo: BIOSTAR model: G31-M7 TE serial: N/A BIOS: American Megatrends v: 080014 date: 02/01/2010
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] vendor: Dell
           driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:6611
           Display: server: X.Org 1.19.2 driver: modesetting alternate: ati,fbdev,vesa resolution: 1920x1200~60Hz
           OpenGL: renderer: Gallium 0.4 on AMD OLAND (DRM 2.49.0 / 4.9.0-8-amd64 LLVM 3.9.1) v: 4.3 Mesa 13.0.6
           compat-v: 3.0 direct render: Yes

The keys in there are the PCI ID, the server driver in use, and the available alternative
server drivers, but much else is useful for troubleshooting.

Holger Herrlich composed on 2019-01-31 15:45 (UTC+0100):

> 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.

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.
-- 
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]

#204868

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 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

-- 
Brian

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

#204870

On Thu 31 Jan 2019 at 18:36:58 (+0000), Brian 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 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

I forgot to check what was actually in my own ~/.bash_logout until
you wrote this. For several years (since installing jessie, I think),
mine runs   clear && reset   rather than   clear_console.
Does that make any difference?

Cheers,
David.

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

#204872

On Thu 31 Jan 2019 at 12:51:05 -0600, David Wright wrote:

> On Thu 31 Jan 2019 at 18:36:58 (+0000), Brian 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 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
> 
> I forgot to check what was actually in my own ~/.bash_logout until
> you wrote this. For several years (since installing jessie, I think),
> mine runs   clear && reset   rather than   clear_console.
> Does that make any difference?

Thank you for looking at this. I tried 'clear && reset' on unstable and
have no complaints. Back to tty2 on after logging in and out and mouse
and keyboard normal operation on X in tty1.

So - is bash the culprit, or are the interactions between it and other
system components more complex than this indicates?

-- 
Brian.

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

#204873

> > mine runs   clear && reset   rather than   clear_console.
> > Does that make any difference?
> 
> Thank you for looking at this. I tried 'clear && reset' on unstable and
> have no complaints. Back to tty2 on after logging in and out and mouse
> and keyboard normal operation on X in tty1.
> 
> So - is bash the culprit, or are the interactions between it and other
> system components more complex than this indicates?

The man page for clear_console(1) is a little unclear to me, and a little
bit disturbing.  I cannot figure out what "changes the foreground virtual
terminal to another terminal" is supposed to mean, but between that and
the reference to chvt(1) under SEE ALSO, it seems like someone might want
to investigate that more closely.

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

#204880

On Thu 31 Jan 2019 at 15:01:49 (-0500), Greg Wooledge wrote:
> > > mine runs   clear && reset   rather than   clear_console.
> > > Does that make any difference?
> > 
> > Thank you for looking at this. I tried 'clear && reset' on unstable and
> > have no complaints. Back to tty2 on after logging in and out and mouse
> > and keyboard normal operation on X in tty1.
> > 
> > So - is bash the culprit, or are the interactions between it and other
> > system components more complex than this indicates?
> 
> The man page for clear_console(1) is a little unclear to me, and a little
> bit disturbing.  I cannot figure out what "changes the foreground virtual
> terminal to another terminal" is supposed to mean, but between that and
> the reference to chvt(1) under SEE ALSO, it seems like someone might want
> to investigate that more closely.

Oops, I think we're celebrating Groundhog Day a day early.

https://lists.debian.org/debian-user/2017/10/msg00603.html

Cheers,
David.

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

#204933

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

Greg Wooledge:

> The man page for |clear_console|(1) is a little unclear to me, and a 
> little bit disturbing. I cannot figure out what "changes the 
> foreground virtual terminal to another terminal" is supposed to mean, 
> but between that and the reference to |chvt|(1) under SEE ALSO, it 
> seems like someone might want to investigate that more closely.
>
I already did, years ago.  It is why I years ago wrote and published a 
replacement |clear_console 
<https://jdebp.eu/Softwares/nosh/guide/commands/clear_console.xml>| that 
just uses the control sequences to clear the scrollback buffer, gaining 
the benefit of working remotely, with GUI terminal emulators, and with 
PuTTY along the way.  It has been in the nosh toolset since version 1.19 
in 2015.  The original |clear_console| from the Bourne Again shell 
package is, in contrast, using the side-effects of switching between 
KVTs as a way of clearing the scrollback buffer.  It switches them back 
and forth very rapidly.

I explained this in this very mailing list three years ago 
<https://lists.debian.org/debian-user/2015/08/msg00958.html>. I also 
explained it in the 1.19 announcement 
<https://lists.debian.org/debian-user/2015/08/msg00951.html>, also on 
this very mailing list, pointing to a whole bunch of Debian bugs. I also 
explained it on Unix and Linux StackExchange 
<https://unix.stackexchange.com/a/451150/5132>.  It's even explained in 
the manual.  (-:

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

#204887

On 2019-01-31, Brian <ad44@cityscape.co.uk> wrote:
>
> Thank you for looking at this. I tried 'clear && reset' on unstable and
> have no complaints. Back to tty2 on after logging in and out and mouse
> and keyboard normal operation on X in tty1.
>
> So - is bash the culprit, or are the interactions between it and other
> system components more complex than this indicates?
>

There is this buggerino:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834270

Simon says:
 according to [1], any the following fixes the bug:
* removing the call to /usr/bin/clear_console from ~/.bash_logout 
(console is cleared anyway nowadays)
* replacing the call to /usr/bin/clear_console with /usr/bin/reset in 
~/.bash_logout

The discussion in [1] shows more information, the bug [2] at xorg is 
related or a duplicate

[1] https://groups.google.com/forum/#!topic/linux.debian.user/2G71U8P8c3Q
[2] https://gitlab.freedesktop.org/xorg/xserver/issues/492

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

#204914

On Fri 01 Feb 2019 at 10:54:32 -0000, Curt wrote:

> On 2019-01-31, Brian <ad44@cityscape.co.uk> wrote:
> >
> > Thank you for looking at this. I tried 'clear && reset' on unstable and
> > have no complaints. Back to tty2 on after logging in and out and mouse
> > and keyboard normal operation on X in tty1.
> >
> > So - is bash the culprit, or are the interactions between it and other
> > system components more complex than this indicates?
> >
> 
> There is this buggerino:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834270
> 
> Simon says:
>  according to [1], any the following fixes the bug:
> * removing the call to /usr/bin/clear_console from ~/.bash_logout 
> (console is cleared anyway nowadays)
> * replacing the call to /usr/bin/clear_console with /usr/bin/reset in 
> ~/.bash_logout
> 
> The discussion in [1] shows more information, the bug [2] at xorg is 
> related or a duplicate
> 
> [1] https://groups.google.com/forum/#!topic/linux.debian.user/2G71U8P8c3Q
> [2] https://gitlab.freedesktop.org/xorg/xserver/issues/492

Bugs filed against X, bash and systemd. Only the much maligned systemd

https://lists.debian.org/debian-user/2019/01/msg01087.html

has had an analysis and discussion in -systemd. Silence from the X
and (in particular) the bash maintaners for 3+ years. It's hardly the
bug of the century, but, for something with an easy solution, the
silence is deafening.

-- 
Brian.

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

#204918

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

On Fri, Feb 01, 2019 at 10:33:14PM +0000, Brian wrote:

> Bugs filed against X, bash and systemd. Only the much maligned systemd
> [...] has had an analysis and discussion in -systemd. Silence from the X
> and [...] the bash maintaners for 3+ years [...]

I don't know if you are aware of it, but it is an interesting point you
make there: what's the difference between {X, bash} and systemd?

Right, the former are "mature" projects. That means that they are somehow
in maintenance mode: they are most of the time seriously understaffed
(and /if/ there are exciting things happening they are at the "borders",
as in X). This works well for a while -- whenever nothing exciting
happens (mature software, after all). But the world around the software
changes...

Remember OpenSSL and Heartbleed? I claim the underlying pattern is the
same [1].

That can only mean two things: either there's a way to bring "fresh
blood" into mature projects on a regular basis (although it /may/
seem they don't "need" it). Or we have to see projects dying of age
and rotting (with some collateral damage as some infrastructure
is still based on this rotting substrate).

Cheers

[1] Some people saw the light and founded the Core Infrastructure
   Project <https://www.coreinfrastructure.org/>. Seeing through
   the illustrious (and very wealthy) list of sponsors I'm still
   a (fair) bit sceptical -- most of them seem to follow the
   neo-capitalist pattern of squeezing "costs" in all corners which
   don't seem to matter /right now/ (hello, Fukushima?).

-- tomás

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web