Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 6597

Summary: syslogd does not accept connections to /dev/log
Product: [Retired] Red Hat Linux Reporter: jonathan
Component: sysklogdAssignee: Bill Nottingham <notting>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: jrush, oc_developer, rvokal, tnorcros
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-12-01 19:35:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description jonathan 1999-11-01 11:52:16 UTC
/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
use strict;
use Socket;

socket(SOCK, PF_UNIX, SOCK_STREAM, 0)  || die "socket: $!";
connect(SOCK, sockaddr_un('/dev/log')) || die "connect: $!";

The equivalent Python:

#! env python

import socket

sock = socket.socket (socket.AF_UNIX, socket.SOCK_STREAM)
sock.connect ('/dev/log')

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

Comment 1 jonathan 1999-11-01 14:50:59 UTC
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
RH 6.0.

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
syslogd sources?


Jonathan <>

Comment 2 Bill Nottingham 1999-11-01 16:07:59 UTC
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


import syslog

Both work fine on 6.1; I see no reason to think they wouldn't
work fine on earlier releases as well.

Comment 3 jonathan 1999-11-04 12:34:59 UTC
> 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.


Comment 4 Bill Nottingham 1999-12-01 19:35:59 UTC
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
available sockets.