logout kills X

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

logout kills X

Holger Herrlich


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.

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

deloptes-2
[hidden email] 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).

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

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

> [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Felix Miata-3
In reply to this post by Holger Herrlich
[hidden email] 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/

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

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

> [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

David Wright-3
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:
> > [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Felix Miata-3
In reply to this post by Brian
Brian composed on 2019-01-30 19:12 (UTC):

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

>> [hidden email] 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/

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Brian
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:
>
> >> [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Brian
In reply to this post by David Wright-3
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:
> > > [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

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

Felix Miata-3
In reply to this post by David Wright-3
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/

Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Let's play "Where is X?"

Felix Miata-3
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/

Reply | Threaded
Open this post in threaded view
|

Re: Let's play "Where is X?"

Brian Potkin-4
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.

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Brian
In reply to this post by Brian
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:
> > > > [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: Let's play "Where is X?"

Felix Miata-3
In reply to this post by Brian Potkin-4
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/

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Holger Herrlich
In reply to this post by deloptes-2



On Wed, 30 Jan 2019 19:23:43 +0100
deloptes <[hidden email]> wrote:

> [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Holger Herrlich
In reply to this post by Brian



On Wed, 30 Jan 2019 20:33:44 +0000
Brian <[hidden email]> 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:  
> > > > [hidden email] 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Holger Herrlich
In reply to this post by Felix Miata-3



On Wed, 30 Jan 2019 14:57:59 -0500
Felix Miata <[hidden email]> wrote:

> Brian composed on 2019-01-30 19:12 (UTC):
>
> > On Wed 30 Jan 2019 at 13:48:17 -0500, Felix Miata wrote:  
>
> >> [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Holger Herrlich
In reply to this post by Brian



On Wed, 30 Jan 2019 20:25:59 +0000
Brian <[hidden email]> 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:  
> >  
> > >> [hidden email] 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: logout kills X

Holger Herrlich
In reply to this post by Holger Herrlich

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
[hidden email] 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.
>

12