Red Hat Bugzilla – Bug 6597
syslogd does not accept connections to /dev/log
Last modified: 2014-03-16 22:10:56 EDT
/dev/log does not seem to be being listened on by syslogd
which started in the usual way from /etc/rc.d/init.d/syslog
The socket is created, but trivial tests of socket use then
fail, such as the following Perl script:
#! /usr/bin/perl -w
socket(SOCK, PF_UNIX, SOCK_STREAM, 0) || die "socket: $!";
connect(SOCK, sockaddr_un('/dev/log')) || die "connect: $!";
The equivalent Python:
#! env python
sock = socket.socket (socket.AF_UNIX, socket.SOCK_STREAM)
fails also, returning 'Connection refused' in the same way.
Both these scripts work fine under RH 6.0.
This issue prevents some subsystems (eg Zope) from logging
in their normal fashion via /dev/log.
Jonathan Marsden <firstname.lastname@example.org>
This issue seems to be that syslogd changed to use DGRAM rather than
STREAM sockets. Changing SOCK_STREAM to SOCK_DGRAM in both sample
scripts results in scripts that work under RH 6.1, but fail under
So now the question becomes, is there a reasonable way to do this
portably? In Python, using try: ... except: ... works, but seems
ugly. Is there a better way?
And was this change to a well-known interface (/dev/log)
documented anywhere appropriately, other than in the bowels of the
It was changed for security reasons.
If you'd like to use portable code, you can use the native
interfaces to syslog in both languages;
use Sys.Syslog (you might need to add qw(:DEFAULT setlogsock)
so you can tell it to use local unix sockets as opposed to
Both work fine on 6.1; I see no reason to think they wouldn't
work fine on earlier releases as well.
> It was changed for security reasons.
So this means that other RH 6.1 subsystems that use STREAM sockets
will soon be releasing security fixes so they use DGRAM sockets
> If you'd like to use portable code, you can use the native
> interfaces to syslog in both languages;
No, that module is not available on all platforms, so importing it
actually *breaks* portability! This is why that approach was not
used in the first place.
The main reason for coding a separate logging system is to ensure
it can work under Linux (use /dev/log), Win NT (use UDP to port 514),
or (other places) just write to a log file.
But it seems extremely unfortunate to have to code separately for
RH 6.0 and RH 6.1, which are minor variations on one version of
one Linux distribution.
If you are going to change known public interfaces such as /dev/log,
especially in a minor revision update, not a new major rev,
could I respectfully suggest that you at least actually document
such changes clearly and visibly when the new revision (RH 6.1 in this
case) is released?
If the use of STREAM unix sockets is per se a security issue (I am
unclear why this would be the case, but will accept your word on it),
then it seems we are stuck with trying both STREAM and DGRAM socket
types, and using whichever one lets us connect.
Actually, this should be fixed across releases now, with the
release of the sysklogd security errata for all releases.
The security problem, as mentioned in the errata, is that
the use of stream sockets allows a user to use up all the