Michael wrote: > On Sunday, 26 October 2025 09:35:27 Greenwich Mean Time Dale wrote: >> Michael wrote: >>> On Sunday, 26 October 2025 06:54:35 Greenwich Mean Time Dale wrote: >>>> I read down to the part about Pam under Troubleshooting, close to the >>>> bottom. I was missing a file with a single line. The other file and >>>> line was there. This is what was missing, file name and contents. >>>> >>>> >>>> root@Gentoo-1 / # cat /etc/pam.d/elogind-user >>>> session optional pam_elogind.so >>>> root@Gentoo-1 / # >>> The package sys-auth/pambase installs a number of configuration files >>> under / etc/pam.d/, but I can't find an elogind-user on my system: >>> >>> ~ # find /etc/pam.d/ -name *login* >>> /etc/pam.d/login >>> /etc/pam.d/sddm-autologin >>> /etc/pam.d/system-local-login >>> /etc/pam.d/system-login >>> /etc/pam.d/system-remote-login >> This is mine, as root as you ran it. >> >> >> root@Gentoo-1 / # find /etc/pam.d/ -name *login* >> /etc/pam.d/system-remote-login >> /etc/pam.d/sddm-autologin >> /etc/pam.d/system-local-login >> /etc/pam.d/system-login >> /etc/pam.d/login >> /etc/pam.d/elogind-user >> root@Gentoo-1 / # >> >> >> Should I delete the file I created, since it didn't seem to fix it anyway? >> >>> The missing entry you identified is also not found on my system, note the >>> "-" sign in front of the second entry: >>> >>> ~ # grep pam_elogind.so -r /etc/pam.d/ >>> /etc/pam.d/sddm-greeter:session required pam_elogind.so >>> /etc/pam.d/system-login:-session optional pam_elogind.so >>> >>> I'm on sys-auth/pambase-20251013, which I recall introduced a couple of >>> changes in the pam config files. >> My output. >> >> >> root@Gentoo-1 / # grep pam_elogind.so -r /etc/pam.d/ >> /etc/pam.d/sddm-greeter:session required pam_elogind.so >> /etc/pam.d/system-login:-session optional pam_elogind.so >> /etc/pam.d/elogind-user:session optional pam_elogind.so >> root@Gentoo-1 / # >> >> >> Only difference is file I added. I'm on sys-auth/pambase-20251013 which >> is same as yours. >> >>>> I can't logout right now but that is next, when I can stop some things >>>> long enough to do so. This is the current output of XDG variables. >>>> Note the missing RUNTIME one. The file creations hasn't taken effect >>>> yet. >>>> >>>> >>>> root@Gentoo-1 / # env | grep "XDG" >>>> XDG_CONFIG_DIRS=/home/dale/.config/kdedefaults:/etc/xdg >>>> XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1 >>>> XDG_MENU_PREFIX=plasma- >>>> XDG_SEAT=seat0 >>>> XDG_SESSION_TYPE=x11 >>>> XDG_CURRENT_DESKTOP=KDE >>>> XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 >>>> XDG_SESSION_CLASS=user >>>> XDG_VTNR=7 >>>> XDG_SESSION_ID=37 >>>> XDG_DATA_DIRS=/usr/local/share:/usr/share >>>> root@Gentoo-1 / # >>> When I login in a VT, I see this: >>> >>> ~ $ ps axf | grep login >>> >>> 3718 ? S 0:00 elogind-daemon >>> 4084 tty1 Ss 0:00 /bin/login -- >>> 4221 tty1 S+ 0:00 \_ /bin/grep -E --color=auto login >>> >>> In Plasma session started via SDDM I see this: >>> >>> ~ $ ps axf | grep login >>> >>> 3718 ? S 0:00 elogind-daemon >>> 7525 pts/1 S+ 0:00 | | \_ /bin/grep -E -- >>> >>> color=auto login >>> >>> 4369 ? SLl 0:00 /usr/bin/ksecretd --pam-login 26 27 >>> >>> Is elogind running? >>> >>> ~ $ rc-service -v elogind status >>> * Executing: /usr/libexec/rc/sh/openrc-run.sh /usr/libexec/rc/sh/openrc- >>> >>> run.sh /etc/init.d/elogind status >>> >>> * status: started >>> >>> Does loginctl show your seat? >>> >>> NOTE: I'm running mostly stable arch on this system. >> I'm not sure what you mean by VT and Plasma exactly. I mostly use a >> Konsole for command line stuff, easy to copy/paste. I use a console >> after updates when I'm restarting services that have new config files. >> I logout of KDE for that as well. This is what I get while logged into >> KDE and while using Konsole. >> >> >> root@Gentoo-1 / # ps axf | grep login >> root 5811 0.0 0.0 6192 3216 ? S 02:56 0:00 >> elogind-daemon >> root 26144 0.0 0.0 6392 2268 pts/12 S+ 04:24 >> 0:00 | \_ grep --colour=auto -i -E login >> root@Gentoo-1 / # >> >> >> I checked, elogind and others are running. I wonder tho, dbus is under >> a section needed/wanted and I'm not sure if it was restarted or not when >> I went to boot runlevel. Should I logout, go to boot runlevel and >> restart dbus as well as elogind? Is there a particular order I should >> restart those? In other words should dbus be done first or elogind? >> >> Also, should I remove that file I created? If I can get my setup to >> match yours, then mine should work as well. >> >> Dale >> >> :-) :-) >> >> P. S. Going to save other reply for later. Trying to work on changes >> with two replies could get confusing. ;-) > There should be a more scientific approach to fixing this, but in absence of > wiser counsel you should remove the file you added. PAM and applications > which need it will add their own files and settings in there. You would only > need to add your own if you are setting up bespoke security access > requirements for some script or application. > > Then you can re-emerge sys-auth/elogind and sys-auth/pambase and reboot. If > this doesn't solve the problem I would also re-emerge sys-apps/shadow and sys- > apps/util-linux. Run dispatch-conf to update any changes to /etc/ config > files. > > HTH.
When there is a update to a pam config file, I always accept new. If something was to be added, I wouldn't have stopped it. I did remove the file I created. It didn't seem to help anyway. If I reemerge those packages, should I add the --noconfmem option to make sure the files are updated? I'm not sure that option is the right one. The one I'm looking for behaves as if no file already exists and updates like new or something like that. Could there be a config file that is the default in use in /usr somewhere? I know for some packages, if nothing exists in /etc, it defaults to one in /usr somewhere. Dale :-) :-)
