Bug 229775 - syslog(3) includes process id in each message even if LOG_PID is not specified as 2nd argument of openlog(3)
Summary: syslog(3) includes process id in each message even if LOG_PID is not specifie...
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2018-07-14 19:03 UTC by Yasuhiro KIMURA
Modified: 2020-05-28 20:58 UTC (History)
5 users (show)

See Also:


Attachments
Sample program to reproduce the problem (364 bytes, text/plain)
2018-07-14 19:03 UTC, Yasuhiro KIMURA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yasuhiro KIMURA 2018-07-14 19:03:52 UTC
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).
Comment 1 Yasuhiro KIMURA 2018-07-14 23:15:10 UTC
(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)
Comment 2 Yuri Pankov 2018-07-15 00:42:19 UTC
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.
Comment 3 Yasuhiro KIMURA 2018-07-15 07:38:21 UTC
(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.
Comment 4 Ed Schouten freebsd_committer 2018-07-15 13:43:34 UTC
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.
Comment 5 Conrad Meyer freebsd_committer 2018-10-09 05:05:08 UTC
Agree.
Comment 6 P Kern 2020-05-28 20:55:07 UTC
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.
Comment 7 P Kern 2020-05-28 20:58:01 UTC
(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.