#1372 Set debug level to 2 by default
Closed: wontfix 2 years ago by pbrezina. Opened 9 years ago by sgallagh.

Users regularly complain that the default debug level is insufficiently low to identify the cause of problems in their systems. I think it's reasonable to say that the default debug level should include SSSDBG_FATAL_FAILURE, SSSDBG_CRIT_FAILURE and SSSDBG_MINOR_FAILURE.

To that end, we need to examine each use of these levels (or their associated numeric value, 0-2, resp.) in the SSSD source and ensure that we aren't going to produce needlessly noisy results with this new default.

I think it would also be useful to review the use of numeric level 9. In the new schema, it's reserved for very low-level tracing (such as LDB transaction start/end), but the existing code uses level 9 quite a lot for messages that should be more visible.

I agree, but I think that's a much larger effort. I've opened a separate ticket (#1374) to track this.

I'd rather see this particular subset addressed sooner rather than later.'

(Aside: I'd actually like to see LDB transaction start/end at SSSDBG_TRACE_INTERNAL rather than SSSDBG_TRACE_ALL, but maybe we need to discuss that).

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11.0 (LTM)
rhbz: => todo

Fields changed

proposed_priority: => Nice to have

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: SSSD 1.11.0 (LTM) => SSSD 1.10 beta

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Fields changed

mark: => 0

Fields changed

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: minor => trivial
review: => 0

Mass-moving tickets not planned for any immediate release and re-setting priority.

milestone: SSSD 1.13 backlog => SSSD Deferred
priority: trivial => major

We really should fix this :-)

What we can start with is select the most common actions (login, offline login, password change, server failover) and make sure those don't emit any messages when running with debug_level=2.

We can even spin a separate topic tickets, chances are this one might never be fixed completely.

milestone: SSSD Deferred => NEEDS_TRIAGE
sensitive: => 0

Fields changed

owner: somebody => pcech

I propose we put tickets for use-cases we select into 1.13.3 and work on those. Then defer this ticket.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13.3

Fields changed

status: new => assigned

This ticket still needs work and we need to release 1.13.3 soon.

milestone: SSSD 1.13.3 => SSSD 1.13.4

Actually, let's see the changes in master first and then decide if we should backport them to 1.13 as well (chances are we might want to in order to make applying patches to 1.13 easier, but that's tbd)

milestone: SSSD 1.13.4 => SSSD 1.14 alpha

The 1.14 Alpha release should be small and targeted at stabilizing the refactoring and important fixes, therefore I'm demoting this ticket to the Beta milestone.

milestone: SSSD 1.14 alpha => SSSD 1.14 beta

There are still quite a few issues to fix, so I think this ticket is out of scope of 1.14.

milestone: SSSD 1.14 beta => SSSD 1.15 beta

Fields changed

status: assigned => new

I have disscused with Lukas (offline) typical use cases of SSSD:

  • getent (passwd, group, uid, gid)
  • pam (auth, account, session, passwd)
  • sudo (netgroups)

Those cases should be priority for better debug messages.

Metadata Update from @sgallagh:
- Issue assigned to pcech
- Issue set to the milestone: SSSD Future releases (no date set yet)

4 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

2 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

2 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2414

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.