https://bugzilla.redhat.com/show_bug.cgi?id=2336049
Bug ID: 2336049
Summary: sssd still writes to old log files after rotation due
to incorrect PID file location
Product: Fedora
Version: 41
OS: Linux
Status: NEW
Component: sssd
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: orion(a)nwra.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
sssd logs are not being rotated properly. This is due to:
postrotate
/bin/kill -HUP `cat /var/run/sssd.pid 2>/dev/null` 2> /dev/null || true
/bin/pkill -HUP sssd_kcm 2> /dev/null || true
endscript
# cat /var/run/sssd.pid
cat: /var/run/sssd.pid: No such file or directory
# find /run -name sssd.pid
/run/sssd/sssd.pid
sssd-2.10.1-1.fc41.x86_64
Reproducible: Always
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2336049
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2334868
Bug ID: 2334868
Summary: updating an existing system to sssd-2.10.1 causes sssd
to fail with permissions issues
Product: Fedora
Version: 41
OS: Linux
Status: NEW
Component: sssd
Keywords: Upgrades
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: roth(a)ursus.net
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
[this is on a ostree system (Fedora 41 Kinoite)]
From what I can tell, the sssd permissions changed recently from root:sssd to
sssd:sssd, and there are subtle differences in the way the config directories
and config files are owned that cause the most recent update to fail.
The previous version (2.10.0) had /etc/sssd at mode 0700, owned by root:sssd.
Now that the service runs as sssd:sssd it is not able to access previous
configs in /etc/sssd and the daemon fails with a permissions error.
There are a couple of contributing factors to this update failure:
1. the three-way merge for /etc files done by ostree does not preserve file
permissions, and does not update directory permissions. When /usr/etc/sssd
changed from 0700 to 0750, this was not reflected in /etc/sssd.
2. the ExecStartPre= statements in sssd.service are a bit optimistic. The chown
and chmod commands don't work with the current service settings (User= and
Group=). They currently fail but this is masked by the '-f' option.
I was able to fix this on my local system by (1) commenting out the
ExecStartPre= statements and (2) moving them to a dependent service that runs
as root. I guess this could also be accomplished with
PermissionsStartOnly=true.
Reproducible: Always
Steps to Reproduce:
1. build up a system that uses sssd (fully-populated /etc/sssd/sssd.conf)
2. stop sssd
3. chmod 0700 /etc/sssd
4. chown root:sssd /etc/sssd
5. try to start sssd
Actual Results:
sssd does not start, it is not able to correctly re-own the files and
directories it needs.
Here is the update report from the most recent ostree transaction
$ rpm-ostree db diff
ostree diff commit from: rollback deployment
(5796a4d9fbff9b2d0e28f34070e6958e0cfb5a1b3ab702fd1ed318ade3aa91ef)
ostree diff commit to: booted deployment
(f07128cd02dc40fbe578714f095140f44e5986f98902783d00bbd837a0ed06d6)
Upgraded:
cldr-emoji-annotation 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41
cldr-emoji-annotation-dtd 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41
ibus-typing-booster 2.27.1-1.fc41 -> 2.27.2-1.fc41
intel-vpl-gpu-rt 24.3.4-1.fc41 -> 24.4.4-1.fc41
libsss_certmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_nss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
libsss_sudo 2.10.0-2.fc41 -> 2.10.1-1.fc41
libva-intel-media-driver 24.3.4-1.fc41 -> 24.4.4-1.fc41
libvpl 1:2.13.0-1.fc41 -> 1:2.14.0-1.fc41
libxml2 2.12.8-2.fc41 -> 2.12.9-1.fc41
openjpeg 2.5.3-1.fc41 -> 2.5.3-2.fc41
setup 2.15.0-5.fc41 -> 2.15.0-8.fc41
sssd-client 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-common 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-kcm 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-krb5-common 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-ldap 2.10.0-2.fc41 -> 2.10.1-1.fc41
sssd-nfs-idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2334868
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2335130
Bug ID: 2335130
Summary: rpm -Vaq complains about wrong owner
Product: Fedora
Version: rawhide
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: pampelmuse(a)gmx.at
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
$ rpm -Vaq sssd-common
.....U... /etc/sssd
.....U... /etc/sssd/conf.d
.....U... /etc/sssd/pki
Reproducible: Always
Steps to Reproduce:
1. fresh rawhide installation
2. rpm -Vaq sssd-common
.....U... /etc/sssd
.....U... /etc/sssd/conf.d
.....U... /etc/sssd/pki
Actual Results:
wrong user
Expected Results:
no output
Maybe in spec file line 850 should be:
%attr(750,root,%{sssd_user}) %dir %{_sysconfdir}/sssd
%attr(750,root,%{sssd_user}) %dir %{_sysconfdir}/sssd/conf.d
%attr(750,root,%{sssd_user}) %dir %{_sysconfdir}/sssd/pki
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2335130
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2334087
Bug ID: 2334087
Summary: Capabilities related changes in
sssd-2.10.1-2.fc42.x86_64 break SSSD in containers
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Keywords: Regression
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: adelton(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
We are running the FreeIPA containers in GitHub Actions of
https://github.com/freeipa/freeipa-container. With sssd 2.10.0-3.fc42 packages
in Fedora rawhide the
https://github.com/freeipa/freeipa-container/actions/runs/12461283683 run
passed, with sssd 2.10.1-2.fc42 the
https://github.com/freeipa/freeipa-container/actions/runs/12489404343 started
to fail for rawhide, on all runtimes.
It is also easy to reproduce the issue locally with
tests/run-partial-tests.sh Dockerfile.fedora-rawhide
In /var/log/sssd/ldap_child.log I then see
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_log_process_caps]
(0x0100): Starting under ruid=285, euid=285, suid=285 : rgid=284, egid=284,
sgid=284
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_log_process_caps]
(0x0100): With following capabilities:
(nothing)
* (2024-12-25 16:41:58): [ldap_child[6484]] [main] (0x2000): context
initialized
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): total
buffer size: 56
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
command: Select principal
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
realm_str size: 12
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): got
realm_str: EXAMPLE.TEST
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
princ_str size: 16
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): got
princ_str: ipa.example.test
* (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000):
keytab_name size: 0
* (2024-12-25 16:41:58): [ldap_child[6484]] [sss_set_cap_effective]
(0x0400): cap_set_proc() failed: 1 ('Operation not permitted')
* (2024-12-25 16:41:58): [ldap_child[6484]] [select_principal_from_keytab]
(0x0200): trying to select the most appropriate principal from keytab
* (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab]
(0x0020): krb5_kt_start_seq_get failed: Permission denied
********************** BACKTRACE DUMP ENDS HERE
*********************************
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020):
krb5_kt_start_seq_get failed: Permission denied
* ... skipping repetitive backtrace ...
(2024-12-25 16:41:58): [ldap_child[6484]] [select_principal_from_keytab]
(0x0010): Failed to read keytab [FILE:/etc/krb5.keytab]: No suitable principal
found in keytab
I see capabilities and file permission related changes in
https://github.com/SSSD/sssd/commits/master/ and in
https://src.fedoraproject.org/rpms/sssd/c/80a939719c9fd4226e7eefc0d3d93c494….
I am able to workaround the issue by reverting the capabilities back to those I
see in sssd 2.10.0-2.fc41, namely
setcap cap_chown,cap_dac_read_search,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/krb5_child
setcap cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/ldap_child
and putting in /usr/lib/systemd/system/sssd.service.d/capabilities.conf with
[Service]
# In sssd-common-2.10.1-2.fc42.x86_64:
# CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH
# In sssd-common-2.10.0-2.fc41.x86_64:
CapabilityBoundingSet= CAP_CHOWN CAP_DAC_OVERRIDE CAP_SETGID CAP_SETUID
CAP_DAC_READ_SEARCH
Things are not proken outside of containers.
So it seems CAP_DAC_READ_SEARCH does not work (is not enough) in containerized
setups.
Reproducible: Always
Steps to Reproduce:
1. git clone https://github.com/freeipa/freeipa-container
2. cd freeipa-container/
3. # to get the state where (a planned) workaround is not present
git checkout d062ba708896d4e0e97d28ac2681097d935cde02
4. # enable a test which does not use the external volume, to minimize impact
of that containerization feature
sed -i 's/^## # test: systemd-container-ipa-server-install.sh/# test:
systemd-container-ipa-server-install.sh/' Dockerfile.fedora-rawhide
5. docker=podman tests/run-partial-tests.sh Dockerfile.fedora-rawhide
Actual Results:
● sssd.service loaded failed failed System Security Services Daemon
Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use
systemd-escape?).
Unit \xe2\x97\x8f.service could not be found.
Yeah, it's not a good error message. It tries to say that sssd.service is
failed.
Expected Results:
No error.
I understand Fedora does not primarily ship SSSD to work in containers, so this
is mostly a headsup that recent changes in the packaging don't seem quite
compatibly with current state of container runtimes.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2334087
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2333529
Bug ID: 2333529
Summary: unpacking of archive failed on file /var/lib/sss/mc:
cpio: chown failed
Product: Fedora
Version: 41
OS: Linux
Status: NEW
Component: sssd
Keywords: Upgrades
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: gregory.lee.bartholomew(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, pbrezina(a)redhat.com,
sbose(a)redhat.com, ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
While trying to upgrade a systemd-nspawn container from Fedora 40 to Fedora 41,
I received the following error:
Upgrading : sssd-common-2.10.0-2.fc41.x86_64
495/1223
error: unpacking of archive failed on file /var/lib/sss/mc: cpio: chown failed
- No data available
The container's /var/lib/sss/mc directory is ro-bind-mounted from the host
system similar to what is described in the last post (dated 11/05/16 14:29)
here:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.…
Reproducible: Always
Steps to Reproduce:
1. dnf upgrade --releasever=41
Actual Results:
Failed:
sssd-common-2.9.5-1.fc40.x86_64
sssd-common-2.10.0-2.fc41.x86_64
Error: Transaction failed
Expected Results:
Transaction succeeded
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2333529
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2305856
Bug ID: 2305856
Summary: sss_ssh_knownhosts man page does not contain
information about replacements
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: orion(a)nwra.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
ssh fails with:
******************************************************************************
Your system is configured to use the obsolete tool sss_ssh_knownhostsproxy.
Please read the sss_ssh_knownhosts(1) man page to learn about its replacement.
******************************************************************************
But man sss_ssh_knownhosts contains just:
SSS_SSH_KNOWNHOSTS(1) SSSD Manual pages
SSS_SSH_KNOWNHOSTS(1)
NAME
sss_ssh_knownhosts - get OpenSSH known hosts public keys
SYNOPSIS
sss_ssh_knownhosts [options] HOST
DESCRIPTION
sss_ssh_knownhosts acquires SSH public keys for host HOST and outputs
them in OpenSSH known_hosts key format (see the
“SSH_KNOWN_HOSTS FILE FORMAT” section of sshd(8) for more information).
ssh(1) can be configured to use sss_ssh_knownhosts for public key host
authentication using the “KnownHostsCommand”
option:
KnownHostsCommand /usr/bin/sss_ssh_knownhosts %H
Please refer to the ssh_config(5) man page for more details about this
option.
OPTIONS
-d,--domain DOMAIN
Search for host public keys in SSSD domain DOMAIN.
-?,--help
Display help message and exit.
EXIT STATUS
In case of successful execution, even if no key was found, 0 is
returned. 1 is returned in case of error.
SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5),
sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5),
sssd-sudo(5), sssd-session-recording(5), sss_cache(8),
sss_debuglevel(8), sss_obfuscate(8), sss_seed(8),
sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1),
sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8).
sss_rpcidmapd(5) sssd-systemtap(5)
AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/
SSSD 07/22/2024
SSS_SSH_KNOWNHOSTS(1)
and no information about a replacement or it being obsolete.
sssd-2.10.0~beta2-3.fc41.x86_64
Reproducible: Always
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2305856
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2319608
Bug ID: 2319608
Summary: python3-sssdconfig packs outdated .pyc files
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Keywords: Regression
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: jpazdziora(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
The /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/*.cpython-313.pyc
/usr/lib/files get regenerated when SSSDConfig module is used.
Reproducible: Always
Steps to Reproduce:
1. dnf install -y python3-sssdconfig
2. stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
3. python3 -c 'import SSSDConfig'
4. stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Actual Results:
[root@0890eef375bc /]# stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
File:
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Size: 57759 Blocks: 120 IO Block: 4096 regular file
Device: 0,109 Inode: 1226072 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-15 00:00:00.000000000 +0000
Modify: 2024-10-15 00:00:00.000000000 +0000
Change: 2024-10-18 09:46:42.433097566 +0000
Birth: 2024-10-18 09:46:42.432097551 +0000
[root@0890eef375bc /]# python3 -c 'import SSSDConfig'
[root@0890eef375bc /]# stat
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
File:
/usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc
Size: 59402 Blocks: 120 IO Block: 4096 regular file
Device: 0,109 Inode: 1196042 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-18 09:47:14.646592272 +0000
Modify: 2024-10-18 09:47:14.646592272 +0000
Change: 2024-10-18 09:47:14.646592272 +0000
Birth: 2024-10-18 09:47:14.646592272 +0000
Expected Results:
The Size and Modify time in the second stat run should match the output from
the first one.
First found by
https://github.com/freeipa/freeipa-container/actions/runs/11397511703/job/3….
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2319608
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2320042
Bug ID: 2320042
Summary: [abrt] sssd-tools: set_component():
source_files.py:73:set_component:OSError
Product: Fedora
Version: 41
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:a5a6dd78a14a8d86bce922d86636e1cb2da53ec6;VAR
IANT_ID=workstation;
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: maxi(a)maxiicodes.dev
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Version-Release number of selected component:
sssd-tools-2.10.0-1.fc41
Additional info:
reporter: libreport-2.17.15
kernel: 6.11.4-300.fc41.x86_64
cmdline: /usr/bin/python3 -sP /usr/libexec/sssd/sss_analyze error list
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/app.slice/app-cosmic-com.system76.CosmicAppList-3787.scope
uid: 1000
reason: source_files.py:73:set_component:OSError
executable: /usr/libexec/sssd/sss_analyze
type: Python3
package: sssd-tools-2.10.0-1.fc41
runlevel: N 5
exception_type: OSError
crash_function: set_component
interpreter: python3-3.13.0-1.fc41.x86_64
Truncated backtrace:
source_files.py:73:set_component:OSError
Traceback (most recent call last):
File "/usr/libexec/sssd/sss_analyze", line 5, in <module>
sss_analyze.run()
~~~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/sssd/sss_analyze.py", line 107, in
run
analyzer.main()
~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/sssd/sss_analyze.py", line 102, in
main
args.func(args)
~~~~~~~~~^^^^^^
File "/usr/lib/python3.13/site-packages/sssd/modules/error.py", line 52, in
print_error
source.set_component(component, False)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.13/site-packages/sssd/source_files.py", line 73, in
set_component
raise IOError
OSError
Local variables in innermost frame:
self: <sssd.source_files.Files object at 0x7f0cd2976e40>
component: <Component.BE: 3>
child: False
domains: []
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2320042
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…