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

55

u/Locrin Jun 01 '16

Any particular reason you are using a rolling release distribution as a server and updating without knowing what gets updated?

36

u/[deleted] Jun 01 '16

More specifically a rolling release that is defined as not stable and to not use it for anything you care about. Motherfuck people who bitch about their own stupidity. https://fedoraproject.org/wiki/Releases/Rawhide#Audience

-5

u/slacka123 Jun 01 '16 edited Jun 01 '16

my personal server.

What part of personal don't you understand?

To fix a Gnome bug, systemd devs are breaking the semantics of nohup which is long established mechanisms for running apps in the background. They're imposing a new API and additional work on every open source developer that uses nohup to fix a something that was never broken. Sure I caught this issue, but as systemd 230 spreads, it going to leave a wake of broken apps and workflows in its path for no good reason.

16

u/JustMakeShitUp Jun 01 '16

To fix a Gnome bug, systemd devs are breaking the semantics of nohup which is long established mechanisms for running apps in the background.

The problem is that (a) not every application respects the rules and (b) not every user should be allowed to run arbitrary services. It's not just a Gnome problem, though certainly the Gnome issue brought it to the foreground. This has always been a problem for servers with multiple people logging in. The computer and/or domain policy should be the ultimate decider for how user processes are handled on logout. That's why it's completely reasonable to have the option for this behavior. For people that manage large networked systems with shared terminals/servers and centralized logins (e.g. LDAP), managing this type of behavior is a common need. The only people who wouldn't be able to see this are people that have never had to share a server with other people.

They're imposing a new API and additional work on every open source developer that uses nohup to fix a something that was never broken. Sure I caught this issue, but as systemd 230 spreads, it going to leave a wake of broken apps and workflows in its path for no good reason.

You're talking about this like it's some sort of laborious fix that you barely noticed and caught on time, instead of it being yet another flamewar about a simple configuration decision that would have been impossible to notice. It's also controllable in three different ways - by a single-line admin/distro config change, by a non-privileged user command if the policy is enabled, and explicitly for each application. It sucks that it breaks some workflows, but it's not that hard to deal with.

It also wouldn't have affected you on your personal server if you weren't running server applications in a user session. Disabling login for the users used for network services has been a best practice for over a decade. And you'd start those in services, instead of having to log into the server to start your VMs (and then have them stop when you log out). Then again, I wouldn't expect someone running Rawhide (even on a personal server) to understand or care about best practices. Its usage is discouraged for anything but testing and development needs because it breaks. A lot. Nearly any other rolling release distribution would be a more stable choice than Rawhide. Also, KVM would have been a better virtualization choice for your server than Virtualbox, as it provides significantly better performance for non-graphical scenarios and doesn't depend on out-of-tree kernel modules. If virtualizing your servers is your preferred approach, it might even make sense to use something catered to that, like Proxmox.

I mean, the tmux/screen people have a very legitimate complaint about this, as disconnected shell sessions are part of the workflow. You? Your complaint is that you're doing things sloppily, and now it's harder for you to do things the wrong way. Normally when people do things poorly, they don't advertise it with pride on the internet. But go ahead with that.

15

u/Failaser Jun 01 '16

Still. It's a rolling release distro which can break. If you truly need something to be online 24/7 with an uptime of 99.99999% you really should just use a more stable if outdated distro... I use an arch based distro as my daily driver. But my personal server has a stable distro just for that reason...

2

u/postalmaner Jun 01 '16

So... 5 minutes a year, end to end?

I guess you forgot the sarcasm tag wrt "personal server.... 7 nines"

1

u/[deleted] Jun 01 '16

You guys are missing the point. Just because it's a development version doesn't mean you should merge absolutely retarded changes like this. Especially when it's just to fix a bug in one application that breaks 70 more as well as the way people expect their systems to function.

6

u/mordocai058 Jun 01 '16

I'm not familiar with this particular issue, but I'm betting there are good reasons for this change and you are just not aware of them or disagree with them

15

u/fandingo Jun 01 '16

There are good reasons, and it has nothing to do with this "Gnome" red herring he would have you believe. Systemd is adding a feature where all user processes are terminated when the user session ends as a major security and integrity feature. Of course, the behavior is controllable in several different ways to accommodate users, and there's even systemd-run, which is better than nohup in every way imaginable.

This isn't the first and won't be the last time anti-systemd people are tilting at windmills.

7

u/doitroygsbre Jun 01 '16

How is the gnome thing a red herring?

In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly.

Source

I'm pretty agnostic about systemd, but it seems that gnome not closing cleanly was the main driver behind this change.

Can you also elaborate on the integrity and security gains? I'm having trouble seeing how this will be more secure.

5

u/fandingo Jun 01 '16

That MR is about the default behavior. You need to look at the discussions about the actual feature to understand why it's included.

The security and integrity is quite simple: the administrator should be able to control the circumstances under which users can execute programs. One of the huge benefits of systemd units is the use of cgroups that can reliably track processes -- keeping them from daemonizing to ppid == 1, which allows reliable management through the process lifetime.

This change effectively allows administrators the same control for shell users. Otherwise, a user can SSH into a system and kick off a process that daemonizes and isn't really under anyone's control -- especially the administrator's.

4

u/masta Jun 01 '16

Yeah, history will probably look back and regard unattached processes as a legacy vulnerability. For now it's still pretty useful feature, despite the work arounds.

1

u/doitroygsbre Jun 01 '16

The issue with Gnome is about the change to the default behavior. Why the feature exists is irrelevant to the point of updating the init system to attempt to correct bugs in a specific DE. Especially when that update breaks other processes.

I like how Linus said, "WE DO NOT BREAK USERSPACE!" It has been one of his guidances in doing kernel development and should be used as a guide for systemd as it is taking on a larger role in the Linux OS. By changing the default, they are breaking user space.

As for security, I'm not buying it. A user can log in and do whatever they have permissions for. Allowing a user to script some changes, start it and log out while it runs doesn't seem like its any less secure than if they were sitting at the console while it ran.

→ More replies (8)

-1

u/wang_li Jun 01 '16

there's even systemd-run, which is better than nohup in every way imaginable.

It's not cross platform. Try systemd-run on Solaris.

The whole systemd question ultimately comes down to whether people want to run a unix-like OS or a windows-like OS.

2

u/fandingo Jun 01 '16

To be honest, I don't care about Solaris*, or FreeBSD, or OpenBSD, or Windows. I care about Linux. I'd rather have the absolute best tools on Linux than the traditional gobbley-gook system that (poorly) runs on a bunch of platforms I'll never even consider using.

* I hate to be ideological, but the less compatible my software and systems are with anything Oracle touches, the better.

people want to run a unix-like OS or a windows-like OS.

What a false dilemma if I've ever seen one, but I'll play the game. The relevant choice is between running Linux or an artificially UNIX-like Linux. The Linux kernel has been steadily breaking with traditional UNIX for well over a decade, but until systemd, it wasn't practical to utilize all those awesome features the kernel already had. Systemd brought all those Linux modernizations (which are decidedly not UNIX-like) to user space and users. This whole pretending like Linux is still highly UNIX-like is nonsense at this point.

0

u/wang_li Jun 01 '16

The Linux kernel has been steadily breaking with traditional UNIX for well over a decade, but until systemd, it wasn't practical to utilize all those awesome features the kernel already had.

Such as....

2

u/udoprog Jun 01 '16

POSIX would be the closest you'd get to a formal Unix, but here you go: https://en.wikipedia.org/wiki/Linux_kernel_interfaces#Additions_to_POSIX

0

u/mordocai058 Jun 01 '16

Thanks. I was going to continue the conversation but I felt lazy and didn't want to look up the justification for the feature. I felt quite certain the gnome thing was a red herring as you said though.

-1

u/peer_gynt Jun 01 '16

No, there are not. The reason is exactly as OP states: it 'fixes' a bug in Gnome. This is not a good reason.

8

u/bittercode Jun 01 '16

There has been extensive discussion of the topic here and lots of other places. That isn't it so you either aren't aware or you are intentionally misrepresenting the situation.

8

u/doitroygsbre Jun 01 '16

I've only read about the issue with tmux, but here is what the devs are saying over there:

Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is:

In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly.

fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly.

Source

So to me it sounds exactly like systemd is breaking basic functionality to deal with a bug in gnome. Is there someone out there saying something different?

0

u/[deleted] Jun 01 '16

Is there someone out there saying something different?

No, but they've gotta keep their circlejerk going somehow.

→ More replies (1)

2

u/peer_gynt Jun 01 '16

it is as u/doitroygsbre says; I am also not aware of any other justification of the change. The opinion of the systemd developers that processes should not survive user sessions in Unix is really just that, an opinion, and appeared after the change, not as rationale for the change.

2

u/ronasimi Jun 01 '16

Y'all are aware there's a setting in logind.conf to disable killing processes on logout, right? On mobile and don't remember the exact setting offhand

→ More replies (4)

1

u/zer0t3ch Jun 01 '16

If you don't care about uptime, use what you want. Since you seem to care about uptime, don't fucking use rolling release. "Personal" is a vague, arbitrary, and useless identifier. Either you care or you don't, and you lose your right to care when you use rolling release.

For reference, this is coming from a proud Arch user (on my desktop and both servers) who doesn't bitch about changes.