Chris SiebenmannI am sure I will not regret upgrading my eccentric office desktop from Fedora 42 to Fedora 43 through a live dnf upgrade the day before a long weekend.
(Well, I have to do it sometime, I've sat on this far too long.)
This is my unsurprised face that I am now gluing one local program back together because the old version broke in the upgrade. I hope that this is not an omen that the old old version of this program that I run at home will also break in the upgrade, because that would annoy me deeply. (I like the old old version better than the old version.)
On the negative side, gluing the local program back together took a lot more work than I expected at the start. On the slightly more positive side, apparently the old version was quietly broken too and I just didn't notice. Yay for actually testing things.
(In theory I could have done some of my stuff with local CSS hacks but in practice I'm building from source anyway so I already have a chainsaw running.)
I impulsively updated my home Fedora desktop to Fedora 43 this evening and the old old version of the program (Liferea) broke, which makes me unhappy because I liked the old UI better than the current one. On the other hand the old (old) version was very old in the tooth by now and being up to date is probably good for me.
I am going to be hacking the new UI, though (which, as usual, is HTML + CSS under the hood).
WHAT THE HELL. My home Fedora desktop (now Fedora 43) is refusing to start a 'systemd --user' daemon/session/etc when I log in on the tty/vty console. SSH in and the 'systemd --user' stuff starts (and then the console session can find it). This breaks sound, among other unpleasant things. At work this works, and I can't see any obvious /etc/pam.d differences.
This is apparently happening because direct console tty logins are now 'user-light' sessions which don't trigger things. On my work desktop, I run something from cron as an @ reboot thing that triggers user service manager startup but at home I don't so I get screwed.
Ah. I believe this is ancient sins coming back to haunt me. Many decades ago my UID was set to '19', a decision that has in no way haunted my Unix machines ever since. Low UIDs are by default system users and in systemd v258+, system users deliberately get a 'user-light' session.
Well. System users in systemd v258+ get a 'user-light' session if and only if they log in on a tty, if they log in via SSH they apparently get a 'user' session. I in no way understand this or how to manipulate this.
It turns out that I'm wrong about one detail of my work Fedora machine. It does open some sort of early session for me when it boots, but it's not from a crontab at-reboot entry and not from any 'User=' .service setting I can see. Loginctl says it's a 'manager-early' class with no seat associated.
All of this is rather charmingly opaque, and some of our users at work have low UIDs too (although none as low as 19, that was a Special Choice).
grawity@cks That's the PAM session for systemd --user *itself* (its [email protected] has a PAMName=), which is why it has no seat.
Systemd by default honors SYS_UID_MAX in login.defs for the system/non-system UID boundary, unless Fedora disables that feature at build time...
@grawity Something is starting the session, though, which turns out to be that at some point loginctl's 'linger' was turned on for me at work¹, so a session starts during boot and sticks around perpetually. Unfortunately, I don't think login.defs can help me because of how it works. (I can't set the maximum system UID to 18, things would explode.)