[SOLVED] xconsole + /dev/console in Slackware

Soderlund · 05-01-2015, 03:35 AM

I have a problem with xconsole in Slackware 14.1. It won't display any logs.

I've tried:

Uncommented kern.* /dev/console in /etc/syslog.conf and restarted syslog (kill -SIGHUP <pid>; /etc/rc.d/rc.syslog restart)
chmod 0666 /dev/console (xconsole will just display an error message if /dev/console has perms 0600)
xconsole -file /dev/console

xconsole doesn't display any logs, even if i write *.* /dev/console in /etc/syslog.conf. It doesn't even display logger -p kern.0 'test'.

As I understand it, this is how it works: /etc/syslog.conf tells syslog to log to /dev/console. xconsole -f /dev/console tells xconsole to read from /dev/console. Seems straightforward, but no luck.

[EDIT]

lsof -p `pidof /usr/sbin/syslogd` does not list /dev/console. Does this mean that syslog isn't really writing to /dev/console and that's why xconsole doesn't show any logs?

echo 'test' > /dev/console doesn't work either, by the way.

Didier Spaier · 05-01-2015, 04:29 AM

Here everything works as expected, without any fiddling with permissions or anything.

Way to reproduce:

Fire up an xterm.
Become root.
Type xconsole& => this opens a widget with a blank line
Type
Code:
```
echo 'test' >/dev/console
```
In the widget is displayed:
Code:
```
test
```
Edit /etc/syslog.conf to uncomment "# kern.* /dev/console" and save the file
Type: /etc/rc.d/rc.d/rc.syslog restart
Now all new messages in /var/log/syslog are also displayed in the widget.

Soderlund · 05-01-2015, 04:42 AM

That doesn't work for me. The message never shows up in xconsole.

I figured out a solution that works:

Code:

# mkfifo /dev/xconsole
# chmod 0666 /dev/xconsole

In /etc/syslog.conf, add:

Code:

kern.* |/dev/xconsole

Restart syslog.

Then start xconsole with:

Code:

$ xconsole -file /dev/xconsole

I noticed the following:

Code:

$ ls -l /dev/*console
crw-rw-rw- [...] /dev/console
prw-rw-rw- [...] /dev/xconsole

$ file /dev/*console
/dev/console:  character special
/dev/xconsole: fifo (named pipe)

Is your /dev/console a fifo named pipe or character special?

Didier Spaier · 05-01-2015, 04:49 AM

Code:

~$ file /dev/console
/dev/console: character special 
~$ stat /dev/console
  Fichier*: «*/dev/console*»
   Taille*: 0           Blocs*: 0          Blocs d'E/S*: 4096   fichier spécial de caractères
Périphérique*: 5h/5d    Inœud*: 1037        Liens*: 1     Type de périph.*: 5,1
Accès*: (0600/crw-------)  UID*: (    0/    root)   GID*: (    0/    root)
 Accès*: 2015-04-30 00:23:02.428000294 +0200
Modif.*: 2015-05-01 11:07:20.428000294 +0200
Changt*: 2015-04-30 00:23:02.428000294 +0200
  Créé*: -
~$

GazL · 05-01-2015, 04:52 AM

Didier, what display manager do you use? I never got it working on Slackware64, when X11 was started via XDM, or in a session started via startx.

Linux doesn't appear to treat /dev/console the same as some other UNIX (*BSDs included), instead it seems to be the same as /dev/tty0 and writes to the currently active vt. Anyway, by tracing xconsole, I discovered that xconsole uses /dev/xconsole instead.

To get xconsole to work, what I did was this:

Create a named pipe in /dev

Code:

#mknod -m 644 /dev/xconsole p
#mknod -m 644 /lib/udev/devices/xconsole p

...the udev one is so that the xconsole named pipe gets recreated on reboot.

Edit /etc/syslog.conf and add the following rule to enable writing to the named pipe:

Code:

# Uncomment this to see kernel messages via the xconsole command.
kern.*                                                  |/dev/xconsole

... adjusting the message specifiers to get whatever messages you're interested in seeing in xconsole.

Then, just pkill -HUP syslogd and you should be able to start xconsole and see messages.

The above is pretty permissive and anyone will be able to start xconsole and see its messages, so depending on how much you want to tie it down, you may want to either use 640 permissions and chown it to a specific user group, or maybe even do something with ACLs. I'll leave that as an exercise for the reader

No idea why Didier didn't have to go through this rigmarole.

P.S. I did report this to Pat way back when, so its possible he's fixed it in current (I noticed that you already have the xconsole pipe - mine was definately missing on 14.1 -edit, ahh nevermind I see we cross posted and you created it manually.)

P.P.S "xterm -C" still doesn't work even with this: I think that it is still trying to use /dev/console.

Didier Spaier · 05-01-2015, 05:01 AM

The machine starts at runlevel 3, then I startx to get into fluxbox. Nothing special that can remember.

But I write this from an old Slackware-14.1 and didn't log all modifications I made.

Anyhow stay tuned, I will try in a virgo intacta Slackware64-current and report the outcome in a few minutes.

Didier Spaier · 05-01-2015, 05:23 AM

I just tried on Slackware64-current and that works exactly as stated in post #2. I even removed the only not genuine package I had installed (brltty-5.2) and that still works. This is also from fluxbox, also started at runlevel 3. the kernel is vmlinuz-huge-3.18.11.

Soderlund · 05-01-2015, 06:15 AM

Strange. I use Slackware 32-bit, by the way.

Quote:

Code:

#mknod -m 644 /lib/udev/devices/xconsole p

Ah, that will come in handy.

Thanks for the help.

GazL · 05-01-2015, 06:56 AM

I think there's a number of complications going on here.

If you run xconsole as root, it opens /dev/console, but if you run xconsole as a non-root user it uses /dev/xconsole instead.

I suspect there also some weird instanciation of /dev/console going on when its opened for reading. While I can su root -c "xconsole&" and then su root -c "echo wibble >/dev/console" and see the output, I don't start seeing kernel messages until after I've restarted syslogd by sending it a SIGHUP, which is a bit of a problem given that you'll certainly be starting xconsole after syslogd has initialised. Having said that, sometimes it seems to work without, but not other times. Something a little odd going on still.

Looking at the way it seems to be working, it seems like the xconsole named pipe is the best way to go to allow end users to use it reliably.

thirdm · 03-03-2016, 10:18 PM

Anyone still care?

I was bothered by running xconsole as non-root and getting the error
"Cannot open console". Saw your thread here. Then looked at the code a
little (xconsole.c, OpenConsole()). If /dev/xconsole does not exist or
cannot be opened it will create a pseudoterminal. It then tries to
redirect output from /dev/console to that pty using ioctl(pty slave fd,
TIOCCONS, 1). Unfortunately, Linux for some time now restricts that
ioctl request to only threads having the CAP_SYS_ADMIN capability. See
tty_ioctl(4). After running the following command I can echo a message
to /dev/console as root and see it in xconsole run as non-root. I have
no idea if this is wise. The CAP_SYS_ADMIN capability is quite broad as
you can see from capabilities(7). But perhaps this is better than setuid
which was my first thought.

# setcap cap_sys_admin=ep /usr/bin/xconsole

GazL · 03-04-2016, 05:28 AM

Yes, I still care and that clears the missing pieces up. I'm still using the fifo and syslog approach I mentioned above which allows non-root users to view the kernel messages via xconsole. Though I must admit, I rarely start xconsole these days, and there are other ways to take a peek when you need to.

Thankyou for posting.