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

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

X crashes when closing one of two running X sessions

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

Contents

  X crashes when closing one of two running X sessions Robert Arkiletian <robark@gmail.com> - 2017-10-18 18:20 +0200
    Re: X crashes when closing one of two running X sessions Floris <jkfloris@dds.nl> - 2017-10-19 10:10 +0200
      Re: X crashes when closing one of two running X sessions Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-19 14:40 +0200
        Re: X crashes when closing one of two running X sessions Robert Arkiletian <robark@gmail.com> - 2017-10-22 18:20 +0200
          Re: X crashes when closing one of two running X sessions Robert Arkiletian <robark@gmail.com> - 2017-10-22 18:50 +0200
            Re: X crashes when closing one of two running X sessions Brian <ad44@cityscape.co.uk> - 2017-10-23 18:40 +0200
              Re: X crashes when closing one of two running X sessions Robert Arkiletian <robark@gmail.com> - 2017-10-23 19:30 +0200
                Re: X crashes when closing one of two running X sessions Robert Arkiletian <robark@gmail.com> - 2017-10-23 22:30 +0200
                  Re: X crashes when closing one of two running X sessions The Wanderer <wanderer@fastmail.fm> - 2017-10-24 00:00 +0200
                    Re: X crashes when closing one of two running X sessions Robert Arkiletian <robark@gmail.com> - 2017-10-24 07:50 +0200
                      Re: X crashes when closing one of two running X sessions The Wanderer <wanderer@fastmail.fm> - 2017-10-24 13:40 +0200
                        Re: X crashes when closing one of two running X sessions Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-24 14:20 +0200
                          Re: X crashes when closing one of two running X sessions The Wanderer <wanderer@fastmail.fm> - 2017-10-24 14:40 +0200
                            Re: X crashes when closing one of two running X sessions David Wright <deblis@lionunicorn.co.uk> - 2017-10-24 18:20 +0200
                              Re: X crashes when closing one of two running X sessions Marc Shapiro <marcnshap@gmail.com> - 2017-10-25 04:40 +0200
                                Re: X crashes when closing one of two running X sessions Robert Arkiletian <robark@gmail.com> - 2017-10-25 19:30 +0200
                        Re: X crashes when closing one of two running X sessions Brian <ad44@cityscape.co.uk> - 2017-10-26 00:40 +0200
                      Re: X crashes when closing one of two running X sessions Jimmy Johnson <field.engineer@gmail.com> - 2017-10-24 21:40 +0200
    Re: X crashes when closing one of two running X sessions Jimmy Johnson <field.engineer@gmail.com> - 2017-10-19 17:40 +0200
      Re: X crashes when closing one of two running X sessions David Wright <deblis@lionunicorn.co.uk> - 2017-10-19 22:10 +0200
        Re: X crashes when closing one of two running X sessions Jimmy Johnson <field.engineer@gmail.com> - 2017-10-20 00:00 +0200
          Re: X crashes when closing one of two running X sessions David Wright <deblis@lionunicorn.co.uk> - 2017-10-20 00:20 +0200

Page 1 of 2  [1] 2  Next page →

#188021 — X crashes when closing one of two running X sessions

Using Debian Stretch x86_64. I don't use a greeter like lightdm. I
just log in at the virtual terminal, then startx (xfce desktop). I
like to use multiple accounts (running X) at the same time on
different virtual terminals (eg. ctrl-alt-f1  ctrl-alt-f2)

All is fine until I exit (shutdown) one X session, then the other
running X session freezes and then after a little while crashes. Any
ideas on how to find or diagnose what's causing this issue are much
appreciated.

Thanks

[toc] | [next] | [standalone]

#188048

Op Wed, 18 Oct 2017 18:13:39 +0200 schreef Robert Arkiletian  
<robark@gmail.com>:

> Using Debian Stretch x86_64. I don't use a greeter like lightdm. I
> just log in at the virtual terminal, then startx (xfce desktop). I
> like to use multiple accounts (running X) at the same time on
> different virtual terminals (eg. ctrl-alt-f1  ctrl-alt-f2)
>
> All is fine until I exit (shutdown) one X session, then the other
> running X session freezes and then after a little while crashes. Any
> ideas on how to find or diagnose what's causing this issue are much
> appreciated.
>
> Thanks
>

Maybe you can find more information in the log messages.  
/var/log/Xorg.x.log gives information about the X server. Or try  
journalctl to read all log messages.

Floris

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

#188057

On Thu, Oct 19, 2017 at 10:06:05AM +0200, Floris wrote:
> Maybe you can find more information in the log messages. /var/log/Xorg.x.log
> gives information about the X server. Or try journalctl to read all log
> messages.

The X log can either be in /var/log/Xorg.*.log or in
~/.local/share/xorg/Xorg.*.log depending on how X is started, in which
version of Debian, on which hardware.

See <https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#x-no-longer-requires-root>

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

#188187

Ok got more detailed info on the crash. First some info

Debian Stretch 64 with Radeon Turks graphics card

Note: I'm running X without root priv. I just log into a virtual term
and run startx. The crash (of the first X session) specifically
happens (not when closing the second X session) but when I log out of
the second virtual term (ctrl-d) after closing the second X session.

Update: In fact I don't even need to start a second X session I just
need to switch to another virtual term, log in and then log out. X
crash occurs with both xfce and openbox. Here is my startx errors and
my Xorg.0.log file relevant output

startx errors:
...
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
(II) [KMS] Kernel modesetting enabled.
-------------------------------------------------------------this is
where the errors
begin----------------------------------------------------
(II) AIGLX: Suspending AIGLX clients for VT switch
(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/arky/.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


Xorg.0.log errors:

[   728.156] (II) systemd-logind: got resume for 13:76
[   728.172] (II) systemd-logind: got resume for 13:77
[   728.188] (II) systemd-logind: got resume for 13:67
[   728.204] (II) systemd-logind: got resume for 13:75
[   728.220] (II) systemd-logind: got resume for 13:66
[   728.220] (II) systemd-logind: got resume for 226:0
[   728.233] (II) AIGLX: Resuming AIGLX clients after VT switch
[   728.233] (EE) RADEON(0): failed to set mode: Permission denied
[   728.233] (EE)
Fatal server error:
[   728.234] (EE) EnterVT failed for screen 0
[   728.234] (EE)
[   728.234] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
 for help.
[   728.234] (EE) Please also check the log file at
"/home/arky/.local/share/xorg/Xorg.0.log" for additional information.
[   728.234] (EE)
[   728.234] (II) AIGLX: Suspending AIGLX clients for VT switch
[   728.255] (EE) Server terminated with error (1). Closing log file.

On Thu, Oct 19, 2017 at 5:32 AM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Thu, Oct 19, 2017 at 10:06:05AM +0200, Floris wrote:
>> Maybe you can find more information in the log messages. /var/log/Xorg.x.log
>> gives information about the X server. Or try journalctl to read all log
>> messages.
>
> The X log can either be in /var/log/Xorg.*.log or in
> ~/.local/share/xorg/Xorg.*.log depending on how X is started, in which
> version of Debian, on which hardware.
>
> See <https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#x-no-longer-requires-root>
>

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

#188188

More info. The crash does NOT occur if I log into and log out of the
root account on the second virtual terminal. Also here is journalctl
output

Oct 22 09:33:10 up udev-acl.ck[4719]: g_slice_set_config: assertion
'sys_page_size == 0' failed
Oct 22 09:33:10 up login[3250]: pam_unix(login:session): session
closed for user arky
Oct 22 09:33:10 up udev-acl.ck[4721]: g_slice_set_config: assertion
'sys_page_size == 0' failed
Oct 22 09:33:10 up udev-acl.ck[4723]: g_slice_set_config: assertion
'sys_page_size == 0' failed
Oct 22 09:33:10 up systemd[1]: getty@tty3.service: Service has no
hold-off time, scheduling restart.
Oct 22 09:33:10 up systemd[1]: Stopped Getty on tty3.
Oct 22 09:33:10 up systemd[1]: Started Getty on tty3.
Oct 22 09:33:10 up systemd-logind[594]: Removed session 30.
Oct 22 09:33:10 up systemd[4677]: Stopped target Default.
Oct 22 09:33:10 up systemd[4677]: Stopped target Basic System.
Oct 22 09:33:10 up systemd[4677]: Stopped target Timers.
Oct 22 09:33:10 up systemd[4677]: Stopped target Sockets.
Oct 22 09:33:10 up systemd[4677]: Closed GnuPG cryptographic agent
(ssh-agent emulation).
Oct 22 09:33:10 up systemd[4677]: Stopped target Paths.
Oct 22 09:33:10 up systemd[4677]: Closed GnuPG network certificate
management daemon.
Oct 22 09:33:10 up systemd[4677]: Closed GnuPG cryptographic agent and
passphrase cache.
Oct 22 09:33:10 up systemd[4677]: Closed GnuPG cryptographic agent and
passphrase cache (restricted).
Oct 22 09:33:10 up systemd[4677]: Closed D-Bus User Message Bus Socket.
Oct 22 09:33:10 up systemd[4677]: Closed GnuPG cryptographic agent
(access for web browsers).
Oct 22 09:33:10 up systemd[4677]: Reached target Shutdown.
Oct 22 09:33:10 up systemd[4677]: Starting Exit the Session...
Oct 22 09:33:10 up systemd[1]: Stopping User Manager for UID 1005...
Oct 22 09:33:10 up systemd[4677]: Received SIGRTMIN+24 from PID 4734 (kill).
Oct 22 09:33:10 up systemd[1]: user@1005.service: Killing process 4734
(kill) with signal SIGKILL.
Oct 22 09:33:10 up systemd[1]: Stopped User Manager for UID 1005.
Oct 22 09:33:10 up systemd[1]: Removed slice User Slice of arky.
Oct 22 09:33:10 up org.a11y.atspi.Registry[4630]: XIO:  fatal IO error
11 (Resource temporarily unavailable) on X server ":0"
Oct 22 09:33:10 up org.a11y.atspi.Registry[4630]:       after 61
requests (61 known processed) with 0 events remaining.
Oct 22 09:33:10 up console-kit-daemon[1011]: GLib-CRITICAL: Source ID
678 was not found when attempting to remove it
Oct 22 09:33:10 up console-kit-daemon[1011]: console-kit-daemon[1011]:
GLib-CRITICAL: Source ID 678 was not found when attempting to remove
it
Oct 22 09:33:13 up udev-acl.ck[4752]: g_slice_set_config: assertion
'sys_page_size == 0' failed

On Sun, Oct 22, 2017 at 9:11 AM, Robert Arkiletian <robark@gmail.com> wrote:
> Ok got more detailed info on the crash. First some info
>
> Debian Stretch 64 with Radeon Turks graphics card
>
> Note: I'm running X without root priv. I just log into a virtual term
> and run startx. The crash (of the first X session) specifically
> happens (not when closing the second X session) but when I log out of
> the second virtual term (ctrl-d) after closing the second X session.
>
> Update: In fact I don't even need to start a second X session I just
> need to switch to another virtual term, log in and then log out. X
> crash occurs with both xfce and openbox. Here is my startx errors and
> my Xorg.0.log file relevant output
>
> startx errors:
> ...
> xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
> (II) [KMS] Kernel modesetting enabled.
> -------------------------------------------------------------this is
> where the errors
> begin----------------------------------------------------
> (II) AIGLX: Suspending AIGLX clients for VT switch
> (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/arky/.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
>
>
> Xorg.0.log errors:
>
> [   728.156] (II) systemd-logind: got resume for 13:76
> [   728.172] (II) systemd-logind: got resume for 13:77
> [   728.188] (II) systemd-logind: got resume for 13:67
> [   728.204] (II) systemd-logind: got resume for 13:75
> [   728.220] (II) systemd-logind: got resume for 13:66
> [   728.220] (II) systemd-logind: got resume for 226:0
> [   728.233] (II) AIGLX: Resuming AIGLX clients after VT switch
> [   728.233] (EE) RADEON(0): failed to set mode: Permission denied
> [   728.233] (EE)
> Fatal server error:
> [   728.234] (EE) EnterVT failed for screen 0
> [   728.234] (EE)
> [   728.234] (EE)
> Please consult the The X.Org Foundation support
> at http://wiki.x.org
>  for help.
> [   728.234] (EE) Please also check the log file at
> "/home/arky/.local/share/xorg/Xorg.0.log" for additional information.
> [   728.234] (EE)
> [   728.234] (II) AIGLX: Suspending AIGLX clients for VT switch
> [   728.255] (EE) Server terminated with error (1). Closing log file.
>
> On Thu, Oct 19, 2017 at 5:32 AM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
>> On Thu, Oct 19, 2017 at 10:06:05AM +0200, Floris wrote:
>>> Maybe you can find more information in the log messages. /var/log/Xorg.x.log
>>> gives information about the X server. Or try journalctl to read all log
>>> messages.
>>
>> The X log can either be in /var/log/Xorg.*.log or in
>> ~/.local/share/xorg/Xorg.*.log depending on how X is started, in which
>> version of Debian, on which hardware.
>>
>> See <https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#x-no-longer-requires-root>
>>

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

#188212

On Sun 22 Oct 2017 at 09:45:08 -0700, Robert Arkiletian wrote:

> More info. The crash does NOT occur if I log into and log out of the
> root account on the second virtual terminal. Also here is journalctl
> output

#858073?

-- 
Brian.

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

#188214

On Mon, Oct 23, 2017 at 9:32 AM, Brian <ad44@cityscape.co.uk> wrote:
> On Sun 22 Oct 2017 at 09:45:08 -0700, Robert Arkiletian wrote:
>
>> More info. The crash does NOT occur if I log into and log out of the
>> root account on the second virtual terminal. Also here is journalctl
>> output
>
> #858073?
>

Ah! thanks Brian, I'm not the only person with this problem.

https://lists.debian.org/debian-devel/2017/03/msg00229.html

and I see you had a discussion with another person reporting the
problem here 2 years ago

https://lists.debian.org/debian-user/2015/07/msg00013.html

Not sure what to do next. Is this a systemd bug or an Xorg bug or a Debian bug?

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

#188218

Just tried this on a different box running Fedora 25 (64) and it works
perfectly, no problem. So I think this is a Debian bug. Although on
Fedora I'm not starting the first X session with startx, I can start
another X session on tty2 with startx and switch to tty3, log in and
log out without issue.

On Mon, Oct 23, 2017 at 10:24 AM, Robert Arkiletian <robark@gmail.com> wrote:
> On Mon, Oct 23, 2017 at 9:32 AM, Brian <ad44@cityscape.co.uk> wrote:
>> On Sun 22 Oct 2017 at 09:45:08 -0700, Robert Arkiletian wrote:
>>
>>> More info. The crash does NOT occur if I log into and log out of the
>>> root account on the second virtual terminal. Also here is journalctl
>>> output
>>
>> #858073?
>>
>
> Ah! thanks Brian, I'm not the only person with this problem.
>
> https://lists.debian.org/debian-devel/2017/03/msg00229.html
>
> and I see you had a discussion with another person reporting the
> problem here 2 years ago
>
> https://lists.debian.org/debian-user/2015/07/msg00013.html
>
> Not sure what to do next. Is this a systemd bug or an Xorg bug or a Debian bug?

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

#188222

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

On 2017-10-23 at 16:21, Robert Arkiletian wrote:

> Just tried this on a different box running Fedora 25 (64) and it
> works perfectly, no problem. So I think this is a Debian bug.
> Although on Fedora I'm not starting the first X session with startx,
> I can start another X session on tty2 with startx and switch to tty3,
> log in and log out without issue.

Per the description in bug 791342 (linked to from 858073 as being the
same issue), "[s]tarting the server on tty[2-6] does not generally
appear to lead to the behaviour described above". So I don't think this
is enough of a test to conclude that Fedora does not exhibit the same
behaviour.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#188232

On Mon, Oct 23, 2017 at 2:51 PM, The Wanderer <wanderer@fastmail.fm> wrote:
> On 2017-10-23 at 16:21, Robert Arkiletian wrote:
>
>> Just tried this on a different box running Fedora 25 (64) and it
>> works perfectly, no problem. So I think this is a Debian bug.
>> Although on Fedora I'm not starting the first X session with startx,
>> I can start another X session on tty2 with startx and switch to tty3,
>> log in and log out without issue.
>
> Per the description in bug 791342 (linked to from 858073 as being the
> same issue), "[s]tarting the server on tty[2-6] does not generally
> appear to lead to the behaviour described above". So I don't think this
> is enough of a test to conclude that Fedora does not exhibit the same
> behaviour.
>

My mistake. Confirmed the same behavior on the Debian Stretch box. If
I don't use tty1 everything is fine. I can use tty2 (running X) and
tty3 logging in and out switching back and forth, no issues. What an
odd bug. Well at least I have a workaround now. I will simply avoid
using tty1.

Update: Looked further into the thread with Brian and August from 2015
and it seems like the clear_console command (in .bash_logout) is at
fault. So I commented out clear_console in .bash_logout and everything
works great. No issues even on tty1. clear_console man page says

clear_console clears your console if this is possible.  It looks in the
       environment for the terminal type and then in the terminfo database  to
       figure  out  how  to  clear  the  screen.  To clear the buffer, it then
       changes the foreground virtual terminal to another  terminal  and  then
       back to the original terminal.

The log files I posted earlier in this thread indicate the crash was
due to "Permission denied". It makes sense that the bug did not
manifest itself while logging in and out of the root account as
permission was not a factor in "changes the foreground virtual
terminal to another  terminal  and  then back to the original
terminal". My guess is clear_console has tty1 hard coded in.  I notice
Matthias K. is the maintainer of the bash package (which has
clear_console) for Debian.  I wonder if he might consider poking
upstream devs of clear_console about this issue?

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

#188236

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

On 2017-10-24 at 01:40, Robert Arkiletian wrote:

> On Mon, Oct 23, 2017 at 2:51 PM, The Wanderer <wanderer@fastmail.fm> wrote:
>
>> On 2017-10-23 at 16:21, Robert Arkiletian wrote:
>>
>>> Just tried this on a different box running Fedora 25 (64) and it
>>> works perfectly, no problem. So I think this is a Debian bug.
>>> Although on Fedora I'm not starting the first X session with startx,
>>> I can start another X session on tty2 with startx and switch to tty3,
>>> log in and log out without issue.
>>
>> Per the description in bug 791342 (linked to from 858073 as being the
>> same issue), "[s]tarting the server on tty[2-6] does not generally
>> appear to lead to the behaviour described above". So I don't think this
>> is enough of a test to conclude that Fedora does not exhibit the same
>> behaviour.
> 
> My mistake. Confirmed the same behavior on the Debian Stretch box. If
> I don't use tty1 everything is fine. I can use tty2 (running X) and
> tty3 logging in and out switching back and forth, no issues. What an
> odd bug. Well at least I have a workaround now. I will simply avoid
> using tty1.
> 
> Update: Looked further into the thread with Brian and August from 2015
> and it seems like the clear_console command (in .bash_logout) is at
> fault. So I commented out clear_console in .bash_logout and everything
> works great. No issues even on tty1. clear_console man page says
> 
> clear_console clears your console if this is possible.  It looks in the
>        environment for the terminal type and then in the terminfo database  to
>        figure  out  how  to  clear  the  screen.  To clear the buffer, it then
>        changes the foreground virtual terminal to another  terminal  and  then
>        back to the original terminal.
> 
> The log files I posted earlier in this thread indicate the crash was
> due to "Permission denied". It makes sense that the bug did not
> manifest itself while logging in and out of the root account as
> permission was not a factor in "changes the foreground virtual
> terminal to another  terminal  and  then back to the original
> terminal". My guess is clear_console has tty1 hard coded in.  I notice
> Matthias K. is the maintainer of the bash package (which has
> clear_console) for Debian.  I wonder if he might consider poking
> upstream devs of clear_console about this issue?

That program is shipped as part of bash, so it looks as if this might
actually be considered a bash bug. I'd see about reporting it there, yes
- either in Debian or upstream.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#188237

On Tue, Oct 24, 2017 at 07:31:32AM -0400, The Wanderer wrote:
> > clear_console clears your console if this is possible.  It looks in the

> That program is shipped as part of bash, so it looks as if this might
> actually be considered a bash bug. I'd see about reporting it there, yes
> - either in Debian or upstream.

Definitely not upstream.

wooledg:/usr/src/bash$ tar xzf bash-4.3.30.tar.gz 
wooledg:/usr/src/bash$ cd bash-4.3.30
wooledg:/usr/src/bash/bash-4.3.30$ grep -ri clear_console .
wooledg:/usr/src/bash/bash-4.3.30$ 

I'd never even heard of it until now.  It's definitely a Debian add-on.

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

#188240

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

On 2017-10-24 at 08:15, Greg Wooledge wrote:

> On Tue, Oct 24, 2017 at 07:31:32AM -0400, The Wanderer wrote:
>
>>> clear_console clears your console if this is possible.  It looks in the
> 
>> That program is shipped as part of bash, so it looks as if this might
>> actually be considered a bash bug. I'd see about reporting it there, yes
>> - either in Debian or upstream.
> 
> Definitely not upstream.
> 
> wooledg:/usr/src/bash$ tar xzf bash-4.3.30.tar.gz 
> wooledg:/usr/src/bash$ cd bash-4.3.30
> wooledg:/usr/src/bash/bash-4.3.30$ grep -ri clear_console .
> wooledg:/usr/src/bash/bash-4.3.30$ 
> 
> I'd never even heard of it until now.  It's definitely a Debian add-on.

Thanks. I hadn't considered checking that way, but it's good to have
this confirmed.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#188243

On Tue 24 Oct 2017 at 08:29:50 (-0400), The Wanderer wrote:
> On 2017-10-24 at 08:15, Greg Wooledge wrote:
> 
> > On Tue, Oct 24, 2017 at 07:31:32AM -0400, The Wanderer wrote:
> >
> >>> clear_console clears your console if this is possible.  It looks in the
> > 
> >> That program is shipped as part of bash, so it looks as if this might
> >> actually be considered a bash bug. I'd see about reporting it there, yes
> >> - either in Debian or upstream.
> > 
> > Definitely not upstream.
> > 
> > wooledg:/usr/src/bash$ tar xzf bash-4.3.30.tar.gz 
> > wooledg:/usr/src/bash$ cd bash-4.3.30
> > wooledg:/usr/src/bash/bash-4.3.30$ grep -ri clear_console .
> > wooledg:/usr/src/bash/bash-4.3.30$ 
> > 
> > I'd never even heard of it until now.  It's definitely a Debian add-on.
> 
> Thanks. I hadn't considered checking that way, but it's good to have
> this confirmed.

I looked at my ~/.bash_logout and found I had recrafted it
long enough ago to forget doing it, just after starting to
use jessie.

It uses reset, and I often type reset myself, at times like
when the ssh pipe breaks during emacs -nw which throws you back
to a local bash prompt but with no visible cursor and a broken
command history recall.

Cheers,
David.

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

#188256

On 10/24/2017 09:14 AM, David Wright wrote:
> On Tue 24 Oct 2017 at 08:29:50 (-0400), The Wanderer wrote:
>> On 2017-10-24 at 08:15, Greg Wooledge wrote:
>>
>>> On Tue, Oct 24, 2017 at 07:31:32AM -0400, The Wanderer wrote:
>>>
>>>>> clear_console clears your console if this is possible.  It looks in the
>>>> That program is shipped as part of bash, so it looks as if this might
>>>> actually be considered a bash bug. I'd see about reporting it there, yes
>>>> - either in Debian or upstream.
>>> Definitely not upstream.
>>>
>>> wooledg:/usr/src/bash$ tar xzf bash-4.3.30.tar.gz
>>> wooledg:/usr/src/bash$ cd bash-4.3.30
>>> wooledg:/usr/src/bash/bash-4.3.30$ grep -ri clear_console .
>>> wooledg:/usr/src/bash/bash-4.3.30$
>>>
>>> I'd never even heard of it until now.  It's definitely a Debian add-on.
>> Thanks. I hadn't considered checking that way, but it's good to have
>> this confirmed.
> I looked at my ~/.bash_logout and found I had recrafted it
> long enough ago to forget doing it, just after starting to
> use jessie.
>
> It uses reset, and I often type reset myself, at times like
> when the ssh pipe breaks during emacs -nw which throws you back
> to a local bash prompt but with no visible cursor and a broken
> command history recall.
>
> Cheers,
> David.
>
That fixed it here.  I noticed this problem a few months ago, but never 
tracked down the source.  About the only time anyone actually logs out 
of a terminal session on this box is if I need to reboot (such as for a 
new kernel).  This is an annoyance due to causing an unclean shutdown, 
but nothing more.  My workaround had been to shut down the X session on 
vt01 first, then the other two.  But this is better.  I replaced 
clear_console with a call to reset and the problem went away.  I shut 
down my dfaughter's X session and logged her out.  My X session on vt01 
is still up and running.


Thanks for the tip, David.


Marc

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

#188307

On Tue, Oct 24, 2017 at 7:35 PM, Marc Shapiro <marcnshap@gmail.com> wrote:
> On 10/24/2017 09:14 AM, David Wright wrote:
>>
>> On Tue 24 Oct 2017 at 08:29:50 (-0400), The Wanderer wrote:
>>>
>>> On 2017-10-24 at 08:15, Greg Wooledge wrote:
>>>
>>>> On Tue, Oct 24, 2017 at 07:31:32AM -0400, The Wanderer wrote:
>>>>
>>>>>> clear_console clears your console if this is possible.  It looks in
>>>>>> the
>>>>>
>>>>> That program is shipped as part of bash, so it looks as if this might
>>>>> actually be considered a bash bug. I'd see about reporting it there,
>>>>> yes
>>>>> - either in Debian or upstream.
>>>>
>>>> Definitely not upstream.
>>>>
>>>> wooledg:/usr/src/bash$ tar xzf bash-4.3.30.tar.gz
>>>> wooledg:/usr/src/bash$ cd bash-4.3.30
>>>> wooledg:/usr/src/bash/bash-4.3.30$ grep -ri clear_console .
>>>> wooledg:/usr/src/bash/bash-4.3.30$
>>>>
>>>> I'd never even heard of it until now.  It's definitely a Debian add-on.
>>>
>>> Thanks. I hadn't considered checking that way, but it's good to have
>>> this confirmed.
>>
>> I looked at my ~/.bash_logout and found I had recrafted it
>> long enough ago to forget doing it, just after starting to
>> use jessie.
>>
>> It uses reset, and I often type reset myself, at times like
>> when the ssh pipe breaks during emacs -nw which throws you back
>> to a local bash prompt but with no visible cursor and a broken
>> command history recall.
>>
>> Cheers,
>> David.
>>
> That fixed it here.  I noticed this problem a few months ago, but never
> tracked down the source.  About the only time anyone actually logs out of a
> terminal session on this box is if I need to reboot (such as for a new
> kernel).  This is an annoyance due to causing an unclean shutdown, but
> nothing more.  My workaround had been to shut down the X session on vt01
> first, then the other two.  But this is better.  I replaced clear_console
> with a call to reset and the problem went away.  I shut down my dfaughter's
> X session and logged her out.  My X session on vt01 is still up and running.

Does Matthias K. (maintainer of bash for Debian) know about this
thread? I'm assuming he would be the one to fix it.

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

#188318

On Tue 24 Oct 2017 at 07:31:32 -0400, The Wanderer wrote:

> On 2017-10-24 at 01:40, Robert Arkiletian wrote:
> 
> > On Mon, Oct 23, 2017 at 2:51 PM, The Wanderer <wanderer@fastmail.fm> wrote:
> >
> >> On 2017-10-23 at 16:21, Robert Arkiletian wrote:
> >>
> >>> Just tried this on a different box running Fedora 25 (64) and it
> >>> works perfectly, no problem. So I think this is a Debian bug.
> >>> Although on Fedora I'm not starting the first X session with startx,
> >>> I can start another X session on tty2 with startx and switch to tty3,
> >>> log in and log out without issue.
> >>
> >> Per the description in bug 791342 (linked to from 858073 as being the
> >> same issue), "[s]tarting the server on tty[2-6] does not generally
> >> appear to lead to the behaviour described above". So I don't think this
> >> is enough of a test to conclude that Fedora does not exhibit the same
> >> behaviour.
> > 
> > My mistake. Confirmed the same behavior on the Debian Stretch box. If
> > I don't use tty1 everything is fine. I can use tty2 (running X) and
> > tty3 logging in and out switching back and forth, no issues. What an
> > odd bug. Well at least I have a workaround now. I will simply avoid
> > using tty1.
> > 
> > Update: Looked further into the thread with Brian and August from 2015
> > and it seems like the clear_console command (in .bash_logout) is at
> > fault. So I commented out clear_console in .bash_logout and everything
> > works great. No issues even on tty1. clear_console man page says
> > 
> > clear_console clears your console if this is possible.  It looks in the
> >        environment for the terminal type and then in the terminfo database  to
> >        figure  out  how  to  clear  the  screen.  To clear the buffer, it then
> >        changes the foreground virtual terminal to another  terminal  and  then
> >        back to the original terminal.
> > 
> > The log files I posted earlier in this thread indicate the crash was
> > due to "Permission denied". It makes sense that the bug did not
> > manifest itself while logging in and out of the root account as
> > permission was not a factor in "changes the foreground virtual
> > terminal to another  terminal  and  then back to the original
> > terminal". My guess is clear_console has tty1 hard coded in.  I notice
> > Matthias K. is the maintainer of the bash package (which has
> > clear_console) for Debian.  I wonder if he might consider poking
> > upstream devs of clear_console about this issue?
> 
> That program is shipped as part of bash, so it looks as if this might
> actually be considered a bash bug. I'd see about reporting it there, yes
> - either in Debian or upstream.

https://bugs.freedesktop.org/show_bug.cgi?id=93164

Which could be added to the existing Debian report.

-- 
Brian.

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

#188249

On 10/23/2017 10:40 PM, Robert Arkiletian wrote:
> On Mon, Oct 23, 2017 at 2:51 PM, The Wanderer <wanderer@fastmail.fm> wrote:
>> On 2017-10-23 at 16:21, Robert Arkiletian wrote:
>>
>>> Just tried this on a different box running Fedora 25 (64) and it
>>> works perfectly, no problem. So I think this is a Debian bug.
>>> Although on Fedora I'm not starting the first X session with startx,
>>> I can start another X session on tty2 with startx and switch to tty3,
>>> log in and log out without issue.
>>
>> Per the description in bug 791342 (linked to from 858073 as being the
>> same issue), "[s]tarting the server on tty[2-6] does not generally
>> appear to lead to the behaviour described above". So I don't think this
>> is enough of a test to conclude that Fedora does not exhibit the same
>> behaviour.
>>
> 
> My mistake. Confirmed the same behavior on the Debian Stretch box. If
> I don't use tty1 everything is fine. I can use tty2 (running X) and
> tty3 logging in and out switching back and forth, no issues. What an
> odd bug. Well at least I have a workaround now. I will simply avoid
> using tty1.


When I'm trying to work in ttys I avoid tty1 the system will output data 
there, seems to be logging stuff, firewall, etc., so I use tty2, etc. 
and then I'm not bothered by the system background noise.
-- 
Jimmy Johnson

Debian Jessie - KDE 4.14.2 - AMD A8-7600 - EXT4 at sda5
Registered Linux User #380263

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

#188060

On 10/18/2017 09:13 AM, Robert Arkiletian wrote:
> Using Debian Stretch x86_64. I don't use a greeter like lightdm. I
> just log in at the virtual terminal, then startx (xfce desktop). I
> like to use multiple accounts (running X) at the same time on
> different virtual terminals (eg. ctrl-alt-f1  ctrl-alt-f2)
> 
> All is fine until I exit (shutdown) one X session, then the other
> running X session freezes and then after a little while crashes. Any
> ideas on how to find or diagnose what's causing this issue are much
> appreciated.

I don't know about how you shutdown a terminal, me I just ctrl+d and it 
logs out.
-- 
Jimmy Johnson

Debian Buster - KDE Plasma 5.10.5 - AMD A8-7600 - EXT4 at sda7
Registered Linux User #380263

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

#188083

On Thu 19 Oct 2017 at 08:35:55 (-0700), Jimmy Johnson wrote:
> On 10/18/2017 09:13 AM, Robert Arkiletian wrote:
> >Using Debian Stretch x86_64. I don't use a greeter like lightdm. I
> >just log in at the virtual terminal, then startx (xfce desktop). I
> >like to use multiple accounts (running X) at the same time on
> >different virtual terminals (eg. ctrl-alt-f1  ctrl-alt-f2)
> >
> >All is fine until I exit (shutdown) one X session, then the other
> >running X session freezes and then after a little while crashes. Any
> >ideas on how to find or diagnose what's causing this issue are much
> >appreciated.
> 
> I don't know about how you shutdown a terminal, me I just ctrl+d and
> it logs out.

That sounds like you're talking about an xterm, not X.

Anyway, my suspicion is that perhaps there's a problem in restoring
the mode for the console that X started from, when it terminates. I've
had that problem in the past on this Acer laptop (on every
termination) though upgrades have often fixed it.

Currently, I have no problem if I haven't worked the system too hard
(which is tricky in 500MB memory), but after doing much browsing
(which tends to thrash the 1GB swap), terminating X will leave the
machine with a black screen. It's still running (I can ssh into it)
but about the only thing that works is the power button, whereupon
after a few seconds the normal VC screen appears with the closedown
messages scrolling by. (The only untested feature is whether the WiFi
kill switch (external) still works.)

I can avoid the black screen by, instead of using Ctrl-Alt-Backspace
to exit X, typing Ctrl-Alt-F2 for a VC and then killing X with
pkill xinit. VC2 now remains usable, just so long as I don't
accidently move to VC1, which puts it into its black screen state.

This Acer has a Radeon driver that is peculiar. When I boot, it's
important that I see these messages:
[   12.195543] radeon 0000:01:00.0: firmware: failed to load radeon/R300_cp.bin (-2)
[   12.195605] radeon 0000:01:00.0: Direct firmware load failed with error -2
[   12.195608] radeon 0000:01:00.0: Falling back to user helper
Were it to load that firmware (which I've hidden), it would crash
after just a few seconds.

Perhaps a workaround for you would be to only use "real" VCs when the
system is freshly booted, and then start a DM so that you stay inside
your X sessions evermore, until the next reboot; ie a one-way ticket.

Cheers,
David.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web