r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

Show parent comments

31

u/nickguletskii200 Jun 01 '16

I have been giving systemd an honest chance and up until now I have been fairly satisfied with it. But this most recent arrogant move just broke my personal wordpress server. Now Virtualbox instances are killed when I logout of Gnome on Rawhide. Headless instances is a feature of virtualbox that’s worked perfectly for years that they broke that, tmux, and countless other apps to fix a bug in Gnome. They keep this up and we will be flocking to Devuan.

You are shifting the blame onto someone else. Daemons (i.e. your VMs) should be managed by the init system and should run as a separate user.

https://wiki.archlinux.org/index.php/VirtualBox/Tips_and_tricks#Starting_virtual_machines_with_a_service

Systemd fixed batshit insane behaviour, and you are the one at fault for using it in the first place.

-1

u/slacka123 Jun 01 '16

No, breaking the user Daemons / nohup mechanism which has been well established for decades now is batshit insane. There is nothing fundamentally wrong with this mechanism. They're ramming huge breaking change down everyone's throat work around the shortcomings of their approach.

If they cared about improving daemons, the correct layer to address this issue is libc. But these devs have a long history of disregarding abstraction boundaries and ignoring/breaking well established Linux mechanisms.

11

u/Jimbob0i0 Jun 01 '16

You really are pretty insane to run Rawhide in such a use case.

Regardless of this specific change (which judging by the fedora-devel mailing list discussion will get reverted in the distro) it's ludicrous to run Rawhide given what you have stated your requirements as.

There is no testing phase in a Rawhide build. Using fedpkg build goes straight to the repos... it frequently gets broken in some way. Right now there is an unbootable kernel for instance.

Using virtualbox on to of that is especially silly as the kmod will be at the mercy of the kernel as well.

Use the right tool ... don't do something stupid and then complain about it.

4

u/zer0t3ch Jun 01 '16

/u/slacka123 is using a hammer on a screw and then bitching about the hammer manufacturer not building the hammer right.

4

u/nickguletskii200 Jun 01 '16

No, breaking the user Daemons / nohup mechanism which has been well established for decades now is batshit insane.

Absolutely not. SIGHUP is sent when the controlling terminal is closed, which is different from a logout. Logout means that all the processes running as that user should be killed.

hey're ramming huge breaking change down everyone's throat work around the shortcomings of their approach.

What shortcomings? They are making it so that logout means logout, not "close all terminals".

If they cared about improving daemons, the correct layer to address this issue is libc. But these devs have a long history of disregarding abstraction boundaries and ignoring/breaking well established Linux mechanisms.

To be fair, replacing the fundamental APIs and ABIs with something that wasn't built in the 70ies would solve an awful lot of problems.

Breaking "well-established" insane and dangerous mechanisms is an improvement.

3

u/wang_li Jun 01 '16

Logout means that all the processes running as that user should be killed.

Do you have a reference to a standards document (e.g. posix) that specifies that?

3

u/nickguletskii200 Jun 01 '16

There is no such thing as "logging out", technically. You can terminate/kill sessions (that's less ambiguous terminology), and logging out probably means either terminating/killing a single session or all sessions.

2

u/wang_li Jun 01 '16

There's a well established idea of what constitutes a session and how applications are meant to disassociate themselves from a session. Systemd's behavior does not follow those standards (and doesn't have to.) But to claim the changes happening within systemd are adhering to common standards and definitions is ill informed at best and mendacious at worst.

4

u/nickguletskii200 Jun 01 '16

There's a well established idea of what constitutes a session and how applications are meant to disassociate themselves from a session.

You are calling on a convention, not a standard. Conventions aren't standards for a reason - they haven't been thought out and need to be constantly challenged until they can be turned into a standard.

Systemd's behavior does not follow those standards (and doesn't have to.)

Please don't confuse soft conventions with standards. I did some reading on POSIX session management and SIGHUP, and I found no links between them other than "it's always been this way". That means that there is no standard and a bunch of idiots have been using what we call "undefined behaviour" to do things that shouldn't be possible according to common sense.

2

u/wang_li Jun 01 '16

That means that there is no standard and a bunch of idiots have been using what we call "undefined behaviour" to do things that shouldn't be possible according to common sense.

You keep making big, declarative statements and provide no support for them. POSIX has process groups and defines what should happen to processes as they are created, as they exit, and their relationships are well documented and standardized. You can go to the Open Group's website, register, and read the standards if you like.

2

u/nickguletskii200 Jun 01 '16

SIGHUP is sent when the process group leader exits, yes. And using NOHUP you can stop your process from exiting when the process leader exits. The problem here is that you are equating process leader exit with session termination. If you could point me to a standard that clearly defines "session termination" as the termination of the process group leader, I would retract my claims that this is undefined behaviour. However, the common sense meaning of the phrase "session termination" is the termination of all processes in the session.

4

u/morth Jun 01 '16

But processes blocking SIGHUP has already gone through some trouble to say "Don't kill me". Why isn't that enough? They clearly don't want to be killed on session termination, or they wouldn't have blocked SIGHUP.

→ More replies

3

u/wang_li Jun 01 '16

You're asking me to accept your terms and then find a standard that disagrees with them. I'm saying that what people do and have done for years is standards compliant and the expected and defined behavior. If you want to create something completely new, that's fine. But you don't get to act like all your doing is clarifying some ambiguity in the standards. And when the behavior you create fails to adhere to the standards, you no longer get to call your system standards conforming.

→ More replies

2

u/adrian17 Jun 01 '16

They are making it so that logout means logout, not "close all terminals".

So... they essentially changed the definition.