Damn, I found out I can't really use #AlpineLinux yet (at least as a daily driver) because I have the misfortune of the only laptop within my budget at the time that was powerful enough for my use case having an #Nvidia #GPU. I'm getting really sick of reasons piling on to hate Nvidia, especially given there is basically nothing Alpine can do. It's literally just the most performant, actually supported by the vendor drivers depend on a C compiler that a large part of the whole point of Alpine is to avoid dependency on.

I might try to just install glibc temporarily so I can manually install the drivers when I have time to deal with the scenario where it's not that simple. Until then, I'll see if there's a #systemd free version of #ArchLinux to try other than #Artix (the reason for not using them is beyond the scope of this post)

Manchmal gibt es gute Gründe für eine ganz eigene Linux-Schulung! Deshalb bieten wir neben unserem regulären Kursprogramm die Möglichkeit, mit uns Inhouse-Schulungen abzustimmen. Egal, ob Dauer, inhaltlicher Schwerpunkt, Ort oder Termin – für Dein Team individualisieren wir bei Bedarf unser Kursangebot.

In diesem Jahr haben unsere Profis z.B. ganze Teams zu den Themen Linux Admin Grundlagen, #Docker & #systemd geschult. Ihr braucht ein Know-how-Update? Wir beraten gerne:
https://www.heinlein-support.de/akademie/inhouse-schulungen

@agowa338 I don't see how this is a #systemd issue. At least on Debian, `/lib/systemd/system/getty@.service` does not come from any SystemD package (in fact, it doesn't come from any package at all), so it sounds more like a distro misconfiguration.

What could be a SystemD issue is not having the right support for getty, which could have 'forced' distros to use `Type=idle` instead of something more adecuate. Or maybe the dependency thing, but from your description, it's not clear what you mean.

This turns out to be something in between a #systemd bug/oversight or a #linux kernel bug.

As console-getty.service is "TTYPath=/dev/console"
and getty@tty1.service is "TTYPath=/dev/tty1".

It appears systemd didn't expect both devices to be referencing the same tty and the kernel lets them appear as independent files instead of the one being a symlink to the other within the #devtmpfs. They even show up with different inode numbers.

Correction, the side effect in question is from #systemd, when I create a dummy getty@tty1.service with this an
ExecStart=-/bin/sh -c 'trap "exit 0" SIGTERM; while true; do sleep 1; done'

a following start of sddm.service also succeeds. So #agetty is not who causes this surprisingly hard to identify side effect.
(tested together with having set all of the same flags using stty manually beforehand)

Anyone a clue what else changes on a system just through "systemctl start getty@tty1.service; sleep 10s; systemctl stop getty@tty1.service" that wouldn't show up within "stty -aF /dev/tty1"?

#tty #agetty #systemd

Anyone know how to make one #systemd unit depend upon another but in a way that ensures that the unit(s) it depends upon have already been started even though they're of Type=idle?

Funnily sddm stops the getty@tty1.service as part of its startup shortly after again too. So I don't even know why it is needed to begin with...

Another day, another issue related to #systemd
Figured out why #sddm didn't work when forced into wayland mode without an xserver (or when the x11 configuration is missing).
While gdm (which defaults to wayland) "just works".

The sddm developers are currently struggling with an #systemd issue. Apparently sddm needs getty@tty1.service to have completed execution. But because it is of "Type=idle" the sddm service starts too soon and crashes...

Funnily the systemd docs don't cover this...

Nice #howto #article on how to clear #systemd journal #logs

https://linuxhandbook.com/clear-systemd-journal-logs/

@foolishowl @azonenberg @mcc @dalias @whitequark @becomethewaifu

Heh! It was, it turns out, and the only response stated to send it back to being a #systemd bug.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086055

#Debian policy ping-pong. (-:

#systemd me rappèle la tumeur que j'avais dans le cou : ça ne cessait de grossir en prenant la place de tout le reste.

#linux #init #InitFreedom

#til the bad way that, at least on #debian unstable, launching a long running process in #screen (but #tmux and nohup and other seem to also be impacted) is not enough to survive a session logout, seemingly because #systemd changed something more than 6y ago and now you have to mark users as linger-able to keep the feature working. Stay tuned.

#SysAdmin #Linux

So figured out why #systemd is overwriting the path for all applications started from the desktop.
It does this because @kde Plasma's KRunner tells it to.
And why does it do that? Cause it itself has the incorrect environment vars as I recently replaced #sddm with #gdm when I swapped my GPU for an #IntelArc A380 and it just failed to start with it (and I was too lazy to actually debug and troubleshoot it).

But why this issue hits now after the last update and not before? No idea...

Is there some structured way to learn "all about #systemd"? (deep dive, I mean, not the basics, but all of the inner workings and all of the advanced stuff)
Any recommendations?

Tbh my main issue with #systemd is that it is so hard to debug because there is always something more that I don't (yet) know anything about.
init.d may be shitty and have its bugs, but it is stupidly simple and after you learned it once you basically know how to handle it.

With systemd almost every problem turns into multiple days of research and discovery.

This doesn't mean that one is better than the other, but gosh it for sure is annoying 😅

Another day, another wird issue with #systemd.

Why exactly does it overwrite almost all Environment variables within transient user service units that are automatically created when the KDE Plasma gui starts an application?

And why does bash not execute the profile script to overwrite the passed in "PATH" value?

Also funny remmina has an autostart unit, the first time it starts it has the correct environment vars, but when you close and reopen it it now has the wrong ones because of this.

@foolishowl @azonenberg @mcc @dalias @whitequark @becomethewaifu

Declared a "wontfix" bug in #Debian back in 2024.

I wonder whether it did get carried over to a policy bug.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370#21

#systemd

@mcc @dalias @whitequark @becomethewaifu

It didn't replace van Smoorenberg init+rc. It replaced Upstart. The existence of Upstart is the part of history that many people forget or gloss over.

van Smoorenberg init+rc always was a straw man. The Debian committee included it, but everyone acknowledged at the time that the main contenders were systemd, Upstart, and OpenRC.

#systemd #Upstart

@mcc @dalias @whitequark @becomethewaifu

Changing compiler is not the problem. But changing the standard library becomes one. systemd gained problems with #musl because of this.

#systemd

https://tty0.social/@JdeBP/114646325165347305

This mornings "lets do some quick updates and reboot while staying in the bed"-session got me out of the bed, because the server did not come online again.

Turns out: If you mount thin-provisioned #LVM logical volumes with #fstab you need thin-provisioning-tools, otherwise the #systemd unit fails during boot. And that package is not a dependency, only recommended on #Debian #Trixie and for some reason wasn't installed on my system.

Longer version: https://swagspace.org/blog/lvm-thin-provisioning-tools/