You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discovered in #43 the way systemd starts daemons end up creating a redirection t a socket that breaks the ability to use '/dev/stderr' as a path name to be able to effectively reopen fd=2.
This means debug level 3 ends up not containing krb5 traces because the file open fails.
We should try to see if we can find a mechanism to deal with this, in the worst case creating a socket of our own and then redirecting its output back to stderr, or perhaps finding out if we can pass an FD number instead of a path to KRB5_TRACE, maybe asking krb5 to add a KRB5_TRACE_FD option ?
The text was updated successfully, but these errors were encountered:
As discovered in #43 the way systemd starts daemons end up creating a redirection t a socket that breaks the ability to use '/dev/stderr' as a path name to be able to effectively reopen fd=2.
This means debug level 3 ends up not containing krb5 traces because the file open fails.
We should try to see if we can find a mechanism to deal with this, in the worst case creating a socket of our own and then redirecting its output back to stderr, or perhaps finding out if we can pass an FD number instead of a path to KRB5_TRACE, maybe asking krb5 to add a KRB5_TRACE_FD option ?
The text was updated successfully, but these errors were encountered: