Bug 231236 - dns/ddclient: logging via syslog not possible
Summary: dns/ddclient: logging via syslog not possible
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-08 08:46 UTC by O. Hartmann
Modified: 2019-07-22 20:30 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (mjl)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2018-09-08 08:46:37 UTC
Running 12-CURRENT; ports and sources are (seemingly) up to date as /usr/ports is up to date and OS is 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #30 r338531: Sat Sep  8 07:32:10 CEST 2018 amd64.

Having configured dns/ddclient with option "syslog=yes" in /usr/local/etc/ddclient.conf (see below, working config) should provide syslog backed logging. But it doesn't!

I've configured in /usr/local/etc/syslog.d/ddclient.conf the following line:

!ddclient
*.* /var/log/ddclient.log

That should be sufficient. I checked further whether syslogd works properly and even deleagtin any(!) syslog output via 

*.* /var/log/everything.log

in /etc/syslog.conf should provide any "burp" from ddclient, if ever any goes off. 

Testing with "logger -p daemon.info -t ddclient Something" works and get its expected impact on /var/log/ddclient.log.

So, my conclusion is that something is broken with ddclient/perl.


My configuration file looks like that:

# Globale Variablendefinitionen
daemon=1800
syslog=yes
#facility=daemon
#priority=info
retry=yes
mail=root
mail-failure=root
pid=/var/run/ddclient.pid


###
ssl=yes
ipv6=yes
protocol=dyndns2
use=if, if=tun0
server=server.to.contact
login=my@email
password='somePASSWDorTOKEN'
script=/update
wildcard=yes
all
Comment 1 mjl 2018-09-11 01:19:35 UTC
I am seeing ddclient output in /var/log/messages, printed as follows:

Sep 10 08:27:39 ZZZ ddclient[60334]: SUCCESS:  updating XXX.dyndns.org: good: IP address set to YYY

I have not tried to shift ddclient logging away from /var/log/messages.  When I have modified syslog for other programs, I've modified /etc/syslog.conf, i.e.:

!ddclient
*.*                                             /var/log/ddclient.log

Are you using a syslog from ports?  What is the output of "which logger"
Comment 2 O. Hartmann 2018-09-14 09:04:29 UTC
(In reply to mjl from comment #1)

For the record.
The system in question is using NETINET6 in the kernel, the NICs do have linklocal addresses, but IPv6 isn't used anyway at the moment. securitylevel=1.

I do not use a logger from ports, this is FreeBSD's logger.

[~] which logger
/usr/bin/logger
Comment 3 O. Hartmann 2018-09-14 09:51:52 UTC
Log messages sent via 

/etc/ppp/ppp.linkup and !bg are sent to the proper log facility and I can clearly watch them appearing in the log file specified via !ddclient.

Othe daemones or instances log as well. ddclient itself does not.
Comment 4 ncrogers 2019-07-22 20:30:58 UTC
I ran into the same problem recently. I think this used to work, but the syslog output changed in 12.0 and ddclient uses the logger(1) CLI tool to log to syslog, which actually has nothing to do with perl.

https://reviews.freebsd.org/D14926
https://forums.freebsd.org/threads/logger-output-changed-in-12-0.69460/


In ddclient code:

sub logger {
    	return pipecmd("logger -p$facility.$priority -t${program}\[$$\]", @_);


It manually includes the process PID in the tag, and I believe syslog output changed in 12.0 to include this automatically or something like that.  In my case, I end up with what appears like two PIDs in /var/log/messages entries for ddclient. One is for the actual daemon inserted by ddclient and the other is the process of logger(1). For example:

Jul 22 12:59:46 testhost ddclient[21473][21481]: FAILED:   updating ...


In any case I believe this has something to do with the problem, as I am also unable to come up with a syslog.conf that successfully logs to another file. I thought I would share this experience in case it helps anyone else.