Created attachment 242833 [details] /etc/pam.d/system I don't know whether this is a bug in the base system, or with ports … From <https://lists.freebsd.org/archives/freebsd-current/2023-June/003866.html>: > … Prior to reporting I had consolekit2 but not pam_xdg, with > /etc/pam.d/system content as shown below. I can't recall the origin of > this content. > > The problem … recurred a few times. > > It has not recurred since packages were upgraded on 15th June (the > second of two attachments). Fingers crossed. I spoke too soon. With the next boot of the system: % grep BOOT /var/log/messages | grep Jun\ 17 Jun 17 13:39:30 mowa219-gjp4-8570p-freebsd kernel: ---<<BOOT>>--- % ls -hln /var/run/user total 1 drwx------ 2 0 0 2B 19 May 02:16 0 drwx------ 7 1001 1001 7B 1 Jun 07:53 1001 %
Created attachment 242834 [details] The first of the two email attachments (In reply to Graham Perrin from comment #0)
Created attachment 242835 [details] The second of the two email attachments (In reply to Graham Perrin from comment #0)
Additional context, whilst list archives are unavailable (bug 272063) My UID number is 1002. From <https://markmail.org/message/amocmeuiepzm6onu>: % whoami grahamperrin % ls -dhln ~ drwxr-xr-x 143 1002 1002 240B 11 Jun 13:38 /home/grahamperrin % ls -hl /var/run/user total 1 drwx------ 2 root wheel 2B 19 May 02:16 0 drwx------ 7 bbsadmin-l bbsadmin-l 7B 1 Jun 07:53 1001 % From <http://markmail.org/message/e7wnq5gbgfbt25xm> by Jan Beich: > … /var/run/user/<UID> is managed by sysutils/consolekit2 or > sysutils/pam_xdg. In consolekit2 case the directory is created > (contents destroyed if already exists) on the first session of the > specific UID either via C API, DBus API, ck-launch-session(1) or > pam_ck_connector(8) and removed when the last session terminates. … – and: >> I recreated the directory. > > Can be automated via PAM e.g., > > # pkg install consolekit2 > # echo "session optional pam_ck_connector.so nox11" >>/etc/pam.d/system > # service dbus onestart > $ exit # log out on VT console to re-trigger PAM > > or > > …
Created attachment 242861 [details] messages from today's boot From <https://markmail.org/message/pikg6ra5cq52pecw>: > % ls -hln /etc/pam.d/system > -rw-r--r-- 1 0 0 540B 7 Oct 2022 /etc/pam.d/system > % All files in that directory were created more than four years ago (2018-12-13). /etc/pam.d/system is one of five files that were modified at the same time last year: % ls -hlnrt /etc/pam.d | grep 2022 -rw-r--r-- 1 0 0 498B 7 Oct 2022 other -rw-r--r-- 1 0 0 576B 7 Oct 2022 sshd -rw-r--r-- 1 0 0 540B 7 Oct 2022 system -rw-r--r-- 2 0 0 359B 7 Oct 2022 ftpd -rw-r--r-- 2 0 0 359B 7 Oct 2022 ftp % <https://markmail.org/message/pikg6ra5cq52pecw> also included output from uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n263493-4e8d558c9d1c-dirty: Sun Jun 11 06:22:01 BST 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400090 1400090 Towards diagnosis ================= With no recent change to /etc/pam.d/system, what might explain the recent randomness – the occasional non-creation of my /var/run/user/1002 directory? If it helps (beginning to give more thought to the background): * Login Screen (SDDM) behaviour is to automatically log in grahamperrin with session Plasma (X11) * my everyday use of CURRENT is very rarely GENERIC, nearly always GENERIC-NODEBUG * ZFS-related bug 271772 comment 17 reminds me that I began testing with GENERIC on 2023-06-11 * my first email about the absence of /var/run/user/1002 was later that day. Now, I wonder whether the trigger for this bug: * has existed for (much) longer than a week * was, somehow, previously suppressed by GENERIC-DEBUG. ---- From today's boot (see attachment), is the message below directly relevant? Jun 18 09:08:34 mowa219-gjp4-8570p-freebsd dbus-daemon[2486]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.7" (uid=1002 pid=3369 comm="/usr/local/lib/libexec/org_kde_powerdevil") interface="org.freedesktop.ConsoleKit.Manager" member="CanSuspendThenHibernate" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid=0 pid=3316 comm="/usr/local/sbin/console-kit-daemon --no-daemon") ---- This morning's packages were installed to a new boot environment (n263493-4e8d558c9d1c-c) that is activated but not yet booted. I'll boot in a few minutes … GENERIC-NODEBUG instead of GENERIC …
(In reply to Graham Perrin from comment #4, 09:28 UTC) > … I wonder whether the trigger for this bug: … was, somehow, > previously suppressed by GENERIC-DEBUG. … This seems unlikely. With GENERIC-DEBUG booted at 10:40, /var/run/user/1002 was missing when Plasma started. Log out failed, so I switched to ttyv1 then: service sddm stop ---- service sddm start (with automated log in) was enough for the directory to be created at 10:50. % uname -i GENERIC-NODEBUG % grep BOOT /var/log/messages | grep Jun\ 18 Jun 18 09:07:46 mowa219-gjp4-8570p-freebsd kernel: ---<<BOOT>>--- Jun 18 10:40:14 mowa219-gjp4-8570p-freebsd kernel: ---<<BOOT>>--- % ls -dhlnU /var/run/user/1002 drwx------ 9 1002 1002 15B 18 Jun 10:50 /var/run/user/1002 %
Where this bug was frequent enough to be an annoyance with 4e8d558c9d1c, the affected system has been completely free from symptoms (with many boots) following an upgrade to ab3e6234ab6e. <https://cgit.freebsd.org/src/log/?qt=range&q=4e8d558c9d1c...ab3e6234ab6e> Without attempting to pinpoint which commit(s) resolved this issue: * I assume that a bug in the base system prevented ports from working as expected in my case. % bectl list -c creation BE Active Mountpoint Space Created n262604-7ee4066db129-b - - 12.4G 2023-04-29 21:29 n263189-c2c9ac88c2bb-b - - 1.45G 2023-05-28 18:43 n263189-c2c9ac88c2bb-c - - 544M 2023-06-01 06:32 n263189-c2c9ac88c2bb-d - - 127M 2023-06-03 07:58 n263402-086e0149ae56-a - - 168M 2023-06-04 17:40 n263402-086e0149ae56-b - - 45.7M 2023-06-06 06:45 n263447-267411d164d4-a - - 55.5M 2023-06-09 04:50 n263447-267411d164d4-b - - 392M 2023-06-09 08:37 n263493-4e8d558c9d1c-a - - 289M 2023-06-11 08:38 n263493-4e8d558c9d1c-b - - 379M 2023-06-15 00:20 n263493-4e8d558c9d1c-c - - 108M 2023-06-18 09:25 n263630-ab3e6234ab6e-a - - 197M 2023-06-18 16:17 n263630-ab3e6234ab6e-b - - 277M 2023-06-20 22:34 n263630-ab3e6234ab6e-c - - 6.74G 2023-06-24 11:42 n263799-f81be7a8318b-a NR / 429G 2023-06-27 03:14 %
The symptom recurred today after I allowed net/citrix_ica (starting a remote desktop session) to make the local desktop environment – with /usr/local/bin/wfica as a part – completely unusable. After inadvertently bringing to the foreground something other than wfica: it's impossible to switch between applications, and so the wfica view of the remote desktop can not be used to apply the long-winded and fragile workaround that's normally necessary to avoid this blockage. In response: 1. Control-Alt-F2 2. service sddm stop 3. after SDDM stops, htop 4. observe processes relating to applications that ran before the blockage 5. be patient whilst all (or most) such processes end 6. reboot -r 7. use SDDM to start the desktop environment (Plasma) for user 1002 Expected: 8. existence of /var/run/user/1002 Actual result: 8. no such directory. As reboot -r did not result in what's required, I'll end this Plasma session and then restart the system.
(In reply to Graham Perrin ◐ from comment #7) > … As reboot -r did not result in what's required, I'll end this > Plasma session and then restart the system. A full restart did not result in what's required. After starting the next Plasma session: still, /var/run/user/1002 was non-existent. As root, I: 1. recreated the directory 2. changed its owner and group 3. changed its mode.
I have remarked a similar behaviour on my main workstation, running FreeBSD 13.2-STABLE, ssdm and KDE: - on the first launch, sddm starts and I can connect to KDE, but the splash screen is a bit long, KDE plasma displays several different errors, and the session is unusable; - then I just switch to a console, run `service sddm restart', and this second attempt is successful, the KDE session is usable. I also run KDE on my laptops, without encountering this problem.
(In reply to Thierry Thomas from comment #9) > - on the first launch, ... but the splash screen is a bit long, > I also run KDE on my laptops, without encountering this problem. Doesn't recent FreeBSD take an unusually long time to launch a program the first time? I am trying to isolate whether it is the exhausted HDD or FreeBSD that is causing the problem, but haven't done it yet :) ... and if this involves something called PAM, From what little I have read of man 5 pam.conf, it seems that the file should not exist in /etc/pam.conf. However, I still do not know anything about PAM :) I say this without knowing about it :)
(In reply to Thierry Thomas from comment #9) (In reply to Tatsuki Makino from comment #10) Please, let's remain focused. Does /var/run/user/ _not_ contain the directory that corresponds to your UID number?
(In reply to Graham Perrin ◐ from comment #11) In my case, there is no /var/run/user itself :) Because I am not using wayland. And if it is set while being seen https://docs.freebsd.org/en/books/handbook/wayland/ I feel that non-privileged users will not be able to create directories there. If the process that first creates the directory in /var/run/user is a non-privileged user, one step is required to make sure that /var/run/user has permissions like 01777 or rwxrwxrwt. Also, I can't find the part of the sddm source code that makes the directory there. If UID is 1001, then just logging in with sddm and starting a session will create that directory, is that correct?
(In reply to Graham Perrin from comment #0) > I don't know whether this is a bug in the base system, or with ports … <https://discord.com/channels/727023752348434432/1135028912661987339> relates to a case where /var/run/user/1000 does not exist.
Created attachment 244145 [details] Notes following an upgrade to packages and a restart of the OS For the past few weeks, after every sign in (to Plasma) I have habitually run: ls -dhlRn /var/run/user/1002 && ls -hlR /var/run/user/1002 /var/run/user/1002 existed, however: - the directory was old (2023-07-24, if I recall correctly) - IIRC it contained nothing other than /var/run/user/1002/gnupg and files therein. This morning, package upgrades included: > … consolekit2 upgraded: 1.2.5_1 -> 1.2.6_1 /var/run/user/1002 - is fresh, 11:03 this morning - has a broader range of contents – notes attached. <https://github.com/FreeBSD/freebsd-ports/commit/8c48a83684b3993c6c7d466edbd816602ee2bb4e> (2023-08-09) > sysutils/consolekit2: Update to 1.2.6 · freebsd/freebsd-ports@8c48a83 <https://github.com/FreeBSD/freebsd-ports/commit/503c15c3e1a5416017d83d66768e06b91f07f630> (2023-08-12) > sysutils/consolekit2: Switch to my fork. · freebsd/freebsd-ports@503c15c
Overcome by events, unless someone can pinpoint – with certainty – the commit (or commits) that fixed this. From bug 272886 comment 23, for net/remmina crashing: > … A lazy guess: maybe bug 272042, or something nearby, was the block. …