Have to Enter Password Twice to Sign In (excluding LUKS)

Ask Fedora
1

After upgrading from F42 - > F44, I have to enter my password twice at LightDM (I think it’s called). The first time always fails and drops me back at LightDM, the second time always works. I do see some interesting logs in the journal:

May 29 09:50:47 lane-pc systemd[1]: user@1000.service: Failed to spawn executor: Device or resource busy
May 29 09:50:47 lane-pc systemd[1]: user@1000.service: Failed to spawn 'start' task: Device or resource busy
May 29 09:50:47 lane-pc systemd[1]: user@1000.service: Failed with result 'resources'.
May 29 09:50:47 lane-pc systemd[1]: Failed to start user@1000.service - User Manager for UID 1000.
...
...
May 29 09:50:47 lane-pc gnome-session-i[4309]: Starting GNOME session target: gnome-session@gnome.target
May 29 09:50:47 lane-pc gnome-session-i[4309]: Failed to start unit gnome-session@gnome.target: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
...
...
May 29 09:50:47 lane-pc systemd[1]: Started systemd-coredump@0-1-4397_45125-0.service - Process Core Dump (PID 4397/UID 0).
May 29 09:50:47 lane-pc audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@0-1-4397_45125-0 comm="systemd" exe="/usr/lib/systemd/system>
May 29 09:50:48 lane-pc systemd-coredump[4398]: [🡕] Process 4309 (gnome-session-i) of user 1000 dumped core.
                                                
                                                Module /usr/libexec/gnome-session-init-worker from rpm gnome-session-50.0-1.fc44.x86_64
                                                Module libbrotlicommon.so.1 from rpm brotli-1.2.0-3.fc44.x86_64
                                                Module libgraphite2.so.3 from rpm graphite2-1.3.14-20.fc44.x86_64
                                                Module libbrotlidec.so.1 from rpm brotli-1.2.0-3.fc44.x86_64
                                                Module libharfbuzz.so.0 from rpm harfbuzz-14.1.0-2.fc44.x86_64
                                                Module libpng16.so.16 from rpm libpng-1.6.58-1.fc44.x86_64
                                                Module libbz2.so.1 from rpm bzip2-1.0.8-23.fc44.x86_64
                                                Module libfreetype.so.6 from rpm freetype-2.14.3-1.fc44.x86_64
                                                Module liblzma.so.5 from rpm xz-5.8.2-2.fc44.x86_64
                                                Module libfontconfig.so.1 from rpm fontconfig-2.17.0-4.fc44.x86_64
                                                Module liblcms2.so.2 from rpm lcms2-2.16-7.fc44.x86_64
                                                Module libxml2.so.2 from rpm libxml2-2.12.10-6.fc44.x86_64
                                                Module libglycin-2.so.0 from rpm glycin-2.1.1-1.fc44.x86_64
                                                Module libblkid.so.1 from rpm util-linux-2.41.4-8.fc44.x86_64
                                                Module libseccomp.so.2 from rpm libseccomp-2.6.0-3.fc44.x86_64
                                                Module libudev.so.1 from rpm systemd-259.5-1.fc44.x86_64
                                                Module libxkbregistry.so.0 from rpm libxkbcommon-1.13.1-2.fc44.x86_64
                                                Module libsystemd.so.0 from rpm systemd-259.5-1.fc44.x86_64
                                                Module libgdk_pixbuf-2.0.so.0 from rpm gdk-pixbuf2-2.44.4-2.fc44.x86_64
                                                Module libpcre2-8.so.0 from rpm pcre2-10.47-1.fc44.1.x86_64
                                                Module libffi.so.8 from rpm libffi-3.5.2-2.fc44.x86_64
                                                Module libselinux.so.1 from rpm libselinux-3.10-1.fc44.x86_64
                                                Module libmount.so.1 from rpm util-linux-2.41.4-8.fc44.x86_64
                                                Module libz.so.1 from rpm zlib-ng-2.3.3-3.fc44.x86_64
                                                Module libgmodule-2.0.so.0 from rpm glib2-2.88.1-1.fc44.x86_64
                                                Module libgnome-desktop-4.so.2 from rpm gnome-desktop3-44.5-1.fc44.x86_64
                                                Module libglib-2.0.so.0 from rpm glib2-2.88.1-1.fc44.x86_64
                                                Module libgobject-2.0.so.0 from rpm glib2-2.88.1-1.fc44.x86_64
                                                Module libgio-2.0.so.0 from rpm glib2-2.88.1-1.fc44.x86_64
                                                Stack trace of thread 4309:
                                                #0  0x00007f0f180a180c __pthread_kill_implementation (libc.so.6 + 0x7580c)
                                                #1  0x00007f0f1804648e raise (libc.so.6 + 0x1a48e)
                                                #2  0x00007f0f1802d7b3 abort (libc.so.6 + 0x17b3)
                                                #3  0x00007f0f18278471 _g_log_abort.lto_priv.0.cold (libglib-2.0.so.0 + 0x2471)
                                                #4  0x00007f0f182c5020 g_log_default_handler (libglib-2.0.so.0 + 0x4f020)
                                                #5  0x00007f0f182c5343 g_logv (libglib-2.0.so.0 + 0x4f343)
                                                #6  0x00007f0f182c56a3 g_log (libglib-2.0.so.0 + 0x4f6a3)
                                                #7  0x000055b12d28913b main (/usr/libexec/gnome-session-init-worker + 0x113b)
                                                #8  0x00007f0f1802f681 __libc_start_call_main (libc.so.6 + 0x3681)
                                                #9  0x00007f0f1802f798 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3798)
                                                #10 0x000055b12d289575 _start (/usr/libexec/gnome-session-init-worker + 0x1575)
                                                Stack trace of thread 4394:
                                                #0  0x00007f0f181216bd syscall (libc.so.6 + 0xf56bd)
                                                #1  0x00007f0f182ee4eb g_cond_wait (libglib-2.0.so.0 + 0x784eb)
                                                #2  0x00007f0f1828058c g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0xa58c)
                                                #3  0x00007f0f182f4d64 g_thread_pool_spawn_thread (libglib-2.0.so.0 + 0x7ed64)
                                                #4  0x00007f0f182f3d12 g_thread_proxy (libglib-2.0.so.0 + 0x7dd12)
                                                #5  0x00007f0f1809f759 start_thread (libc.so.6 + 0x73759)
                                                #6  0x00007f0f1812390c __clone3 (libc.so.6 + 0xf790c)
                                                
                                                Stack trace of thread 4395:
                                                #0  0x00007f0f180a7e32 __syscall_cancel_arch (libc.so.6 + 0x7be32)
                                                #1  0x00007f0f1809c06c __internal_syscall_cancel (libc.so.6 + 0x7006c)
                                                #2  0x00007f0f1809c0b4 __syscall_cancel (libc.so.6 + 0x700b4)
                                                #3  0x00007f0f18116766 ppoll (libc.so.6 + 0xea766)
                                                #4  0x00007f0f182be125 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48125)
                                                #5  0x00007f0f182be1e3 g_main_context_iteration (libglib-2.0.so.0 + 0x481e3)
                                                #6  0x00007f0f182be231 glib_worker_main (libglib-2.0.so.0 + 0x48231)
                                                #7  0x00007f0f182f3d12 g_thread_proxy (libglib-2.0.so.0 + 0x7dd12)
                                                #8  0x00007f0f1809f759 start_thread (libc.so.6 + 0x73759)
                                                #9  0x00007f0f1812390c __clone3 (libc.so.6 + 0xf790c)
                                                
                                                Stack trace of thread 4396:
                                                #0  0x00007f0f180a7e32 __syscall_cancel_arch (libc.so.6 + 0x7be32)
                                                #1  0x00007f0f1809c06c __internal_syscall_cancel (libc.so.6 + 0x7006c)
                                                #2  0x00007f0f1809c0b4 __syscall_cancel (libc.so.6 + 0x700b4)
                                                #3  0x00007f0f18116766 ppoll (libc.so.6 + 0xea766)
                                                #4  0x00007f0f182be125 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48125)
                                                #5  0x00007f0f182be2e7 g_main_loop_run (libglib-2.0.so.0 + 0x482e7)
                                                #6  0x00007f0f185306c2 gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0xf76c2)
                                                #7  0x00007f0f182f3d12 g_thread_proxy (libglib-2.0.so.0 + 0x7dd12)
                                                #8  0x00007f0f1809f759 start_thread (libc.so.6 + 0x73759)
                                                #9  0x00007f0f1812390c __clone3 (libc.so.6 + 0xf790c)
                                                ELF object binary architecture: AMD x86-64
May 29 09:50:48 lane-pc systemd[1]: systemd-coredump@0-1-4397_45125-0.service: Deactivated successfully.
2

Any updates on this? I can provide more information as needed. I’ve been updating each day hoping something would fix it, but I still have to sign in twice every time I boot up.

3

“Device or resource busy” suggests that some file or mountpoint was not closed/released from a previous session. I’m guessing that you don’t see this problem if you completely shutdown (not hibernate) your PC and power it back on?

Otherwise, maybe it could be a device being really slow, but the timestamps that you shared are not showing any large gaps. Does the system seem to hang for a bit before the first error message that you shared appears?

I think whatever the problem is, it is happening just before the logs that you shared.

Also, are you really using LightDM to start GNOME? Is there a reason you are not using GDM?

4

It may well be GDM, I may have misspoken there. The note about “Device or resource busy” is interesting. I didn’t think about it before, but I do have an sshfs automount set up to start at login. It wasn’t an issue before upgrading from 42 - > 44, but I’ll investigate that more closely this weekend. Thanks for your help!

5

Finally had a chance to test my automounts. I disabled my sshfs and syncthing systemd units that were set to start at user login. However, I’m still having the same problem.

To answer one of your questions I missed: I only have this issue when booting from a restart or complete shutdown. If I sign out/in or lock/unlock, I do not have the problem. When I type in my password the first time, it kicks me back to the login screen after only 1 or 2 seconds.

6

Try setting a static hostname.

7

A static hostname on the device itself? I believe I already have that:


lrussell@lane-pc:~$ cat /etc/hostname
lane-pc
8

Any other thoughts here? This has still been a problem after recent updates. I haven’t been able glean anything else from the journal.

9

I think we need more information about what is failing. You might try signing in on another VT with the root account, switching back to GDM, try to sign in with your normal user and let it fail, switch back to the VT that you have signed in with root and then run systemctl status user@1000.service. Maybe it will show the exact command that caused the service to fail?

FWIW, the only resource limit I see that stands out to me is TasksMax=33% which is set in /usr/lib/systemd/system/user-.slice.d/10-defaults.conf:

$ cat /usr/lib/systemd/system/user-.slice.d/10-defaults.conf 
#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=User Slice of UID %j
Documentation=man:user@.service(5)
StopWhenUnneeded=yes

[Slice]
TasksMax=33%

According to the man pages, that setting is relative to the value of DefaultTasksMax=:

$ man systemd-system.conf | sed -n '/^\s*DefaultTasksMax=/,/^$/ p'
       DefaultTasksMax=
           Configure the default value for the per-unit TasksMax= setting. See systemd.resource-control(5) for details. This setting applies to all unit types that support resource control settings, with the
           exception of slice units. Defaults to 15% of the minimum of kernel.pid_max=, kernel.threads-max= and root cgroup pids.max. Kernel has a default value for kernel.pid_max= and an algorithm of counting
           in case of more than 32 cores. For example, with the default kernel.pid_max=, DefaultTasksMax= defaults to 4915, but might be greater in other systems or smaller in OS containers.

Are you trying to run the GNOME session in a container or some other environment where the calculated value for TasksMax might be coming out unusually low?

Edit: Never mind. The TasksMax resource limit wouldn’t give a “Resource Busy” error. I think it must be something else.

10

I was able to grab the output of systemctl status user@1000.service after the failed login attempt:

Jul 18 06:37:18 lane-pc systemd[1]: user@1000.service: Failed to spawn executor: No such file or directory
Jul 18 06:37:18 lane-pc systemd[1]: user@1000.service: Failed to spawn 'start' task: No such file or directory
Jul 18 06:37:18 lane-pc systemd[1]: user@1000.service: Failed with result 'resources'.
Jul 18 06:37:18 lane-pc systemd[1]: Failed to start user@1000.service - User Manager for UID 1000.
Jul 18 06:37:23 lane-pc systemd[1]: Starting user@1000.service - User Manager for UID 1000...

The first four logs show the failed login attempt, followed by the successful login attempt 5 seconds later (I left out a lot from the successful attempt for brevity).

It looks similar to my initial post, although instead of saying Device or resource busy, it is now showing No such file or directory, which is an interesting difference.

11

Is “start” the name of an executable on your system somewhere? Is it located under an automatic mountpoint or network share or something like that?

Edit: I think it must be referring to the ExecStart line in the user@.service, but that is just the systemd command. There is no way that that could be unavailable.

$ grep ExecStart /usr/lib/systemd/system/user@.service
ExecStart=/usr/lib/systemd/systemd --user

You might try adding systemd.log_level=debug to your kernel parameters temporarily and see if you can get more info in the logs about what is failing that way.

12

Aha, the systemd.log_level=debug recommendation got me to the answer. I was seeing several messages referring to something I had set up a while back to quash a naughty app that kept memory leaking and causing full system lockup.

I no longer have to enter my password twice. Removing the following entries from my root crontab fixed the issue:

  @reboot                               cgcreate -t lrussell:lrussell -a lrussell:lrussell -g memory:user.slice/user-1000.slice/user@1000.service/stationeers
  @reboot                               cgset -r memory.max=17179869184 user.slice/user-1000.slice/user@1000.service/stationeers
  @reboot                               cgset -r memory.swap.max=0 user.slice/user-1000.slice/user@1000.service/stationeers

Thanks for all your assistance!