Hacker News Reader

Comment by petre | Hacker News Reader

Maybe eventually Linus will become so fed up with systemd, that he would write an init system of his own, which would become a major success just like git did. Then conversations like this one will be pointless, because everyone and their dog with the possible exception of RedHat would have long switched to Linus' init.

Systemd and the whole controversy around it is anything but funny. It's upsetting and it already divided the community.

View on HN

Maybe eventually Linus will become so fed up with systemd, that he would write an init system of his own

Can't. Fucking. Wait. Seriously, that day cannot come soon enough. systemd might have some useful ideas, but their implementation is crap, and the overall intrusion on how to get stuff done is significant.

It's a little funny.

systemd has some great stuff in it. I have my nits to pick with it but, on the whole, it's better than what we had before. And, don't we all just want things to be a little better every day?

I think it's all gonna work out fine in the end (and if not, we'll all be dead someday, anyway).

I would say the same with pulseaudio; before this, there were a mess of audio servers (esd / ksd or none) - now things are definitely better.

I have not required a audio server in years, and i have not adopted PA. What i did was enable dmix, that comes with Alsa.

A behavior that is even default Alsa these days if it detect that you use sound hardware without mixing.

The one "issue" that PA "fixed" was that of temporary audio devices (bluetooth, USB). But then i find the whole notion of USB headphones (a pair of headphones soldered to a minimal USB sound card) a massive abomination. and i fail to see why paired Bluetooth audio devices are exposed directly into the /dev tree rather than behind the Bluetooth dongle device.

I use tmux and emacs --daemon constantly. My experience with systemd is that I need to check whether KillUserProcesses is enabled, or else systemd will kill my processes. My experience with init was nonexistent, because it never came up as an issue.

Most distros have set KillUserProcesss to no for the short-term. Fedora plans to make all of the obvious user programs aware of the change (and able to create a new systemd unit for the process) and turn it back on for Fedora 26.

https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_...

Their reasoning is pretty good, IMHO. It provides more control at low cost, and it's a one-line configuration change if you want the old behavior. But, everything I need it for (pretty much just screen and tmux) will already be aware and will handle setting up the new systemd unit automatically.

But, it breaks a standard Unix behaviour going back years, and it can't be configured by a non root user.

It is a one-line configuration change IF you know that it exists, and you have administrator privileges on the machine. If either of those conditions fail, systemd has broken your setup.

Not only that, but there was an existing mechanism for this. On a disconnect, SIGHUP would be sent to all processes. A background process can explicitly ignore SIGHUP in order to remain running on disconnect. I would be fine if systemd were sending SIGHUP to processes, because that would fit with the existing method of opting out. Sending SIGKILL, and having to use systemd's API to opt out of being killed is ridiculous.

This adds more complexity for no added benefit. My standard .bashrc now needs to have a line checking whether KillUserProcesses is enabled, so that I can bug the admin to disable that idiocy if it is.

>A background process can explicitly ignore SIGHUP

The problem with SIGHUP is that a background process can't explicitly ignore SIGHUP, it can only implicitly ignore it. If you send SIGHUP to a process and it doesn't exit you have no idea if it didn't exit because it wants to hang around or if it didn't exit because the process is hung.

Part of the motivation for fixing that is to eliminate things like gnome-keyring-daemon hanging around after the user logs out.

Correct me if I am wrong, but I would call signal(SIGHUP, mysignalhandler) to be an explicit ignoring of SIGHUP. I have taken a non-default action in order to have a non-default behavior.

Since gnome is the one that requires behavior and integration with systemd beyond what can be done with signals, a reasonable workaround would be to have the extra logic in systemd apply only to gnome. As it is, they are changing to a default that is entirely unreasonable outside of a desktop environment, and requiring others to work with the new system.

>I would call signal(SIGHUP, mysignalhandler) to be an explicit ignoring of SIGHUP. But that doesn't explicitly ignore SIGHUP. You're explicitly handling it but from an outside perspective we don't know if your SIGHUP handler is supposed to be a no op, output some progress information, terminate the program in some special way or what. All the system knows is that it signaled your program and your program is still around 10 seconds later. In terms of your program, it hasn't taken any external action, hence not being explicit.

As for the Gnome project though, that's just an example. I'm talking about cases where the application should terminate upon receipt of SIGHUP but doesn't. That default isn't changing, the method to avoid the default action is. Back when SIGHUP was created all software that wanted to ignore it needed to make a handler to avoid the new default behavior. If you want to be able to kill misbehaving processes that were supposed to terminate on SIGHUP then the design needs to change. There's no way to fix this without making some breaking change.

As to requiring others to work with it, your distribution is the one that's making you do that. systemd upstream has had killuserprocesses for a while now. It's just a configure option when building systemd. It's not like your distro is having someone else build packages for them, setting appropriate config options is entirely on them. Some distros are building systemd with that on by default, and some aren't.

So, if I understand correctly, a misbehaved program that incorrectly ignores SIGHUP will be replaced by a misbehaved program that starts a new user scope with systemd. In both cases, there is no way to tell whether the program has hung, or whether it is working as intended. The end result is the same. So, we've switched to a new API, broken all existing daemons, for no end benefit?

I'm fine with having KillUserProcesses exist as a concept. There are some odd machines, like public terminals, where you would want to forbid any long-lived processes. I'm not okay with it being the default option. Yes, the distributions can change their default, but systemd's default in an endorsement that shouldn't be there.

No, that's not the concern here. KillUserProcesses is intended to reap children that were never intended to persist outside of the user session. My ssh-agent is never going to move itself into a new scope, but it very well could have a bug that causes it to hang around after I log out.

The only things that will ever create a new scope are things like tmux, screen, and maybe some variant of nohup.

Here's the kinds of problems that misbehaving processes actually cause.

https://bugs.freedesktop.org/show_bug.cgi?id=94508#c10

And yes, KillUserProcesses reliably fixes crap like "hp-systray" from hanging your whole session in a way that isn't obvious to the user. If there's a deadlock when trying to log out, somethings gotta give otherwise your session will just persist forever.

> Back when SIGHUP was created all software that wanted to ignore it needed to make a handler

False. People ran such softwares via the nohup command. No program modifications were needed. They still aren't.

Yeah but that's exactly the same situation we're in right now with distros turning on KillUserProcesses. I can start whatever processes I want to in another scope without having to modify those processes.

... but not with general-purpose tools that use the standard semantics that have been around since 7th Edition. Only with Linux-specific and systemd-specific tools. Which is why it of course is not the same situation at all.

Reply on news.ycombinator.com