# Toying around -- console log in X



## zirias@ (Mar 21, 2016)

*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:



If anyone interested, here is the code. I use this line in syslog.conf(5):

```
*.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?


----------



## Juha Nurmela (Mar 23, 2016)

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


----------



## zirias@ (Mar 23, 2016)

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.


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


----------



## Juha Nurmela (Mar 23, 2016)

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


----------



## zirias@ (Mar 23, 2016)

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.


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


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


----------



## Juha Nurmela (Mar 23, 2016)

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


----------



## zirias@ (Mar 27, 2016)

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?


----------



## zirias@ (Apr 6, 2016)

quick port for clean installation -- this of course lacks all documentation and a few features would be nice ... we will see. But the port builds and installs fine.


----------

