Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

Post reply on HN
Print view View original

11–20 of 332 posts

Re: Systemd, 10 years later (2020)

#11

Post by fuzzy2 »

mongol wrote: post #10

How does it work in a Kubernetes world? I found today that "systemctl stop k3s" actually did not stop all k3s dependent processes. A separate script was supplied to do that. So on a Kubernetes box there are processes running in namespaces that systemd does not manage?

Not sure what you’re asking about. If Systemd didn’t start it, Systemd doesn’t manage it. Nothing strange about that…? Systemd does not start all the Kubernetes stuff.

k3s could stop everything, but it doesn’t. It’s a design decision.

Re: Systemd, 10 years later (2020)

#12

Post by a-dub »

marcodiego wrote: post #3

Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs .

yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry.

in the earlier days when it was still buggy, even linus himself was screaming about not being able to easily take the case off of pid 1 when it misbehaved.

Re: Systemd, 10 years later (2020)

#13

Post by xyzzy_plugh »

mongol wrote: post #10

How does it work in a Kubernetes world? I found today that "systemctl stop k3s" actually did not stop all k3s dependent processes. A separate script was supplied to do that. So on a Kubernetes box there are processes running in namespaces that systemd does not manage?

Define manage?

If systemd is your init, then it manages everything. It may not manage them at a service level ala systemctl stop, but that's true of pretty much everything. Whether or not k3s brings down everything with it is on k3s. I certainly see why stopping k3s might not stop all dependent processes: it's useful for live upgrades.

Re: Systemd, 10 years later (2020)

#14

Post by mongol »

fuzzy2 wrote: post #11
mongol wrote: post #10

How does it work in a Kubernetes world? I found today that "systemctl stop k3s" actually did not stop all k3s dependent processes. A separate script was supplied to do that. So on a Kubernetes box there are processes running in namespaces that systemd does not manage?

Not sure what you’re asking about. If Systemd didn’t start it, Systemd doesn’t manage it. Nothing strange about that…? Systemd does not start all the Kubernetes stuff. k3s could stop everything, but it doesn’t. It’s a design decision.

It did start it. For example the k3s process did start a container registry, but it did not stop it. I thought one of the points of systemd was that it would reap parentless processes

Re: Systemd, 10 years later (2020)

#15

Post by mongol »

xyzzy_plugh wrote: post #13
mongol wrote: post #10

How does it work in a Kubernetes world? I found today that "systemctl stop k3s" actually did not stop all k3s dependent processes. A separate script was supplied to do that. So on a Kubernetes box there are processes running in namespaces that systemd does not manage?

Define manage? If systemd is your init, then it manages everything. It may not manage them at a service level ala systemctl stop, but that's true of pretty much everything. Whether or not k3s brings down everything with it is on k3s. I certainly see why stopping k3s might not stop all dependent processes: it's useful for live upgrades.

Yes the live upgrade argument was mentioned when I searched for it. So it makes sense in some ways but it surprised me, and I think probably this is an area that can be improved.

Re: Systemd, 10 years later (2020)

#16

Post by dredmorbius »

usrbinbash wrote: post #7

https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... quote: "What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. " endquote

https://old.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...

Re: Systemd, 10 years later (2020)

#17

Post by wrycoder »

a-dub wrote: post #12
marcodiego wrote: post #3

Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

Right. I have a simple rule: don’t use a GNU/Linux system that uses systemd. It doesn’t respect the Unix philosophy. It’s trying to turn it into Windows.

I’m waiting for Microsoft to buy Red Hat. Failing that, IBM.

Re: Systemd, 10 years later (2020)

#18

Post by c0l0 »

mongol wrote: post #14
fuzzy2 wrote: post #11

Earlier quoted context omitted.

Not sure what you’re asking about. If Systemd didn’t start it, Systemd doesn’t manage it. Nothing strange about that…? Systemd does not start all the Kubernetes stuff. k3s could stop everything, but it doesn’t. It’s a design decision.

It did start it. For example the k3s process did start a container registry, but it did not stop it. I thought one of the points of systemd was that it would reap parentless processes

Which processes systemd allows to live on after stopping an associated service depends on the kind of KillMode= (see systemd.kill(5)) that was specified for the service unit. The default ('control-group') is usually what you want, esp. if you are looking to not recreate the kind of chaos improper process management SysV-style init scripts frequently caused.

Chances are the k3s service unit specifies something else (like 'none') - whether or not that is actually wise would probably require some research.

Re: Systemd, 10 years later (2020)

#19

Post by gtirloni »

wrycoder wrote: post #17
a-dub wrote: post #12

Earlier quoted context omitted.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

Right. I have a simple rule: don’t use a GNU/Linux system that uses systemd. It doesn’t respect the Unix philosophy. It’s trying to turn it into Windows. I’m waiting for Microsoft to buy Red Hat. Failing that, IBM.

Uh?

https://www.redhat.com/en/about/press-releases/ibm-closes-la...

Re: Systemd, 10 years later (2020)

#20

Post by opan »

zh3 wrote: post #2

It's not as bad as at first feared. Views here are along the usual lines; for many when there's an issue either it's something that's fixable inhouse (init scripts) or needs a support contract. Having said that, personally (old school) I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason.

>I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason.

This is one of my go-to reasons when people ask me why systemd is bad. Once it overrode power settings I had configured in xfce-power-manager. Mainly I wanted the lid close to do nothing on AC power and to sleep on battery. It started sleeping for everything after an update once. I think in the end I couldn't figure out how to get the exact desired behavior with systemd and I disabled sleep entirely.

The other reason I often mention is the ridiculous shutdown timer thing that makes you wait for minutes sometimes for some service to end.

The main advantage to systemd is that a lot of unit files were already written and packaged with stuff, including --user variants, and also that it has a user mode at all (OpenRC doesn't yet). Fairly minor advantage, imo. In general I prefer shepherd, runit, or openrc. My needs are pretty simple, though. Most of the time I just need to start/stop/restart a service, which is pretty simple in every init system I've used.

Post reply on HN