[blibble]

I only use debian

pulseaudio I had to fight every single day, with my "exotic" setup of one set of speakers and a headset

with pipewire, I've never had to even touch it

systemd: yesterday I had a network service on one machine not start up because the IP it was trying to bind to wasn't available yet

the dependencies for the .service file didn't/can't express the networking semantics correctly

this isn't some hacked up .service file I made, it's that from an extremely popular package from a very popular distro

(yeah I know, use a socket activated service......... more tight coupling to the garbage software)

the day before that I had a service fail to start because the wall clock was shifted by systemd-timesyncd during startup, and then the startup timeout fired because the clock advanced more than the timeout

then the week before that I had a load of stuff start before the time was synced, because chrony has some weird interactions with time-sync.target

it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc

for what? to save maybe a second of boot time

if the distro maintainers don't understand the systemd dependency model after a decade then it's unfit for purpose

[jorvi]

> it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc

This gave me a good chuckle. Systemd literally was created to solve the awful race conditions and non-determinism in other init systems. And it has done a tremendous job at it. Hence the litany of options to ensure correct order and execution: https://www.freedesktop.org/software/systemd/man/latest/syst...

And outside of esoteric setups I haven't ever encountered the problems you mentioned with service files.

[direwolf20]

systemd was created to solve the problems of a directory full of shell scripts. A single shell script has completely different problems. And traditional init uses inittab, which is not /etc/init.d, and works more like runit.

runit's approach is to just keep trying to start the shell script every 2 seconds until it works. One of those worse–is–better ideas, it's really dumb, and effective. You can check for arbitrary conditions and error–exit, and it will keep trying. If you need the time synced you can just make your script fail if the time is not synced.

traditional inittab is older than that and there's not any reason to use it when you could be using runit, really.

[blibble]

yeah, many options that are complicated beyond the understanding of the distro maintainers, and yet still don't allow expression of common semantics required to support network services reliably

like "at least one real IP address is available" or "time has been synced"

and it's not esoteric, even ListenAddress with sshd doesn't even work reliably

the ONLY piece of systemd I've not had problems with is systemd-boot, and then it turned out they didn't write that

[jorvi]

> like "at least one real IP address is available" or "time has been synced"

"network-online.target is a target that actively waits until the network is “up”, where the definition of “up” is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network has been set up."

For time sync checks, I assume one of the targets available will effectively mean a time sync has happened. Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one.

[blibble]

it's the "usually" that's the problem

this service (untouched by me) had:

After=local-fs.target network-online.target remote-fs.target time-sync.target

but it was still started without an IP address, and then failed to bind

just like this sort of problem: https://github.com/systemd/systemd/issues/4880#issuecomment-...

the entire thing is unreliable and doesn't act like you'd expect

> Or you can do something with ExecStartPre. You could run a shell command that checks for the most recent time sync or forces one.

at that point I might as well go back to init=/etc/rc

[jorvi]

Are you running this particular unit file as a user unit or a system unit? Some targets like network-online.target don't work from user unit files.

You could also try targeting NetworkManager or networkd's "wait-online" services. Or if that doesn't work, something is telling systemd that you have an IP when you don't. NetworkManager has "ipv4.may-fail" and "ipv6.may-fail" that might be errenously true.

> at that point I might as well go back to init=/etc/rc

The difference is that systemd is much better at ensuring correctness. If you write the invoked shell command properly, it'll communicate failure or success correct and systemd will then communicate that state to the unit. It's still a lot more robust than before.

[blibble]

it's a system service file

the problem is systemd

> The difference is that systemd is much better at ensuring correctness.

yeah, whatever mate

[direwolf20]

> Some targets like network-online.target don't work from user unit files.

So basically it just doesn't work sometimes for no particular reason.

> The difference is that systemd is much better at ensuring correctness

Uh, well, you just said that it isn't, because some targets like network-online.target don't work from user unit files.

[magicalhippo]

> https://github.com/systemd/systemd/issues/4880

I'm not a systemd hater or anything, but I continue to read stuff from Poettering which to me is deeply disturbing given the programs he works on.

Saying it's not a bug that service is launched despite a stated required prerequisite dependency failed... WTF?

Sure, I agree with him that most computers should probably boot despite NTP being unable to sync. But proposing that the solution to that is breaking Requires is just wild to me.

[jcgl]

I'm not sure I understand why you think the solution proposed there is so bad.

The question in that issue is around the semantics of time-sync.target. Targets are synchronization points for the system and don't (afaik) generally make promises about the units that are ordered before them (in this case chrony-wait.service.

Does that answer your specific objection of "proposing that the solution to that is breaking Requires is just wild to me"? Basically, what is proposed in that issue is not breaking Requires=. The proposition is that the user add their own, specific Requires= as a drop-in configuration since that's not a generally-applicable default.

[direwolf20]

Is it possible for network-online to mean that, or does network-on actually mean that?

It is possible for a specification to be so abstract that it's useless.

[jcgl]

That's entirely defined by whatever units order themselves before network-online.target (normally a network management daemon like NetworkManager or systemd-networkd). systemd itself doesn't define the details; that's left up to how that distro and sysadmin have configured the network manager/system.

[bandrami]

Sysadmins really hate the word "usually", and that is at the root of just about every systemd headache I've had

[ethin]

Same. I run a server with a ton of services running on it which all have what I think are pretty complex dependency chains. And I also have used Linux with systemd on my laptop. Systemd has never, once, caused me issues.

[jacquesm]

I can totally relate to this, it's gotten to the point that I'm just as scared of rebooting my Linux boxes as I was of rebooting my windows machine a couple of decades ago. And quite probably more scared.

[blibble]

everyone attacking Microslop for a bug where Windows won't shut down properly

well, systemd's got them beat there!

[direwolf20]

The good thing about systemd or any other Linux software is that you don't have to use it, until this company gets off the ground.

[jacquesm]

I think at some point we will see a steep increase in value of old hardware that can still run unsigned binaries.

[direwolf20]

It won't be able to interact with any online services like Google or Hacker News.

[herewulf]

Ah, we will get more done. Or maybe just see you on the mailing list and IRC?!

[rsync]

You will always be able to interact with rsync.net …

… and the warrant canary we publish every Monday morning.

[jacquesm]

Google I can live without ;)

[esseph]

What distro?

[jacquesm]

The box that I'm worried about in particular is running RedHat.

Ubuntu boxes: usually ok as long as you stay away from anything python related in the core system.

[1vuio0pswjnm7]

"for what? to save a second of boot time"

Doubtful the motivation was /etc/rc being too slow

daemontools, runit, s6 solve that problem

[jacquesm]

The only parties that really cared about boot time were the big hosting providers and container schleppers. For desktop linux it never mattered as much.

[braincat31415]

For me, randomly missing NFS mounts after boot were the last straw. I could not solve this problem. I am back on sysv init.

[smm11]

This. If you set an NFS share, it better be there forever and ever.

[bee_rider]

PipeWire is like 10 years newer than PulseAudio. It probably had a chance to learn some lessons!

IIRC before PulseAudio we had to mess around with ALSA directly (memory hazy, it was a while ago). It could be a bit of a pain.

[ahartmetz]

PipeWire was also made by a guy with a lot of multimedia experience (GStreamer).

ALSA was kind of OK after mixing was enabled by default and if you didn't need to switch outputs of a running application between anything but internal speakers and headphones (which worked basically in hardware). With any additional devices that you could add and remove, ALSA became a more serious limitation, depending. You could usually choose your audio devices (including microphones) at least at the beginning of a video conference / playing a movie etc, but it was janky (unreliable, list of 20 devices for one multi-channel sound card) and needed explicit support from all applications. Not sure if it ever worked with Bluetooth.

[Sophira]

> Not sure if it ever worked with Bluetooth.

It does, with the help of BlueALSA[0].

[0] https://github.com/arkq/bluez-alsa

[fao_]

I remember ALSA. Sure, it was finnicky to use `alsamixer` to unmute the master channels now and then, but I personally never had any trouble with it.

[account42]

I still need to use alsamixer to unmute my headphones after accidentally unplugging them and plugging them in again fails to do so. That's with PipeWire - never had that problem with just ALSA.

[fao_]

Eh, I had to do that with pulseaudio too, but constantly, across all distros and headphones. Pipewire is shonky, I have to restart now and then on my steam deck (I'm using it as a desktop), but it's still much better than pulseaudio. Even ALSA was better than pulseaudio lol

[ahartmetz]

For most of the (sadly not shorter) life of PulseAudio, ALSA was more reliable, but at some point, Firefox got a new audio backend that straight up dropped support for ALSA, and a few games started crashing with backtraces indicating audio trouble when not run with PulseAudio. I've had to deal with PulseAudio's dropouts under load, latencies and lockups for 2-3 years before PipeWire became a viable replacement.

[sam_lowry_]

Alsa with dmix is my current setup on ArchLinux.

[jjmarr]

I installed Gentoo in 2014 and getting PulseAudio working was much easier than ALSA. It was also much better.

I get ALSA followed the Unix philosophy of doing one thing but I want my audio mixer to play multiple sounds at once.

[account42]

Gentoo in 2014 had dmix enabled by default without the need for any user configuration. I know because I was using it.

[jjmarr]

I got stuck for two weeks installing the kernel because I forgot to mount /boot. Perhaps I disabled it by accident when goofing around in alsamixer? Or my card did or didn't have hardware mixing?

I didn't actually know anything about Linux at the time and started with Gentoo because I saw a meme saying "install Gentoo" and people told me not to start with that distro. So it's possible I messed up the default config by accident.

Either way PulseAudio worked after I emerged it.

[esseph]

Debian is a darling for which I will always love, but it's inability to deal with systemd is one of the prime reasons I left.

I am not seeing these kind of systemd issues with Fedora / RHEL.

It just works

[jacquesm]

That's because systemd originated at RedHat. If it had been designed distribution agnostic it would have worked a lot better on other distros besides RH.

[NekkoDroid]

What are the non-distribution agnostic parts of systemd? Considering it runs as PID1 (usually) it kinda is the base of distros and not really built on top of any distro other than "the linux kernel".