[SOLVED] manually started X in tty1 crashes on logout from console session in tty2

Hi all -

I run debian stretch without automatically starting X. Startup leaves me at tty1. If I need to, I use startx to run fluxbox manually, usually from tty1. I can switch ttys without problems.

However, if I have X running in tty1 and a console session in tty2, logging out of the console session in tty2, to change user for instance, causes the X session in tty1 to eventually crash with errors about missing devices. What happens is this: I execute logout in tty2 and, instead of seeing a new login prompt in tty2, as I would have expected, the X session from tty1 appears on the screen. If I now press ctl alt F2, nothing happens, the X session from tty1 stays on the screen. If I press ctl alt F3, same thing. But if I press ctl alt F1, the X session crashes and I am back at a console session in tty1. At this point I can switch between ttys again.

Someone suggested I should try a different window manager, so I installed lxde. This modified my systemd services such that X now starts automatically in tty7. If I now go to tty1 and start another X session with lxde and then go to tty2 and login and logout from a console session, the X session in tty1 crashes as before, but the X session in tty7 stays unaffected.

Generally I don't want to start X automatically, mainly because I want to experiment with different window managers under X and with Wayland, and I don't want those things running simultaneously (at least in the beginning) in different ttys.

Is there something I can do to prevent my manually started X sessions from crashing when I logout from console sessions in other ttys?

Any suggestions, pointers to documentation, etc, greatly appreciated.

Your experience is or was common. It is (or, was in older releases?) a bug, because tty1 is special. Use any of 2-6 instead to start X instead of 1. I never start X on tty1 except by mistake.

Thanks @mrmazda - you were indeed correct. Upon further testing, I got these errors whenever tty1 was involved, either as the console session, or as the X session. All other tty pairings worked fine, which was good enough for me. Anyway, I upgraded to Debian 10 a few days ago, and I have not seen errors of the same type yet.