/dev/log disappeared on upgrade

I've noticed (and LANANA backs me up here) that /dev/log isn't a device node at all, it's a UNIX socket. I use syslog-ng myself on a number of machines, and I configure it to read it as a unix-stream.

root@log-tp:~# ls -l /dev/log
srw-rw-rw- 1 root root 0 Mar 17 18:33 /dev/log

What that means is I have doubts that MAKEDEV will work. I honestly don't know what creates /dev/log – if I look at what has it open on one of my syslog-ng managed machines, I find only syslog-ng:

root@log-collect:~# lsof /dev/log
COMMAND    PID USER   FD   TYPE     DEVICE SIZE/OFF   NODE NAME
syslog-ng 2522 root    7u  unix 0xe09a1200      0t0   4695 /dev/log
syslog-ng 2522 root   51u  unix 0xe14e6040      0t0   4897 /dev/log
syslog-ng 2522 root   56u  unix 0xe09a1c80      0t0 577713 /dev/log

I would assume, therefore, that the other end is the kernel. Let me know what you find, I'm interested too. The good news for you is that both machines I listed above are running paravirt, so it isn't a kernel issue…probably udev.

Well, it is a local socket. So, syslog daemon listens on it, and clients connect to it. If syslog-ng would have write access to /dev, it probably would have create it itself… and the longer I look at the glibc socket interface, the less I think any other option is possible… seems that you can't bind() again to an "abandoned" socket. If I'm wrong about this, making the socket by manually with a few lines of C and chmoding it 666 could work.

@rsk:

Well, it is a local socket. So, syslog daemon listens on it, and clients connect to it. If syslog-ng would have write access to /dev, it probably would have create it itself… and the longer I look at the glibc socket interface, the less I think any other option is possible… seems that you can't bind() again to an "abandoned" socket. If I'm wrong about this, making the socket by manually with a few lines of C and chmoding it 666 could work.
You might be on to something. /dev/log was there already when I pointed syslog-ng at it, though (it looks like rsyslogd might have created it before I purged it).

@man syslog-ng:

Typically messages are sent to syslog-ng via a Unix domain socket (/dev/log) … To receieve messages from the kernel, /dev/klog is opened for reading.
After removing syslog-ng from the default runlevel and removing /dev/log before rebooting, it looks like (at least in gentoo), the socket is created by syslog-ng at startup:

# ls -l /dev/log
ls: cannot access /dev/log: No such file or directory
# /etc/init.d/syslog-ng start
 * Starting syslog-ng ...                                                 [ ok ]
# ls -l /dev/log
srw-rw-rw- 1 root root 0 Mar 23 19:40 /dev/log
#

So for the OP, I would say that a missing /dev/log might just be a symptom, and syslog-ng isn't starting up for some other reason. Is there anything related to syslog-ng showing in the boot messages shown on the LISH console?

EDIT:

OK, I see that /dev/log is defined in the syslog-ng.conf file. Do you still have something like this in your syslog-ng.conf?

source src {
    unix-stream("/dev/log" max-connections(256));
    internal();
    file("/proc/kmsg");
};

Yep. It turns out that this file is created by syslog-ng and syslog-ng (which was also upgraded) is failing to start. Some problem with the format of the configuration files. Thanks for the pointers.

@AtomicDog:

Yep. It turns out that this file is created by syslog-ng and syslog-ng (which was also upgraded) is failing to start. Some problem with the format of the configuration files. Thanks for the pointers.
They tend to do that when you upgrade. I run 3.1beta2 in production and they released 3.1 on Monday…I don't really feel like upgrading, because I know something will break (and it isn't the best at telling you what).

If you aren't already, make the jump to 3.0+ since you're already fixing the last upgrade. TLS, pattern DB matching, etc. It's very worth it, unless you're just packaging up local logs into files (and if you are, syslog-ng is like bringing an M1A1 to a gunfight).

@jed:

If you aren't already, make the jump to 3.0+ since you're already fixing the last upgrade. TLS, pattern DB matching, etc. It's very worth it, unless you're just packaging up local logs into files (and if you are, syslog-ng is like bringing an M1A1 to a gunfight).
The gentoo install guide recommends several different loggers, but then the example commands show an install of syslog-ng, so I think most people consider it the default.

And 3.0.4 is the stable version in gentoo, so switching to the 3.0 series is probably what broke his config.

And finally, if I was going to be in a gunfight, and I had a M1A1 handy, it would certainly be a no-brainer ;)