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

capnslog: why check ppid = 1 for systemd? #38

Open
philips opened this issue Sep 28, 2015 · 5 comments
Open

capnslog: why check ppid = 1 for systemd? #38

philips opened this issue Sep 28, 2015 · 5 comments

Comments

@philips
Copy link

philips commented Sep 28, 2015

Current algorithm for journal detection:

  1. Check for ppid == 1 https://github.com/coreos/pkg/blob/master/capnslog/init.go#L41
  2. Check for an actual journal https://github.com/coreos/pkg/blob/master/capnslog/journald_formatter.go#L28

This is wrong for two reasons: 1. systemd isn't always pid 1 (user session) 2. it is code stutter having a heuristic and then a authoritative check after 3. even if systemd is pid, your parent might not be pid 1.

@barakmich Was there a reason for doing this check that I might be missing? Otherwise we should fix it up.

Thanks.

@barakmich
Copy link
Contributor

This aimed for the 80% case. Open for fix up suggestions. I take it you'd
like to always do journald if available. I kind of hate that, as running on
a system that happens to have journald means you get no log output in the
run-from-the-command-line case.

Is there a better detection algorithm? If so, let's do it (detect parent
name?). Or write to two outputs (stderr and journald) if detected? Many
options, not sure which is preferable.
On Sep 28, 2015 11:23 PM, "Brandon Philips" [email protected]
wrote:

Current algorithm for journal detection:

  1. Check for ppid == 1
    https://github.com/coreos/pkg/blob/master/capnslog/init.go#L41
  2. Check for an actual journal
    https://github.com/coreos/pkg/blob/master/capnslog/journald_formatter.go#L28

This is wrong for two reasons: 1. systemd isn't always pid 1 (user
session) 2. it is code stutter having a heuristic and then a authoritative
check after 3. even if systemd is pid, your parent might not be pid 1.

@barakmich https://github.com/barakmich Was there a reason for doing
this check that I might be missing? Otherwise we should fix it up.

Thanks.


Reply to this email directly or view it on GitHub
#38.

@jlamillan
Copy link

What about util.RunningFromSystemService() from coreos/go-systemd?

@xiang90
Copy link

xiang90 commented Jun 30, 2016

@jonboulle How do you think we should deal with this? Sending to journal by detecting pid+systemd is proven to confuse people, in rkt case at least:

etcd-io/etcd#5449
etcd-io/etcd#5779

@jonboulle
Copy link
Contributor

@xiang90 for this specific issue I'm sympathetic towards #38 (comment)

I'm actually not convinced that capnslog should log directly to the journal - rather it seems to me it'd be sufficient if it didn't log timestamps when it detects it's invoked from systemd.

@xiang90
Copy link

xiang90 commented Jul 4, 2016

rather it seems to me it'd be sufficient if it didn't log timestamps when it detects it's invoked from systemd.

If the timestamp is the only issue, yea, probably we should just try #38 (comment) to detect systemd, and do not log timestamp.

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

No branches or pull requests

5 participants