Comment 1 for bug 1659140

There doesn't seem to be an "edit" button, so I'll add details in comments as I discover them.

In the situation described, the same thing happens if I use the command "logout" instead of "exit".

In the error messages put forth by X (I presume) in tty2 while it was crashing in tty1 because I had just done "logout" in tty2, there was an oddity - it stated the time and date and the date was one day behind but the time was correct. I'm in the +5 zone but I suffer a government of idiots and who insist I "save" daylight by setting my clock wrong. It was nominally 2 pm here, but any way you look at it the date was the same at Greenwich unless I'm sadly confused. Under X the date was and is correct. I've now restarted X in tty1 (where it was to begin with - that's where Xenial puts X, not in tty7 as in days of yore) an logged in again in tty2. I did su (I'm a naughty boy - I enabled su) in tty2 got a root prompt, and then entered the command "exit". It went back to a user prompt and did NOT crash X in tty1. So whether "exit" makes X crash depends on the circumstances. I haven't studied "exit" but apparently if I've logged in as user and do "su", exit merely logs out root on the tty. But if I do "exit" on a tty when I'm logged in as user it seems it does something more and that something more is something X doesn't like. It didn't work that way in Trusty.

Now I'm wondering if this is properly an X bug, as opposed to a bug in whatever "logout" and "exit" call in common. Or maybe in bash itself. I'd appreciate an opinion as to whether I should report this against a different package.

Later, I'll tinker more, and post the log when I find it.

For now, for anyone else annoyed by this, my insecure work-around is simply not to log out of ttys but leave them logged in. This is a security problem if you are in an environment where you lock your kb/mouse/screen with something like xscreensaver or xtrlock in that a logged in tty provides an opportunity for an evil person to shut off your screen locker or just do damage from the command line. Not much of an issue for me at the moment. If this problem leads others to this obvious work-around though, I could argue that it is a security issue. So should this bug be flagged as such?