Created attachment 195129 [details] Sample program to reproduce the problem On 12-CURRENT syslog(3) includes process id in each message even if LOG_PID is specified as 2nd argument of openlog(3). Attached sample program reproduce the problem. On 11.2-RELEASE compiled program writes following messages. Jul 15 03:45:35 eastasia syslogtest: Warning message without process ID. Jul 15 03:45:35 eastasia syslogtest[65208]: Warning message with process ID. At first LOG_PID is not specified as 2nd argument of openlog(3). So first message doesn't include process id. And next LOG_PID is specified as 2nd argument of openlog(3). So second message includes process id. On 12-CURRENT (base r336196), on the other hand, compiled program writes following messages. Jul 15 03:50:57 rolling-vm-freebsd2 syslogtest[99867]: Warning message without process ID. Jul 15 03:50:57 rolling-vm-freebsd2 syslogtest[99867]: Warning message with process ID. This time first message includes process id even if LOG_PID is not specified as 2nd argument of openlog(3).
(In reply to Yasuhiro KIMURA from comment #0) > On 12-CURRENT syslog(3) includes process id in each message even if LOG_PID is specified as 2nd argument of openlog(3) This should have been > On 12-CURRENT syslog(3) includes process id in each message even if LOG_PID is NOT specified as 2nd argument of openlog(3)
It's mentioned in syslog(3); the change is base r332100, though the related note in UPDATING (20180406) is silent on this part of the change.
(In reply to Yuri Pankov from comment #2) Behavior on 12-CURRENT doesn't conform to POSIX standard and breaks compatibility with other UNIX-like OSes. And it results in change of application behavior not intended by author. One example is security/sudo. According to man page of sudoers(5) there is following configuration option. ---------------------------------------------------------------------- syslog_pid When logging via syslog(3), include the process ID in the log entry. This flag is off by default. ---------------------------------------------------------------------- On 11.2-RELEASE it works as is expected. But on 12-CURRENT it doesn't because process ID is included regardless of this option. And from the viewpoint of user it looks like bug of sudo. So it is possible someone reports it to author of sudo. Then he will investigate and find behavior of syslog(3) changed on 12-CURRENT. And to make matters worse he will also find there is no way to implement it correctly. So it is quite possible he blames syslog(3) of 12-CURRENT is broken.
Hi Kimura-san, This change was made for the reason that many applications fail to set this flag even though they should, meaning that it's hard to distinguish log entries for multiple worker processes, detect process restarts, etc. The claim that this breaks conformance with POSIX is in my opinion unsubstantiated. Even though POSIX defines the API and explains the idea behind flags like LOG_PID, it in no way describes the actual process of logging or the exact format that is used to store entries on disk. We're allowed to log any additional metadata we want (unique message IDs, user IDs, associated TTY name, etc.), even if no flag were to be set. Though I agree that the new syslog(3) implementation is unconventional in that sense, I think that this change should be seen as something positive. It improves traceability. I therefore suggest that we close this with WONTFIX if others agree.
Agree.
Hello. I understand the rationale for making LOG_PID the default behaviour. But that change should have also included a way to cancel the default LOG_PID if a user explicitly did not want to have a PID in the syslog entry. Either that or remove the "-i" option from logger(1). Thanks.
(In reply to Conrad Meyer from comment #5) [ Sorry if this is duplication. Should this be re-submitted as a bug for logger(1) ? ] Hello. I understand the rationale for making LOG_PID the default behaviour. But that change should have also included a way to cancel the default LOG_PID if a user explicitly did not want to have a PID in the syslog entry. Either that or remove the "-i" option from logger(1). Thanks.