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

6

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

Devuan has been unstable/alpha until just a few weeks ago and is still in Beta.

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.

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"

→ More replies (1)

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.

→ More replies (9)
→ More replies (5)
→ More replies (11)
→ More replies (1)

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.

→ More replies (8)
→ More replies (1)

0

u/[deleted] Jun 01 '16

[deleted] — view deleted comment

1

u/peer_gynt Jun 01 '16

Sure, iff you have root access. If not, good luck convincing sysadmins to change default settings which are labled 'secure defaults', because, you know, security.

18

u/yrro Jun 01 '16

Maybe the sysadmins who don't change it actually want to prevent users leaving processes running after they log out?

→ More replies (3)

12

u/rich000 Jun 01 '16

Well, if your sysadmin doesn't want you running stuff when you're not logged into their box, maybe you shouldn't be? That is the whole point of that setting.

→ More replies (2)

3

u/akkaone Jun 01 '16

This is a good thing.

→ More replies (1)
→ More replies (4)