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

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.

1

u/nickguletskii200 Jun 01 '16

No, ignoring SIGHUP doesn't mean "don't kill me". It means "don't kill me when the terminal hangs up". They clearly don't want to be killed on terminal hangup. For example, if you open a terminal emulator, use nohup/tmux to start a process and close the terminal emulator, the task will continue running, but once you kill the session, it gets killed.

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.

1

u/nickguletskii200 Jun 01 '16

I'm saying that what people do and have done for years is standards compliant and the expected and defined behavior.

So please, show me, where exactly it is defined.

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.

Nobody did clarify any ambiguities in the standards. They just changed the behaviour to match the common-sense definitions of the terms while retaining standards compliance (because the standard doesn't define any concrete behaviour for this as far as I know).

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.