Launchpad has imported 14 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1534873.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2018-01-16T07:40:09+00:00 araszka 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/0 ------------------------------------------------------------------------ On 2018-01-17T14:38:36+00:00 cfergeau 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/1 ------------------------------------------------------------------------ On 2018-01-17T14:58:49+00:00 cfergeau 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' Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/2 ------------------------------------------------------------------------ On 2018-01-17T14:59:35+00:00 cfergeau wrote: 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=<optimized out>) at ../src/core/manager.c:1621 #17 0x00007fbcdda6f4ba in source_dispatch (s=s@entry=0x5627d5f75930) at ../src/libsystemd/sd-event/sd-event.c:2312 #18 0x00007fbcdda6f7da in sd_event_dispatch (e=e@entry=0x5627d5f75c10) at ../src/libsystemd/sd-event/sd-event.c:2631 #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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/3 ------------------------------------------------------------------------ On 2018-10-08T10:19:34+00:00 cfergeau wrote: Still an issue with f29 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/4 ------------------------------------------------------------------------ On 2018-10-08T11:44:31+00:00 bnocera 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/5 ------------------------------------------------------------------------ On 2019-06-04T07:16:42+00:00 rbu wrote: Same on f30. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/15 ------------------------------------------------------------------------ On 2019-06-05T15:00:14+00:00 mclayton wrote: I'm also seeing this on F30. It just started yesterday for me. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/16 ------------------------------------------------------------------------ On 2019-06-07T23:44:42+00:00 mheck 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/17 ------------------------------------------------------------------------ On 2019-06-08T00:05:24+00:00 mheck 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/18 ------------------------------------------------------------------------ On 2019-06-08T00:50:12+00:00 awilliam 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/19 ------------------------------------------------------------------------ On 2019-06-11T11:22:40+00:00 bnocera wrote: *** Bug 1719180 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/22 ------------------------------------------------------------------------ On 2019-06-26T05:51:00+00:00 samuel-rhbugs 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/24 ------------------------------------------------------------------------ On 2019-08-19T10:30:31+00:00 bnocera 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- shell/+bug/1824855/comments/25 ** Changed in: fprintd (Fedora) Status: Unknown => Confirmed ** Changed in: fprintd (Fedora) Importance: Unknown => Undecided -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1824855 Title: Unlocking the screen takes a long time after "Starting Fingerprint Authentication Daemon..." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fprintd/+bug/1824855/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
