The Sys::Syslog man page says:


setlogsock($sock_type, $stream_location, $sock_timeout) (added in 0.25)

Sets the socket type to be used for the next call to openlog() or syslog() and returns true on success, undef on failure. The available mechanisms are:

"native" - use the native C functions from your syslog(3) library (added in Sys::Syslog 0.15).

"eventlog" - send messages to the Win32 events logger (Win32 only; added in Sys::Syslog 0.19).

"tcp" - connect to a TCP socket, on the syslog/tcp or syslogng/tcp service. If defined, the second parameter is used as a hostname to connect to.

"udp" - connect to a UDP socket, on the syslog/udp service. If defined, the second parameter is used as a hostname to connect to, and the third parameter as the timeout used to check for UDP response.

"inet" - connect to an INET socket, either TCP or UDP, tried in that order. If defined, the second parameter is used as a hostname to connect to.

"unix" - connect to a UNIX domain socket (in some systems a character special device). The name of that socket is the second parameter or, if you omit the second parameter, the value returned by the _PATH_LOG macro (if your system defines it), or /dev/log or /dev/conslog, whatever is writable.

"stream" - connect to the stream indicated by the pathname provided as the optional second parameter, or, if omitted, to /dev/conslog. For example Solaris and IRIX system may prefer "stream" instead of "unix".

"pipe" - connect to the named pipe indicated by the pathname provided as the optional second parameter, or, if omitted, to the value returned by the _PATH_LOG macro (if your system defines it), or /dev/log (added in Sys::Syslog 0.21).

"console" - send messages directly to the console, as for the "cons" option of openlog().

A reference to an array can also be passed as the first parameter. When this calling method is used, the array should contain a list of mechanisms which are attempted in order.

The default is to try native, tcp, udp, unix, pipe, stream, console. Under systems with the Win32 API, eventlog will be added as the first mechanism to try if Win32::EventLog is available.

It seems the current code does not validate the value of the --syslog-socket
option to be one of the documented names, but just passes it to setlogsock,
which happens to be a good thing.

It may indeed be sensible to let Sys::Syslog pick a suitable default,
and not call setlogsock at all unless specifically requested.

As a minimum the docs should be enhanced.

For whatever this is worth. We are running version 3.3.0 on a Solaris 10
Sparc machine with --syslog-socket=inet and it works. This is with Perl
v5.8.5 and Sys::Syslog version 0.05.

trunk:

- spamd: updated documentation on --syslog-socket, listing
  additional socket types as recognized by Sys::Syslog::setlogsock;
- Logger/Syslog.pm: allow 'log_socket' argument to be undef
  or '', making possible to skip a call to setlogsock() and
  letting Sys::Syslog choose a default;
Bug 6267 - Solaris 10 requires --syslog-socket=native
Bug 6331 - Win32: spamd logging: syslog-socket
Sending        lib/Mail/SpamAssassin/Logger/Syslog.pm
Sending        spamd/spamd.raw
Transmitting file data ..
Committed revision 910376.


Please review: svn diff -c910376
Would this solve both this bug and the Bug 6331 ?

*** Bug 6331 has been marked as a duplicate of this bug. ***

+1

btw would it be possible to default to syslog-socket=none on Win32 to avoid the errors in bug 6331?

> btw would it be possible to default to syslog-socket=none on Win32
> to avoid the errors in bug 6331?

Like this:

-my $log_socket = lc($opt{'syslog-socket'}) || 'unix';
+my $log_socket = lc($opt{'syslog-socket'});

+if (!defined $log_socket || $log_socket eq '') {
+  $log_socket =
+    Mail::SpamAssassin::Util::am_running_on_windows() ? 'none' : 'unix';
+}

trunk:

  Bug 6331 - Win32: spamd logging: syslog-socket
  make --syslog-socket default to none on Windows
Sending spamd/spamd.raw
Committed revision 910488.

Shouldn't the default socket be decided in Logger.pm and not spamd?

> Shouldn't the default socket be decided in Logger.pm and not spamd?

That would be my preference too, which is why I paved grounds for it
by the patch to Logger/Syslog.pm.

I just didn't dare to change the defaults. Avoiding the overloaded semantics
of $log_socket and $log_facility would be beneficial for understanding code
too. As I'm not running spamd, I'll let others decide and test a sensible
solution.

(In reply to comment #9)
> trunk:
> 
>   Bug 6331 - Win32: spamd logging: syslog-socket
>   make --syslog-socket default to none on Windows
> Sending spamd/spamd.raw
> Committed revision 910488.

+1 for 3.3.1.

I don't particularly mind about refactoring that into Logger.pm; for minimal changes, it's quite ok to have that in spamd.

Suggesting to go with the minimal change r910376 + r910488 for 3.3.1
and resolve this ticket, then perhaps re-open or clone it for a
cleanup of logging settings and changing a default.
( btw, I tried to go that path yesterday, but soon waded into trouble,
requiring thorough testing :)

If I'm counting correctly, it needs one more vote.

+1 for 3.3.1

(In reply to comment #13)
> Suggesting to go with the minimal change r910376 + r910488 for 3.3.1
> and resolve this ticket, then perhaps re-open or clone it for a
> cleanup of logging settings and changing a default.
> ( btw, I tried to go that path yesterday, but soon waded into trouble,
> requiring thorough testing :)
> 
> If I'm counting correctly, it needs one more vote.

+1 on this course of action.

> > Suggesting to go with the minimal change r910376 + r910488 for 3.3.1

3.3:

Bug 6267: Solaris 10 requires --syslog-socket=native
Sending lib/Mail/SpamAssassin/Logger/Syslog.pm
Sending spamd/spamd.raw
Committed revision 921213.