Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

journald: add support for specifying syslog facility #2425

Closed
wants to merge 1 commit into from

Conversation

oherrala
Copy link

@oherrala oherrala commented Dec 23, 2022

Motivation

Syslog facility is supported in JournalD this allows using that mechanism. This way JournalD can provide same fields as syslog messages: Syslog identifier and facility.

Solution

The Syslog facility is optional and if it is not specified, it is not included in JournalD message. The Syslog facility can be set with Subscriber::with_syslog_facility()method using e.g.libc crate's LOG_* constants: Subscriber::with_syslog_facility(libc::LOG_DAEMON).

@oherrala oherrala requested review from hawkw, davidbarsky and a team as code owners December 23, 2022 13:32
@hawkw
Copy link
Member

hawkw commented Dec 29, 2022

It looks like rustfmt needs to be run on this PR: https://github.com/tokio-rs/tracing/actions/runs/3766015080/jobs/6443426140

Would you mind running cargo fmt and committing the results? Thanks!

Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall, this looks correct. i had a few minor suggestions, but i didn't notice any significant issues with the implementation.

it would be nice to get a review from @Ralith (tracing-journald's original author) as well.

tracing-journald/src/lib.rs Outdated Show resolved Hide resolved
tracing-journald/src/lib.rs Outdated Show resolved Hide resolved
tracing-journald/src/lib.rs Outdated Show resolved Hide resolved
tracing-journald/src/lib.rs Show resolved Hide resolved
/// message. This lets the configuration file specify that messages from
/// different facilities will be handled differently.
#[derive(Copy, Clone)]
pub enum SyslogFacility {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we know that the list of syslog facilities will always be the same across various operating systems and libcs? should this maybe have a #[non_exhaustive] on it just in case?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

journald so far is Linux-only I think? And I expect Linux's definitions to stay stable.

Comment on lines 306 to 349
/// security/authorization messages
Auth,
/// security/authorization messages (private)
Authpriv,
/// clock daemon (cron and at)
Cron,
/// system daemons without separate facility value
Daemon,
/// ftp daemon
Ftp,
/// kernel messages (these can't be generated from user
/// processes)
Kern,
///reserved for local use
Local0,
///reserved for local use
Local1,
///reserved for local use
Local2,
///reserved for local use
Local3,
///reserved for local use
Local4,
///reserved for local use
Local5,
///reserved for local use
Local6,
///reserved for local use
Local7,
/// line printer subsystem
Lpr,
/// mail subsystem
Mail,
/// USENET news subsystem
News,
/// messages generated internally by syslogd(8)
Syslog,
/// generic user-level messages
User,
/// UUCP subsystem
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: generally, the documentation comments for enum variants are capitalized:

Suggested change
/// security/authorization messages
Auth,
/// security/authorization messages (private)
Authpriv,
/// clock daemon (cron and at)
Cron,
/// system daemons without separate facility value
Daemon,
/// ftp daemon
Ftp,
/// kernel messages (these can't be generated from user
/// processes)
Kern,
///reserved for local use
Local0,
///reserved for local use
Local1,
///reserved for local use
Local2,
///reserved for local use
Local3,
///reserved for local use
Local4,
///reserved for local use
Local5,
///reserved for local use
Local6,
///reserved for local use
Local7,
/// line printer subsystem
Lpr,
/// mail subsystem
Mail,
/// USENET news subsystem
News,
/// messages generated internally by syslogd(8)
Syslog,
/// generic user-level messages
User,
/// UUCP subsystem
/// Security/authorization messages
Auth,
/// Security/authorization messages (private)
Authpriv,
/// Clock daemon (`cron` and `at`)
Cron,
/// System daemons without separate facility value
Daemon,
/// FTP daemon
Ftp,
/// Kernel messages (these can't be generated from user
/// processes)
Kern,
/// Reserved for local use
Local0,
/// Reserved for local use
Local1,
/// Reserved for local use
Local2,
/// Reserved for local use
Local3,
/// Reserved for local use
Local4,
/// Reserved for local use
Local5,
/// Reserved for local use
Local6,
/// Reserved for local use
Local7,
/// Line printer subsystem
Lpr,
/// Mail subsystem
Mail,
/// USENET news subsystem
News,
/// Messages generated internally by `syslogd(8)`
Syslog,
/// Generic user-level messages
User,
/// UUCP subsystem

tracing-journald/src/lib.rs Show resolved Hide resolved
Comment on lines 305 to 350
pub enum SyslogFacility {
/// security/authorization messages
Auth,
/// security/authorization messages (private)
Authpriv,
/// clock daemon (cron and at)
Cron,
/// system daemons without separate facility value
Daemon,
/// ftp daemon
Ftp,
/// kernel messages (these can't be generated from user
/// processes)
Kern,
///reserved for local use
Local0,
///reserved for local use
Local1,
///reserved for local use
Local2,
///reserved for local use
Local3,
///reserved for local use
Local4,
///reserved for local use
Local5,
///reserved for local use
Local6,
///reserved for local use
Local7,
/// line printer subsystem
Lpr,
/// mail subsystem
Mail,
/// USENET news subsystem
News,
/// messages generated internally by syslogd(8)
Syslog,
/// generic user-level messages
User,
/// UUCP subsystem
Uucp,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i believe that an enum variant's value can be assigned to a constant of the enum's repr type (i had to check, see this playground). i think we should be able to write something like this:

Suggested change
pub enum SyslogFacility {
/// security/authorization messages
Auth,
/// security/authorization messages (private)
Authpriv,
/// clock daemon (cron and at)
Cron,
/// system daemons without separate facility value
Daemon,
/// ftp daemon
Ftp,
/// kernel messages (these can't be generated from user
/// processes)
Kern,
///reserved for local use
Local0,
///reserved for local use
Local1,
///reserved for local use
Local2,
///reserved for local use
Local3,
///reserved for local use
Local4,
///reserved for local use
Local5,
///reserved for local use
Local6,
///reserved for local use
Local7,
/// line printer subsystem
Lpr,
/// mail subsystem
Mail,
/// USENET news subsystem
News,
/// messages generated internally by syslogd(8)
Syslog,
/// generic user-level messages
User,
/// UUCP subsystem
Uucp,
#[repr(i32)]
pub enum SyslogFacility {
/// security/authorization messages
Auth = libc::LOG_AUTH as i32,
/// security/authorization messages (private)
Authpriv = libc::LOG_AUTHPRIV as i32,,
/// clock daemon (cron and at)
Cron = libc::LOG_CRON as i32,
/// system daemons without separate facility value
Daemon = libc::LOG_DAEMON as i32,
/// ftp daemon
Ftp = libc::LOG_FTP as i32,
/// kernel messages (these can't be generated from user
/// processes)
Kern = libc::LOG_KERN as i32,
///reserved for local use
Local0 = libc::LOG_LOCAL0 as i32,
///reserved for local use
Local1 = libc::LOG_LOCAL1 as i32,
///reserved for local use
Local2 = libc::LOG_LOCAL2 as i32,
///reserved for local use
Local3 = libc::LOG_LOCAL3 as i32,
///reserved for local use
Local4 = libc::LOG_LOCAL4 as i32,
///reserved for local use
Local5 = libc::LOG_LOCAL5 as i32,
///reserved for local use
Local6 = libc::LOG_LOCAL6 as i32,
///reserved for local use
Local7 = libc::LOG_LOCAL7 as i32,
/// line printer subsystem
Lpr = libc::LOG_LPR as i32,
/// mail subsystem
Mail = libc::LOG_MAIL as i32,
/// USENET news subsystem
News = libc::LOG_NEWS as i32,
/// messages generated internally by syslogd(8)
Syslog = libc::LOG_SYSLOG as i32,
/// generic user-level messages
User = libc::LOG_USER as i32,
/// UUCP subsystem
Uucp = libc::LOG_UUCP as i32,

if we did this, we could remove the match in put_facility and replace it with just let value = facility as i32;, which would be nice. however, this does rely on these values being a c_int (castable to an i32) on all platforms' libcs, so we should make sure it wouldn't cause any problems to do this.

tracing-journald/src/lib.rs Outdated Show resolved Hide resolved
@hawkw hawkw requested a review from Ralith December 29, 2022 19:53
tracing-journald/src/lib.rs Outdated Show resolved Hide resolved
tracing-journald/src/lib.rs Outdated Show resolved Hide resolved
@oherrala oherrala force-pushed the syslog-facility branch 2 times, most recently from 3419e27 to cc402e6 Compare December 29, 2022 21:23
@oherrala oherrala force-pushed the syslog-facility branch 2 times, most recently from 5f5be01 to 2ea1cd6 Compare January 12, 2023 14:02
@mguender
Copy link

mguender commented Jun 5, 2023

Is this pull request actively worked on? I would be very happy to use SYSLOG_FACILTY for filtering journald logs...

@oherrala
Copy link
Author

oherrala commented Jun 5, 2023

Is this pull request actively worked on? I would be very happy to use SYSLOG_FACILTY for filtering journald logs...

I'd be happy to work towards getting this merged.

Comment on lines +292 to +294
// libc definitions are bitshifted left by 3, but journald uses
// values without bitshift.
writeln!(buf, "SYSLOG_FACILITY={}", facility >> 3).unwrap();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this seems like a potential footgun. If you Google around for facility definitions and pass one manually rather than via libc, it would be silently mangled, and passing a value different than what you'd use to filter for it is confusing.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ralith Do you have any advice how we could go forward?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I'm wondering if anyone else has ideas before we set this in stone. Both obvious options have significant drawbacks. How do other journald bindings handle it?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No much luck with my Googling of various implementations:

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, would it make more sense to punt on abstracting this entirely, and let people supply arbitrary key/value pairs to be appended globally? Particularly as this seems to be a really niche/archaic parameter.

The syslog facility is optional and if it is not specified, it is not
included in JournalD message. The SyslogFacility enum contains all the
fields specified in syslog(3) for facility and numbers are mapped
using libc's definition.
@Finomnis
Copy link
Contributor

Any reason the current change code doesn't contain the initial enum approach?

I'd like to take over this merge request, but I'm not sure if I understand its current design decisions.

@Ralith
Copy link
Collaborator

Ralith commented Aug 31, 2023

My current feeling is that this sort of niche (I think?) case is best addressed by allowing the user to specify arbitrary key-value pairs. That saves us from needing complex/opinionated APIs.

@Finomnis
Copy link
Contributor

My current feeling is that this sort of niche (I think?) case is best addressed by allowing the user to specify arbitrary key-value pairs. That saves us from needing complex/opinionated APIs.

Is there an open PR for it already? Or should we start one?

@Ralith
Copy link
Collaborator

Ralith commented Sep 1, 2023

I'm not aware of any attempt. It should be straightforward enough; if you're motivated, please feel welcome!

@oherrala
Copy link
Author

oherrala commented Sep 1, 2023

Is this PR still needed? I've not been given any actionable directions to go towards so this has been left hanging without any decisions.

@Finomnis
Copy link
Contributor

Finomnis commented Sep 1, 2023

I opened #2708, which should replace this PR, based on what was discussed above.

EDIT: After thinking about it some more, I'm actually opposed to closing this PR and would instead prefer to rework+merge it.

@Finomnis
Copy link
Contributor

Finomnis commented Sep 1, 2023

One problem I can see with allowing arbitrary values is that users can specify values that already get set by other options, like SYSLOG_IDENTIFIER and .with_syslog_identifier(). There aren't many settings left - should we simply add them all manually? That would avoid that aliasing.

I personally think that the best way forward is to proceed with adding with_syslog_facility (as this change originally intended), but with a u32/u16/u8 parameter that does not get >>3'd. This would allow compatibility with definitions like https://wiki.archlinux.org/title/Systemd/Journal#Facility and the official specification.

The fact that the values are <<3 is very specific to the journal C API, where the log level and the facility are combined in a single value. This isn't the case for us, so I oppose using the libc constants.

@Finomnis
Copy link
Contributor

Finomnis commented Sep 1, 2023

@oherrala I opened a merge request to your branch with how I would continue this PR.

Also, you should at some point merge master into your change, otherwise clippy will issue some warnings.

What's your opinion, @Ralith? Also including my previous comment about aliasing, and about continuing this PR.

I kind of need this feature for work, so I'm very interested in getting this merged. Otherwise this crate is not viable for our usecase. (we use local0/local1 to redirect logs onto specific log locations)

@hawkw hawkw closed this in 672dfdf Sep 5, 2023
@oherrala oherrala deleted the syslog-facility branch September 6, 2023 20:38
davidbarsky pushed a commit that referenced this pull request Sep 26, 2023
## Motivation

It's currently not possible to customize how messages will get send to journald.

This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.

So in a sense, this is the successor/rework of #2425.

## Solution

Allow custom fields to be set in tracing-journald.

## Open Questions

- [x] How should we deal with fields that also get supplied by other options?
  For example, setting `SYSLOG_IDENTIFIER` here and also setting
  `.with_syslog_identifier()` will send said field twice, potentially with
  differing values. Is that a problem?
    - Answer: No, this is not a problem.

Closes #2425
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
## Motivation

It's currently not possible to customize how messages will get send to journald.

This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.

So in a sense, this is the successor/rework of #2425.

## Solution

Allow custom fields to be set in tracing-journald.

## Open Questions

- [x] How should we deal with fields that also get supplied by other options?
  For example, setting `SYSLOG_IDENTIFIER` here and also setting
  `.with_syslog_identifier()` will send said field twice, potentially with
  differing values. Is that a problem?
    - Answer: No, this is not a problem.

Closes #2425
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
## Motivation

It's currently not possible to customize how messages will get send to journald.

This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.

So in a sense, this is the successor/rework of #2425.

## Solution

Allow custom fields to be set in tracing-journald.

## Open Questions

- [x] How should we deal with fields that also get supplied by other options?
  For example, setting `SYSLOG_IDENTIFIER` here and also setting
  `.with_syslog_identifier()` will send said field twice, potentially with
  differing values. Is that a problem?
    - Answer: No, this is not a problem.

Closes #2425
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
It's currently not possible to customize how messages will get send to journald.

This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.

So in a sense, this is the successor/rework of #2425.

Allow custom fields to be set in tracing-journald.

- [x] How should we deal with fields that also get supplied by other options?
  For example, setting `SYSLOG_IDENTIFIER` here and also setting
  `.with_syslog_identifier()` will send said field twice, potentially with
  differing values. Is that a problem?
    - Answer: No, this is not a problem.

Closes #2425
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
It's currently not possible to customize how messages will get send to journald.

This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.

So in a sense, this is the successor/rework of #2425.

Allow custom fields to be set in tracing-journald.

- [x] How should we deal with fields that also get supplied by other options?
  For example, setting `SYSLOG_IDENTIFIER` here and also setting
  `.with_syslog_identifier()` will send said field twice, potentially with
  differing values. Is that a problem?
    - Answer: No, this is not a problem.

Closes #2425
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
It's currently not possible to customize how messages will get send to journald.

This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.

So in a sense, this is the successor/rework of #2425.

Allow custom fields to be set in tracing-journald.

- [x] How should we deal with fields that also get supplied by other options?
  For example, setting `SYSLOG_IDENTIFIER` here and also setting
  `.with_syslog_identifier()` will send said field twice, potentially with
  differing values. Is that a problem?
    - Answer: No, this is not a problem.

Closes #2425
davidbarsky pushed a commit that referenced this pull request Sep 29, 2023
It's currently not possible to customize how messages will get send to journald.

This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.

So in a sense, this is the successor/rework of #2425.

Allow custom fields to be set in tracing-journald.

- [x] How should we deal with fields that also get supplied by other options?
  For example, setting `SYSLOG_IDENTIFIER` here and also setting
  `.with_syslog_identifier()` will send said field twice, potentially with
  differing values. Is that a problem?
    - Answer: No, this is not a problem.

Closes #2425
hawkw pushed a commit that referenced this pull request Oct 1, 2023
It's currently not possible to customize how messages will get send to journald.

This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.

So in a sense, this is the successor/rework of #2425.

Allow custom fields to be set in tracing-journald.

- [x] How should we deal with fields that also get supplied by other options?
  For example, setting `SYSLOG_IDENTIFIER` here and also setting
  `.with_syslog_identifier()` will send said field twice, potentially with
  differing values. Is that a problem?
    - Answer: No, this is not a problem.

Closes #2425
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants