some equivalent of console in this brave new world

[geofft]

~/.xsession-errors captures all stdout and stderr from your Athena session. This means that it captures inordinate amounts of GNOME spew, so you don't want that displayed Athena-9-console style.

The downside of this is that things that you do want displayed, like output of your .startup.X, output of from, etc., don't show up anywhere. If you want to display things at login, you need to copy the hairy anti-HTML code to invoke zenity that we added today to fix the gmotd. And, that doesn't have the nice features of Athena 9's console that it updates as more info comes in and it can hide until more input arrives.

It would be totally spiffy if someone implemented a short python-gtk or whatever app that waited for input on stdin, mapped itself, and displayed data. Then we can run .startup.X with stdout/stderr redirected to this app, and display output the user wants to see iff there is such output.

For example, RSI has code in .startup.X to display a motd on stdout, assuming the Athena 9 console. I also have code in .startup.X to display various useful output, and .xsession-errors is a useless place for it to go (it's not an error!).

[quentin]

I've implemented a basic console app that meets these needs in PyGTK at:

/mit/quentin/Public/da-console.py

I'm not too happy with the font, though, and I'm not sure if it should wrap text or not. It currently just handles text on stdin; I'd really like to see it hooked in so that it can differentiate stdout and stderr. geofft and I looked and decided that tcsh sucked for this, but it was probably doable in bash.

[jdreed]

Should the new version support config_console, show_console, and hide_console, as well as the various X resources from the Athena 9.4 version?

My first reaction would be "Yes", but I didn't think particularly hard about that, nor can I justify it.

[quentin]

Jon, can you clarify what each of those options should do? I assume they're shell variables?

I'm not sure there's a good way to support X resources from Gtk.

[jdreed]

The relevant man pages are at:

/afs/dev/source/src-current/athena/bin/config_console/{config,show,hide}_console.1

The man page for console, which describes command line options, as well as some clever behavior it had when it received various signals, is at:

/afs/dev/source/src-current/athena/etc/console/console.8

[quentin]

I added support for gconf keys /apps/da-console/{blink,auto_hide,start_visible}, doing approximately what the X resources used to do. Unfortunately, GTK doesn't expose X resources at all.

I also think I fixed the focus issues, so that it only grabs the focus when it is first mapped, but then if you receive further messages it raises without focusing.

I also added support for multiple fds; it takes fd numbers as arguments and interprets them as stdout, stderr in order. We should figure out how to hook it into the login process and into syslog this way.

[broder]

quentin, could you change the gconf keys to debathena-console instead of da-console? As a rule we don't use the da abbreviation outside of our build tools.

[quentin]

Sure, that sounds reasonable. Done.

I'm not sure if I have the focus handling correct; can someone with a real GNOME desktop try it? (It doesn't work when I X forward from my Mac, but I blame quartz-wm for that.)

The behavior I'm trying to create is that new input will raise the window without giving it focus, and you have to focus the window before you can again lower it.

[geofft]

I've packaged quentin's current draft in the da-console branch of my git repo (cd /mit/geofft/debathena/git; git log -p da-console).

Something breaks the dbus messages on a cluster machine, although it works on Linerva, so I'm waiting to see if we chance upon the fix to that quickly. Also, I haven't started hacking the login process to invoke debathena-console.

[geofft]

I've committed and built that draft, with a fix from Evan for the D-Bus issue, to -proposed; I'll also start looking at where to hook the login scripts.

[jdreed]

I understand there's a chance of this getting done at the hackathon tomorrow. Some things to note:

• The original console had timestamps, which was vaguely helpful.
• The font is huge, and linewrapped messages will suck.
• Athena 9's xlogin did a "sleep 5" or some such to allow people time to read failure messages before getting kicked back out.
• If we want them, we'll need to add quota, mailquota and "from" back into the dotfiles if we.

--- The above should be test by both Exchange and IMAP users.

[geofft]

So, I tried packaging this; the obvious approach is to stuff it in debathena-xsession and replace 00debathena-tcsh-sucks, although it could well go in a separate package.

I couldn't get it to work with tcsh, mainly due to multiple issues with tcsh's incompetence regarding file handles. The first was an inability for tcsh to reasonably redirect stdout and stderr; I tried to work around this by creating two wrapper scripts (in sh), one to redirect to console and save the original file handles and one to revert the redirection, but xsession.tcsh (and notably, not xsession.bash) appears to close the file handles when run.

So, we can't (yet) replace 00debathena-tcsh-sucks with console the way we want to. Sad.

My current code is in the console branch in /mit/geofft/debathena/git, if someone wants to pick up on it from there.

[geofft]

I should also note that removing /etc/X11/Xsession.d/00debathena-tcsh-sucks from the debathena-xsession package is effectively useless, because it's a conffile and only goes away on purge, not remove. We'll have to think harder about this; see ticket #348.

[quentin]

geofft and I discussed this, and we decided that the best solution would be to change the Xsession.tcsh code to have something like this:

mkfifo /tmp/stdout
mkfifo /tmp/stderr
debathena-console stdout:/tmp/stdout stderr:/tmp/stderr xconsole:/dev/xconsole &
( (
# old xsession here
) > /tmp/stdout ) >& /tmp/stderr

Probably with "# old xsession here" actually sourcing the old Xsession.tcsh.

[jdreed]

We could move forward with this, but debathena-console is broken:

$ debathena-console stdout:/tmp/stdout stderr:/tmp/stderr

** (debathena-console:6988): WARNING **: Trying to register gtype 'WnckWindowState' as enum when in fact it is of type 'GFlags'

** (debathena-console:6988): WARNING **: Trying to register gtype 'WnckWindowActions' as enum when in fact it is of type 'GFlags'

** (debathena-console:6988): WARNING **: Trying to register gtype 'WnckWindowMoveResizeMask' as enum when in fact it is of type 'GFlags'
Traceback (most recent call last):
  File "/usr/bin/debathena-console", line 243, in <module>
    main()
  File "/usr/bin/debathena-console", line 236, in main
    type, fd = x.split(':')
UnboundLocalError: local variable 'x' referenced before assignment

[jdreed]

Re-milestoned until console gets un-broken

[jdreed]

console is unbroken and now supports either passing fds or filenames (read: named pipes) if "-n" or "--names" is passed.

We should work on the session integration and finally kill off 00debathena-tcsh-sucks.

It has been noted that Gtk apps like to spew on stderr and this can easily confuse users, especially if the errors are in ZOMG RED.

[jdreed]

I looked at this some more in an effort to get this into Precise. We can try the tcsh wrapping suggested, but it's kind of clunky. I'll also note that since Upstart, there has been no /dev/xconsole, due to rsyslog stupidity. See  LP:459730 and  LP:612900. They both have a couple of suggested fixes, but since one has been open since Karmic, I'm not optimistic.

[jdreed]

I finally made this integrate with tcsh. Here's but a sampling of the hilarity:

• Unity complains about once/second, loudly, on stderr

-- for maximum hilarity, unity complains _about_ console, so you can't ever hide it, ever (hiding generates the complaints)

• show_console and hide_console don't work (probably due to dbus hilarity)
• python-wnck is now its own package

If we still want this (I'm not convinced we do), I think we only want stdout, not xconsole and not stderr. (blacklisting certain apps or Gtk errors is asking for trouble). I'm also not sure this shouldn't be rewritten without wnck.

[jdreed]

OK, this can't be used, because catching early shell errors, and using dbus are mutually exclusive. There's also no good way to hook it into tcsh. And ~/.xsession-errors is full of confusing spew and decidedly uninteresting. I favor a different approach.

[quentin]

This was supposed to catch stdout + stderr from just the startup process, and not from the actual running GUI programs. That was part of what made it hard to integrate with tcsh - we needed to save the original stdout and stderr, and restore them when execing gnome-session.

Can you explain the conflict with dbus?

[jdreed]

There is no session bus running at the time xsession.tcsh is run, so console has nothing to attach to. If it's just designed to catch errors from the startup process, then it can also be a lot simpler, since there will be no value in showing it after a successful login. I'm not opposed to a visual progress indicator for dotfiles, but it can be as simple as tailing ~/.xsession-errors or possibly a series of echo statements to a FIFO during the login process. If the tcsh integration is hard, that's a problem, since this is primarily _for_ tcsh. Bash has a lot fewer fatal errors. I'd rather devote time and effort into better troubleshooting of the login process; someone who breaks their login is unlikely to look at Console. The other problem is keeping it around long enough to read errors. We can't do that, since 99x11-common_start execs the session, and can't tell whether it fails or not.

[quentin]

The way I had envisioned this working is:

bash -c 'exec 3>&1 4>&2; mkfifo stdout stderr; exec 1>stdout 2>stderr; da-console stdout stderr; exec start-tcsh-session'

and then inside start-tcsh-session, after running the dotfiles,

exec bash -c 'exec 1>&3 2>&4; exec gnome-session'

You raise a good point, though, which is that something should wrap gnome-session and wait (sleep?) if it fails too quickly, so X stays up long enough to read the errors.

The dbus logic could be replaced with a unix socket or the like, if we don't want to depend on dbus. But... won't the first app in the session that uses dbus cause the session bus to be created?

I definitely think that xconsole or the equivalent should be included in console.

[jdreed]

Except it's not quite as simple as that, because of the run-parts, which exec's the xsession. That's a lot to be diverting/changing just to get dotfile error output. (The dotfile graph is very out of date at this point). It will create a session bus, just not _the_ session bus, because one of the wrapped things is dbus-launch, which happily creates its own session-bus. Like I said, I'm not opposed to replacing 000tcshsucks with something simpler that works for both bash and tcsh.

There's a lot of junk in xconsole too at this point. I think I favor a "console" which only reads from private FIFOs, which we write to in the dotfiles, and possibly to solve things like #117 too. But we should keep our design goals in mind. Normal Ubuntu does not start an xconsole, nor is it configured to syslog to one. There are no undergrads still at MIT who are used to /etc/athena/console. If we do something, I want it to be useful and not contain a lot of false positives.

[quentin]

Hm, you do raise a good point there - but I would argue that's something to be fixed whether we have console or not. Since the random GUI apps that people launch from their dotfiles should also have access to the session bus.

I think I'm mostly interested in showing authpriv syslogs; i.e. on a SIPB officehead showing SSH failed logins. Also kernel logs are probably relevant. I don't know what Ubuntu's default xconsole filter is, but I thought it was close to that.