[11:44:32]  <mezcalero> some X hacker around who could comment on
   https://bugzilla.redhat.com/show_bug.cgi?id=619889  ?
   [11:44:34]  <bebot> Bug 619889: urgent, low, ---, lpoetter, NEW, X.org
   pegged at 100% CPU usage after booting with systemd
   [11:45:27]  <mezcalero> notting: ah, you commented already there
   [11:45:41]  <mezcalero> notting: hmm, what's that logic in upstart
   exactly?
   [11:46:11]  <notting^ we don't start a getty on tty1 in runlevel 5
   [11:46:22]  <mezcalero> notting: ah, interesting
   [11:47:31]  <halfline> mezcalero: note we force X on vt1
   [11:47:47]  <halfline> mezcalero: so starting getty on vt1 is a bad
   idea...
   [11:48:36]  <mezcalero> notting: hmm, but it still sounds racy that if you
   run both they deadlock in various ways
   [11:48:56]  <mezcalero> notting: what i'd expect to happen is that one
   wins and the other fails
   [11:50:03]  <halfline> there's no doubt the X server could fail in a more
   robust way
   [11:50:12]  <mezcalero> notting: hmm, in systemd graphical.target is
   currently configured as true superset of multi-user.target default
   [11:50:19]  <halfline> but it's still ultimately a failure we should be
   avoiding...
   [11:50:19]  <mezcalero> s/default/by default
   [11:50:26]  <mezcalero> halfline: yes, that is true
   [11:51:22]  <mjg59> mezcalero: There's a great deal about X that is some
   distance from what you'd expect
   [11:52:39]  <halfline> mezcalero: i remember looking into this issue one
   time before
   [11:52:53]  <halfline> mezcalero: and it turned out to be something caused
   by egbert commenting out some code
   [11:53:43]  <halfline> basically X used to detach it's controlling
   terminal but doesn't anymore
   [11:54:03]  <halfline> and so to work around that, X sets some terminal
   attributes and calls tcflush in a loop
   [11:54:32]  <halfline> (since X doesn't ever read from the tty, it has
   /dev/input)