Unlocking the screen takes a long time after "Starting Fingerprint Authentication Daemon..."

Bug #1824855 reported by Steve Langasek
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
fprintd (Fedora)
Won't Fix
Undecided
fprintd (Ubuntu)
Won't Fix
Undecided
Unassigned
gnome-shell (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

When waking my laptop screen up at the lock screen, it takes a very long time to display the password prompt (definitely longer than 30s, possibly longer than 1m - I didn't time it). I notice that while waiting for the password prompt, the screen is showing a full list of (obfuscated) desktop notifications. After logging in, I used the gnome-shell interface to clear the notifications; then I locked my screen again, at which point hitting the space bar caused the password prompt to show up immediately.

So it looks like the time to display the password prompt might scale linearly with the number of notifications; which is not useful, because there is a finite number of (obfuscated!) notifications that will be displayed on the lock screen, and AFAIK you can't interact with them through the lock screen at all. So we shouldn't be wasting time processing (and presumably rendering) notifications that will never be visible.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: gdm3 3.32.0-1ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1
Uname: Linux 5.0.0-8-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Apr 15 09:58:23 2019
InstallationDate: Installed on 2010-09-24 (3125 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
SourcePackage: gdm3
UpgradeStatus: Upgraded to disco on 2019-04-11 (3 days ago)

Revision history for this message
In , araszka (araszka-redhat-bugs) wrote :

Description of problem:
After update to F27, I am facing issue during login to the system as a user. When a screen is locked (screen with the clock) and I hit any key to show password screen a system completely freeze for 15-20 seconds and after that time I am finally able to type my password.

Journalctl shows following error message:

Jan 16 08:19:36 araszka-rh gnome-shell[2622]: Failed to connect to Fprint service: Error calling StartServiceByName for net.reactivated.Fprint: Timeout was reached
Jan 16 08:19:36 araszka-rh dbus-daemon[981]: [system] Failed to activate service 'net.reactivated.Fprint': timed out (service_start_timeout=25000ms)

Version-Release number of selected component (if applicable):
libfprint-0.7.0-3.fc27.x86_64
fprintd-0.8.0-1.fc27.x86_64
fprintd-pam-0.8.0-1.fc27.x86_64

How reproducible:
always

Steps to Reproduce:
1. Lock a screen
2. Log in as a user
3.

Actual results:
System freeze for 15-20 second in the middle of lock screen and password screen

Expected results:
No delay

Additional info:
The bug is reproducible on my Lenovo Thinkpad T450s.

Revision history for this message
In , cfergeau (cfergeau-redhat-bugs) wrote :

Hitting that occasionally on my f27. Once it starts triggering, 'fprintd-list $username' triggers it too (it hangs for 25 seconds and dies with a service timeout rather than telling me "no device found).
Commenting out ProtectSystem=strict in /usr/lib/systemd/system/fprintd.service makes it go away

Revision history for this message
In , cfergeau (cfergeau-redhat-bugs) wrote :

Looking at fprintd strace/backtrace while it's stuck, I figured out it was trying to run statfs on some stale cifs mountpoints I had on my laptop. After unmounting them (and with an unmodified systemd service file), I no longer get hangs running 'fprintd-list $username'

Revision history for this message
In , cfergeau (cfergeau-redhat-bugs) wrote :
Download full text (3.7 KiB)

backtrace of fprintd while it's hung

#0 0x00007fbcdde84287 in statfs64 () from target:/lib64/libc.so.6
#1 0x00007fbcdde84309 in statvfs64 () from target:/lib64/libc.so.6
#2 0x00005627d4a130f7 in get_mount_flags (
    path=path@entry=0x5627d5f54710 "/media/synology/backup",
    flags=flags@entry=0x7ffc8e276778) at ../src/basic/mount-util.c:314
#3 0x00005627d4a1577a in bind_remount_recursive_with_mountinfo (ro=true,
    proc_self_mountinfo=<optimized out>, blacklist=<optimized out>,
    prefix=<optimized out>) at ../src/basic/mount-util.c:489
#4 make_read_only (proc_self_mountinfo=<optimized out>,
    blacklist=<optimized out>, m=<optimized out>)
    at ../src/core/namespace.c:803
#5 setup_namespace.constprop.59 (root_directory=<optimized out>,
    root_image=<optimized out>, ns_info=<optimized out>,
    read_write_paths=<optimized out>, read_only_paths=<optimized out>,
    inaccessible_paths=<optimized out>, bind_mounts=<optimized out>,
    n_bind_mounts=<optimized out>, tmp_dir=<optimized out>,
    var_tmp_dir=<optimized out>, protect_home=<optimized out>,
    protect_system=<optimized out>, mount_flags=<optimized out>,
    dissect_image_flags=<optimized out>) at ../src/core/namespace.c:1115
#6 0x00005627d4a17654 in apply_mount_namespace.lto_priv.263 (
    u=0x5627d610b5b0, command=0x5627d606cc40, context=0x5627d610b9e0,
    params=<optimized out>, runtime=<optimized out>)
    at ../src/core/execute.c:2002
#7 0x00005627d4a851f4 in exec_child.constprop.47 (unit=0x5627d610b5b0,
    command=0x5627d606cc40, context=<optimized out>, params=0x7ffc8e277180,
    runtime=<optimized out>, dcreds=<optimized out>, argv=<optimized out>,
    socket_fd=<optimized out>, named_iofds=<optimized out>,
    fds=<optimized out>, n_storage_fds=<optimized out>,
    n_socket_fds=<optimized out>, files_env=<optimized out>,
    user_lookup_fd=<optimized out>, exit_status=<optimized out>,
    error_message=<optimized out>) at ../src/core/execute.c:2626
#8 0x00005627d4ab5060 in exec_spawn (unit=<optimized out>,
    command=0x5627d606cc40, context=0x5627d610b9e0, params=<optimized out>,
    runtime=0x0, dcreds=0x5627d610bd28, ret=0x7ffc8e277170)
    at ../src/core/execute.c:2983
#9 0x00005627d4a5801f in service_spawn (s=s@entry=0x5627d610b5b0,
    c=<optimized out>, timeout=<optimized out>,
    flags=flags@entry=(EXEC_APPLY_PERMISSIONS | EXEC_APPLY_CHROOT | EXEC_APPLY_TTY_STDIN | EXEC_PASS_FDS | EXEC_SET_WATCHDOG), _pid=_pid@entry=0x7ffc8e2772c4)
    at ../src/core/service.c:1375
#10 0x00005627d4a60c6c in service_enter_start (s=s@entry=0x5627d610b5b0)
    at ../src/core/service.c:1817
#11 0x00005627d4a61098 in service_enter_start_pre (s=0x5627d610b5b0)
    at ../src/core/service.c:1886
#12 service_start.lto_priv.375 (u=0x5627d610b5b0) at ../src/core/service.c:2099
#13 0x00005627d4a9ad3c in unit_start (u=0x5627d610b5b0)
    at ../src/core/unit.c:1647
#14 job_perform_on_unit.lto_priv.870 (j=0x7ffc8e2773a0)
    at ../src/core/job.c:535
#15 0x00005627d4ab83d8 in job_run_and_invalidate (j=<optimized out>)
    at ../src/core/job.c:600
#16 manager_dispatch_run_queue.lto_priv.881 (source=<optimized out>,
    userdata=<optimized out>, userdata=<o...

Read more...

Revision history for this message
In , cfergeau (cfergeau-redhat-bugs) wrote :

Still an issue with f29

Revision history for this message
In , bnocera (bnocera-redhat-bugs) wrote :

I don't know why systemd is trying to bind remount the backup share on your NAS, but it probably (still) shouldn't be doing that.

Revision history for this message
Steve Langasek (vorlon) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Steve,

Next time the problem happens please send us the section of the journal (journalctl -b0) showing that long wake-up period.

Changed in gdm3 (Ubuntu):
status: New → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote :
Download full text (4.4 KiB)

After locking my screen and trying to log in, here's what I see in the log corresponding to a delay in the login prompt being shown.

I have not configured fingerprint authentication and never will, so I don't know why this is spawned or failing to spawn.

$ journalctl -b0 --since '2019-04-23 12:18' --no-pager
-- Logs begin at Sat 2019-02-02 22:33:11 PST, end at Tue 2019-04-23 12:19:26 PDT. --
Apr 23 12:18:41 virgil gnome-shell[4982]: JS WARNING: [resource:///org/gnome/gjs/modules/signals.js 128]: Too many arguments to method Clutter.Actor.destroy: expected 0, got 1
Apr 23 12:18:45 virgil dbus-daemon[2096]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' requested by ':1.360' (uid=1000 pid=4982 comm="/usr/bin/gnome-shell " label="unconfined")
Apr 23 12:18:45 virgil systemd[1]: Starting Fingerprint Authentication Daemon...
Apr 23 12:19:10 virgil dbus-daemon[2096]: [system] Failed to activate service 'net.reactivated.Fprint': timed out (service_start_timeout=25000ms)
Apr 23 12:19:10 virgil gnome-shell[4982]: Failed to connect to Fprint service: Error calling StartServiceByName for net.reactivated.Fprint: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'net.reactivated.Fprint': timed out (service_start_timeout=25000ms)
Apr 23 12:19:12 virgil gdm-password][23487]: pam_krb5(gdm-password:auth): user vorlon authenticated as [REDACTED]
Apr 23 12:19:12 virgil gdm-password][23487]: gkr-pam: unlocked login keyring
Apr 23 12:19:13 virgil NetworkManager[2098]: <info> [1556047153.6710] agent-manager: req[0x55dda12f3ae0, :1.360/org.gnome.Shell.NetworkAgent/1000]: agent registered
Apr 23 12:19:13 virgil /usr/lib/gdm3/gdm-x-session[4767]: dbus-daemon[4783]: [session uid=1000 pid=4783] Activating service name='org.gnome.Nautilus' requested by ':1.26' (uid=1000 pid=4982 comm="/usr/bin/gnome-shell " label="unconfined")
Apr 23 12:19:13 virgil /usr/lib/gdm3/gdm-x-session[4767]: dbus-daemon[4783]: [session uid=1000 pid=4783] Activating service name='org.freedesktop.FileManager1' requested by ':1.26' (uid=1000 pid=4982 comm="/usr/bin/gnome-shell " label="unconfined")
Apr 23 12:19:14 virgil /usr/lib/gdm3/gdm-x-session[4767]: dbus-daemon[4783]: [session uid=1000 pid=4783] Successfully activated service 'org.gnome.Nautilus'
Apr 23 12:19:14 virgil /usr/lib/gdm3/gdm-x-session[4767]: Failed to register: Unable to acquire bus name 'org.gnome.Nautilus'
Apr 23 12:19:14 virgil /usr/lib/gdm3/gdm-x-session[4767]: dbus-daemon[4783]: [session uid=1000 pid=4783] Activated service 'org.freedesktop.FileManager1' failed: Process org.freedesktop.FileManager1 exited with status 1
Apr 23 12:19:18 virgil gnome-shell[4982]: Couldn’t parse steam.desktop as a desktop file, will treat it as a regular file.
Apr 23 12:19:18 virgil gnome-shell[4982]: Error connecting to Nautilus
Apr 23 12:19:19 virgil gnome-shell[4982]: [AppIndicatorSupport-DEBUG] Using Brute-force mode for StatusNotifierItem :1.83/org/ayatana/NotificationItem/software_update_available
Apr 23 12:19:19 virgil gnome-shell[4982]: [AppIndicatorSupport-DEBUG] Registering StatusNotifierItem :1.83/org/ayatana/NotificationItem/software_update_available
Apr 23 12...

Read more...

Changed in gdm3 (Ubuntu):
status: Incomplete → Opinion
status: Opinion → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

Could you try starting fprintd manually and see if it displays any error?

Revision history for this message
Steve Langasek (vorlon) wrote :

There are no errors in the journal / systemctl status for fprintd aside from a timeout.

There is no output when running 'sudo /usr/lib/fprintd/fprintd' manually; but the command eventually exits.

This laptop does not have a fingerprint reader at all, and I have definitely never configured to authorize fingerprint-based unlocking of the system, so something should be figuring this out without launching (failing to launch) a separate fprintd daemon process.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes the "long delay" appears to be mostly the 25 seconds mentioned in:

Apr 23 12:18:45 virgil systemd[1]: Starting Fingerprint Authentication Daemon...
Apr 23 12:19:10 virgil dbus-daemon[2096]: [system] Failed to activate service 'net.reactivated.Fprint': timed out (service_start_timeout=25000ms)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Can you please try uninstalling 'fprintd'?

It sounds like all the detection, and the problem, is in there. Although the kernel might also be reporting some device nodes that it shouldn't.

Changed in fprintd (Ubuntu):
status: New → Incomplete
Changed in gdm3 (Ubuntu):
status: New → Incomplete
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Also, it is gnome-shell requesting fprintd via js/gdm/fingerprint.js

affects: gdm3 (Ubuntu) → gnome-shell (Ubuntu)
summary: - very long delay to display login prompt if there are a large number of
- uncleared desktop notifications
+ Unlocking the screen takes a long time after "Starting Fingerprint
+ Authentication Daemon..."
tags: added: performance
Changed in gnome-shell (Ubuntu):
status: Incomplete → New
Revision history for this message
In , rbu (rbu-redhat-bugs) wrote :

Same on f30.

Revision history for this message
In , mclayton (mclayton-redhat-bugs) wrote :

I'm also seeing this on F30. It just started yesterday for me.

Revision history for this message
In , mheck (mheck-redhat-bugs) wrote :

Seeing this problem immediately after "dnf system-upgrade" upgrade from F29 to F30:

Jun 07 16:23:59 * gnome-shell[8386]: Failed to connect to Fprint service: Error calling StartServiceByName for net.reactivated.Fprint: Timeout was reached
Jun 07 16:24:04 * dbus-broker-launch[1581]: avc: received policyload notice (seqno=2)
Jun 07 16:24:24 * gnome-shell[8386]: Failed to connect to Fprint service: Error calling StartServiceByName for net.reactivated.Fprint: Timeout was reached
Jun 07 16:24:49 * gnome-shell[8386]: Failed to connect to Fprint service: Error calling StartServiceByName for net.reactivated.Fprint: Timeout was reached
Jun 07 16:24:53 * gdm-password][15166]: gkr-pam: unlocked login keyring
Jun 07 16:24:53 * audit[15166]: USER_AUTH pid=15166 uid=0 auid=1000 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_succeed_if,pam_localuser,pam_unix,pam_gnome_keyring acct="myusername" exe="/usr/libexec/gdm-session-worker" hostname=myhostname.mysubdomain.mydomain.com addr=? terminal=/dev/tty2 res=success'
Jun 07 16:24:53 * audit[15166]: USER_ACCT pid=15166 uid=0 auid=1000 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="myusername" exe="/usr/libexec/gdm-session-worker" * addr=? terminal=/dev/tty2 res=success'
Jun 07 16:24:53 * audit[15166]: CRED_REFR pid=15166 uid=0 auid=1000 ses=2 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_unix,pam_gnome_keyring acct="myusername" exe="/usr/libexec/gdm-session-worker" hostname=myhostname.mysubdomain.mydomain.com addr=? terminal=/dev/tty2 res=success'
Jun 07 16:24:53 * gsd-power[8503]: up_client_get_on_battery: assertion 'UP_IS_CLIENT (client)' failed
Jun 07 16:24:53 * NetworkManager[1383]: <info> [1559949893.8365] agent-manager: req[0x5601e75a92f0, :1.306/org.gnome.Shell.NetworkAgent/1000]: agent registered

Saw a bunch of other problems, too, related to really slow sudo execution, most of which seemed to resolve by banging around on nsswitch.conf and sssd. Still not entirely sure what broke, but it's beginning to seem like at least one, possibly several, authentication-related services are trying to check things that have slow timeouts. Notably, the sudo-related problems happen even in runlevel 2-- that is, before the network is up-- which means all the people who are totally convinced it's some kind of network configuration problem are almost certainly wrong.

So, it's been hard to tell whether this is multiple problems with the same root cause, multiple unrelated problems, or something weirder.

What's frustrating is that variations on these problems, across multiple distros, seem to go back years and years. I suspect that the slow sudo issue that is NOT a network configuration issue, and the Gnome screen lock that doesn't display a password prompt for a long time, may both have the same root cause, and that this has been a seven year long, multi-project finger-pointing circle-jerk.

It would be nice to finally figure out WTF is so damn brittle that so many versions of so many distros keep breaking it.

Revision history for this message
In , mheck (mheck-redhat-bugs) wrote :

WORKAROUND:
For me,

sudo dnf remove fprintd

followed by a reboot resolves this-- as long as you don't actually need fingerprint login. (I certainly don't; this desktop doesn't even have the hardware for it, and never did.)

However, again, I suspect the actual culprit is a configuration problem, or bad multi-package interaction, involving a lower-level authentication system.

Nonetheless, this is worth a try, if you need a fix right now (which, for a bug like this, you probably do) and don't absolutely require fingerprint login. If you do, try reinstalling fprintd AFTER uninstalling and rebooting, and let us all know if it starts working again.

Revision history for this message
In , awilliam (awilliam-redhat-bugs) wrote :

I've seen this too, but from a long time ago (like Christophe), not starting with F30 (like Matt and Michael). I figured out that removing fprintd helped a while back.

Revision history for this message
Brian Murray (brian-murray) wrote :

I was wondering why it took so long to be able to unlock my laptop and it looks like it is this bug.

Jun 10 15:34:30 speedy dbus-daemon[989]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' requested by ':1.335' (uid=1000 pid=3119 comm="/usr/bin/gnome-shell " label="unconfined")
Jun 10 15:34:30 speedy systemd[1]: Starting Fingerprint Authentication Daemon...
Jun 10 15:34:55 speedy dbus-daemon[989]: [system] Failed to activate service 'net.reactivated.Fprint': timed out (service_start_timeout=25000ms)
Jun 10 15:34:55 speedy gnome-shell[3119]: Failed to connect to Fprint service: Error calling StartServiceByName for net.reactivated.Fprint: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'net.reactivated.Fprint

Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

What model machine are you seeing this bug on?

Revision history for this message
In , bnocera (bnocera-redhat-bugs) wrote :

*** Bug 1719180 has been marked as a duplicate of this bug. ***

Revision history for this message
Brian Murray (brian-murray) wrote : Re: [Bug 1824855] Re: Unlocking the screen takes a long time after "Starting Fingerprint Authentication Daemon..."

On Tue, Jun 11, 2019 at 02:07:14AM -0000, Daniel van Vugt wrote:
> What model machine are you seeing this bug on?

A Lenovo T450s, while it has a fingerprint reader I've no interest in
using it.

--
Brian Murray

Revision history for this message
In , samuel-rhbugs (samuel-rhbugs-redhat-bugs) wrote :

The strange part for me is if I run "systemctl start fprintd", it starts successfully and everything works until it gets automatically stopped again after a short delay. The problem is something specific to the way it's being started by other processes.

Revision history for this message
In , bnocera (bnocera-redhat-bugs) wrote :

(In reply to Christophe Fergeau from comment #3)
> backtrace of fprintd while it's hung
>
<snip>
> #19 0x00007fbcdda6f957 in sd_event_run (e=0x5627d5f75c10,
> timeout=18446744073709551615) at
> ../src/libsystemd/sd-event/sd-event.c:2690
> #20 0x00005627d4abc5a2 in manager_loop (m=0x5627d5f77520)
> at ../src/core/manager.c:2291
> #21 0x00005627d4a1ece1 in main (argc=5, argv=<optimized out>)
> at ../src/core/main.c:1937

This is clearly systemd, pre-fork. This code isn't from fprintd, and if stuff hangs before fprintd is even forked, I don't see how blaming it would help anything.

Revision history for this message
paraiko (paraiko) wrote :

I experience the same problem on my xps9360 (without fingerprint reader) after a clean install of ubuntu 19.10. I never experienced this problem on 18.04 and the earlier ubuntu versions I ran on this laptop. The delay is ~ 15-20 seconds and there are error messages in the Journactl log:

kt 03 11:18:55 paraiko-XPS-13-9360 systemd[1]: NetworkManager-dispatcher.service: Succeeded.
okt 03 11:19:07 paraiko-XPS-13-9360 dbus-daemon[851]: [system] Failed to activate service 'net.reactivated.Fprint': timed out (service_start_timeout=25000ms)
okt 03 11:19:07 paraiko-XPS-13-9360 gnome-shell[2403]: Failed to connect to Fprint service: Error calling StartServiceByName for net.reactivated.Fprint: Failed to activate service 'net.reactivated
okt 03 11:19:11 paraiko-XPS-13-9360 gdm-password][21463]: gkr-pam: unlocked login keyring.

There is also an intersting discussion on the fedora bugtracker about this problem which might be of interest.

Changed in fprintd (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
paraiko (paraiko) wrote :

I tested uninstalling fprintd, this indeed works around the problem.

Changed in fprintd (Fedora):
importance: Unknown → Undecided
status: Unknown → Confirmed
Revision history for this message
Klaus Doering (klausdoering) wrote :

I'm on Debian Buster, seeing the same behaviour (i.e. long timeout before being shown the login screen in GDM3). Before the upgrade from Stretch all worked as expected.
Uninstalling fprintd and libpam-fprintd solves the issue. But I like to have the fingerprint reader working ;-) This is on a Lenovo T430 laptop, fingerprint reader ID 147e:2020 Upek TouchChip Fingerprint Coprocessor.

So, I now downgraded both of those packages to version 0.8.0-2, and all works fine.
Note, I did not change the installed version of libfprint0, currently this is 0.8.2-3.
Installed version of systemd is 241-7~deb10u1.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thank you for reporting this bug to Ubuntu.
Ubuntu 19.04 (disco) reached end-of-life on January 23, 2020.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

Changed in gnome-shell (Ubuntu):
status: Confirmed → Won't Fix
Changed in fprintd (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 30 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Revision history for this message
In , d.bz-redhat (d.bz-redhat-redhat-bugs) wrote :

Encountering this issue on an up-to-date F32 :

systemd-245.7-1.fc32.x86_64
fprintd-1.90.1-1.fc32.x86_64

Revision history for this message
In , d.bz-redhat (d.bz-redhat-redhat-bugs) wrote :

Can this bz be reopened, or do I need to file a new bug report against F32 ?

Revision history for this message
In , d.bz-redhat (d.bz-redhat-redhat-bugs) wrote :

# strace -o /tmp/strace_fprintd-list.out -tt -f fprintd-list $USER
list_devices failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

strace_fprintd-list.out in attachment ; command hangs at
'2570072 10:44:27.207763 restart_syscall(<... resuming interrupted restart_syscall ...>'

Revision history for this message
In , d.bz-redhat (d.bz-redhat-redhat-bugs) wrote :

Created attachment 1712228
strace output of "fprintd-list $USER"

Revision history for this message
In , d.bz-redhat (d.bz-redhat-redhat-bugs) wrote :

$ strace -o /tmp/strace_su.out -tt -f su

strace_su.out in attachment ; command hangs at
'2571952 10:49:47.809422 ppoll([{fd=5, events=POLLIN}], 1, {tv_sec=24, tv_nsec=999930000}, NULL, 8'

Revision history for this message
In , d.bz-redhat (d.bz-redhat-redhat-bugs) wrote :

Created attachment 1712229
strace output of "su"

Revision history for this message
In , d.bz-redhat (d.bz-redhat-redhat-bugs) wrote :

Note : this behaviour usually starts to occur after a couple of days uptime (this is on a Dell XPS7390 2-in-1 with unrecognized fingerprint reader), for every action which requires authentication (su, sudo, virt-manager, screensaver unlocking).

journalctl error message (for the "su" example from comment#20) :

Aug 22 10:50:12 mymachine su[2571952]: pam_fprintd(su:auth): GetDevices failed: Connection timed out

Changed in fprintd (Fedora):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.