Toying around -- console log in X

zirias@

zirias@

Developer
Update 2016-03-27:
v0.2 released

Update 2016-03-25:
Found a problem with `xcons_curses` -- after hours, it stops working, eating up all the cycles of the core it is running on. I'm trying to debug this behavior now, hopefully pushing a fix soon. edit: I think this fixed it

Update 2016-03-22:
Now there IS an improvement (a unix domain socket is used now, this is much more reliable and allows multiple consoles reading from it) and a new name:
https://github.com/zirias/xcons

Hi all,

today I produced a little bit of code to help with getting a "console log" on my desktop -- you know, like xconsole, just different. Basic idea is having syslogd write to a FIFO that's read and displayed by a little curses(3) tool running inside an X terminal emulator.

This is what it looks like for me now:
consolepipe.png

If anyone interested, here is the code. I use this line in syslog.conf(5):
Code: 
*.err;kern.notice;auth.notice;mail.crit |exec /home/felix/bin/pipewrite /usr/local/var/run/console.pipe
The pipe was created with mkfifo /usr/local/var/run/console.pipe

For display, I used konsole with a custom profile starting /home/felix/bin/consolepipe /usr/local/var/run/console.pipe instead of a shell -- you can match that with a kwin window-specific rule quite easily because konsole creates the window first with the name of the profile as title.

So what do you think of this idea? Any improvements?
 
Last edited:
Do you know kqueue(2) ? If you don't, check it out, it's awesome!

Multicast is also an option here. You don't need to run those routing daemons, if you don't want to, just route 224/4 to local ethernet.

Juha
 
Juha Nurmela said:
Multicast is also an option here. You don't need to run those routing daemons, if you don't want to, just route 224/4 to local ethernet.
Click to expand...
Hi, was this part really meant as a follow-up to my post? If so, please explain, I don't see the connection.

As for kqueue(2), sure I heard of it, but I thought it would be overkill for my "xconsole-like-toy" -- right now, the code is kept portable and uses pselect(2), which seems good enough :)
 
There's the @loghost:udpport "action". You could use a multicast address there, syslogd(8) does not mind, and then receive on that address anywhere on the local lan, no special multiplex-process needed and running multiple "voyeurs" on a machine is no problem either.

One glitch with the simple setup: if 224/4 is forcibly routed to a disconnected ethernet, syslogd adds an error message after each message.

Yes, the portability thing... Really irritating. Finally there's a mechanism to select for input, catch signals and watch for file changes, no races, neat compact code, and then one must avoid using it :)

Likes to watch *.*,
Juha
 
Juha Nurmela said:
There's the @loghost:udpport "action". You could use a multicast address there, syslogd(8) does not mind, and then receive on that address anywhere on the local lan, no special multiplex-process needed and running multiple "voyeurs" on a machine is no problem either.
Click to expand...
Ah, now I get what you mean. Sure, that's an alternative, but I was thinking about the local scenario, really a lot like the old xconsole, and how to improve on that idea. So, why have network interfaces involved in local communication? But of course, a nice addition would be to allow other inputs for the watcher / "voyeur" part (which I have use curses(3) so it can use colors, hide the cursor, and that way work nicely with any X terminal emulator).

Juha Nurmela said:
Yes, the portability thing... Really irritating. Finally there's a mechanism to select for input, catch signals and watch for file changes, no races, neat compact code, and then one must avoid using it :)
Click to expand...
Well ... I used inotify on linux before and realized only later that the tool might be handy on other systems as well, so ... If there's really a need, I'd probably use a library like libev in future projects. For this little thing, where I expect a single client almost all the time, pselect(2) is just fine :)
 
Thanks for the libev pointer.

There is a free bonus with system logs from multiple boxes. It's easy to catch a crash: Host suchnsuch has not said anything in one hour.

Juha
 
Still putting some work into this, v0.2 is there and it becomes really usable :) Any other feedback? Thinking about implementing a cache of the last n log lines in xcons_service, so a newly connected client gets them ... good idea?
 
You must log in or register to reply here.
Back
Top