[Bug 265] New: syslog-ng does not output the $PID of the process, even when forced
https://bugzilla.balabit.com/show_bug.cgi?id=265 Summary: syslog-ng does not output the $PID of the process, even when forced Product: syslog-ng Version: 3.4.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi@balabit.hu ReportedBy: support@sikkerhed.org Type of the Report: --- Estimated Hours: 0.0 I'm researching syslog-ng, in order to set it up on all my machines, and have them log to a central server on the network. Things are going great, except I can't seem to force syslog-ng to report the $PID of the program that logs, so sometimes I get lines that have missing $PIDS: (anonymized, but based on real log line) 2013-12-05T19:40:44.388099+01:00 web15.example.org pop3d: Connection, ip=[::ffff:x.y.z.w] Whereas I was able to change pureftpd to log with pid: 2013-12-05T19:40:44.639127+01:00 web15.example.org pure-ftpd[872804]: (?@x.y.z.w) [INFO] New connection from x.y.z.w Unfortunately, courier-imap does not have such a logging option. I thought that using $PID in the output template would force syslog-ng to log the PID of the reporting process, but this does not seem to be the case. Is it really true that there is no way to force syslog-ng to report the PID? I know that rsyslog has this feature, but I would much rather use syslog-ng :) -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=265 --- Comment #1 from Balazs Scheidler <bazsi@balabit.hu> 2013-12-06 09:36:34 --- Specifying the output template doesn't "force" the query of the PID value. The output side merely uses stuff that's already present in the message. A message can be thought of as a hierarchy of dictionary-of-values or JSON object, which is filled by the input driver and potentially modified later as the message traverses the structure specified in the configuration. What is missing right now is that syslog-ng doesn't currently support augmenting the log message with stuff like the sender's PID and that's only available if the peer application calls openlog() with LOG_PID let me see how difficult this is to add. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=265 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |algernon@balabit.hu --- Comment #2 from Balazs Scheidler <bazsi@balabit.hu> 2013-12-07 00:05:59 --- You can see a very hacky implementation on this branch at github: 3.6queue/f/peer-pid-in-log-message It does need some cleanup and I do know about some ongoing work in this area, so I'm not sure when this can be integrated. Anyway, this seemed quite complicated when I last checked, but it doesn't seem too ugly, so I think this will be indeed be added to syslog-ng. Thanks for the suggestion. I'm going to clean up the branch to prepare it for integration, and will probably split up logtransport.c while I am there. @Algernon: I know you tried at this at one time, so a review would be handy. @Algernon, @Tusa: I think It'd probably make sense to wait for the late-ack stuff before integrating this. What do you guys think? -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=265 --- Comment #3 from Gergely Nagy <algernon@balabit.hu> 2013-12-20 23:34:41 --- (In reply to comment #2)
@Algernon: I know you tried at this at one time, so a review would be handy.
I'll try to have a look between the holidays.
@Algernon, @Tusa: I think It'd probably make sense to wait for the late-ack stuff before integrating this. What do you guys think?
Either after, or around the same time, as to not conflict. But I believe you talked about this with Tusa already in person, no? -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=265 --- Comment #4 from Balazs Scheidler <bazsi@balabit.hu> 2013-12-23 17:45:20 --- My cleaned up patches destined to be integrated to 3.6 master are now available at the same branch, it contains a bit more functionality than what you have requested, as unix-dgram/unix-stream sources add .unix.pid, .unix.uid., .unix.gid, .unix.exe and .unix.cmdline to the message when they are received. .unix.pid is used to populate $PID in the system() source. It'll get integrated to master shortly. If you have any further comments, feedback, etc, those would be appreciated. Thanks. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
How much more work would it be to have the .unix.login and/or the .unix.group into this? To get the login as a post/processed item may be difficult as the login may not be available on a syslog server, and over time the uid to login may change making historic logs less accurate/usable. Evan. On 12/23/2013 08:45 AM, bugzilla@wwwold.balabit.com wrote:
https://bugzilla.balabit.com/show_bug.cgi?id=265
--- Comment #4 from Balazs Scheidler <bazsi@balabit.hu> 2013-12-23 17:45:20 ---
My cleaned up patches destined to be integrated to 3.6 master are now available at the same branch, it contains a bit more functionality than what you have requested, as unix-dgram/unix-stream sources add
.unix.pid, .unix.uid., .unix.gid, .unix.exe and .unix.cmdline to the message when they are received.
.unix.pid is used to populate $PID in the system() source.
It'll get integrated to master shortly.
If you have any further comments, feedback, etc, those would be appreciated.
Thanks.
Evan Rempel <erempel@uvic.ca> writes:
How much more work would it be to have the .unix.login and/or the .unix.group into this?
I wouldn't put that in the same code, as resolving login and group are more expensive than figuring out the rest. However, it's not all that hard to make a template function to do that. That's not quite automatic, but still nicer than having a flag to opt into it, I believe. -- |8]
participants (3)
-
bugzilla＠bugzilla.balabit.com
-
Evan Rempel
-
Gergely Nagy