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

21–30 of 332 posts

Re: Systemd, 10 years later (2020)

#21

Post by cfors »

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.

IBM already purchased red hat for $34b 3 years ago, so no need to wait any longer :)

Re: Systemd, 10 years later (2020)

#22

Post by justinsaccount »

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

It does exactly what the configuration tells it to do.

At one point some distributions accidentally configured the sshd or cron unit to do that. People were a bit surprised when restarting sshd or cron killed every single background child process.

See https://www.freedesktop.org/software/systemd/man/systemd.kil...

Not to mention if k3s is just managing containers running under docker or containerd, those processes are not parentless just because k3s stopped.

Re: Systemd, 10 years later (2020)

#23

Post by an_d_rew »

This was an amazing review, and love systemd or hate it, this article gives a fantastic history and exposition of what systemd actually is.

My favorite quote (and when taken in context is much less tongue-in-cheek thank you might think):

systemd is an event-driven object manager with dependency-like side effects which ‘boxes’ primitive kernel resources and userspace subsystems into a generic object type called Unit. These Unit objects are scheduled through the state propagation mechanism of ‘jobs’ and dynamically dispatched via a singleton object called Manager, responsible for launching jobs in ‘transactions’ which do merging, cyclic ordering and consistency checks and serve as the main point at which unit dependencies are pulled in. Unit startup is executed as a non-indempotent parallel dataflow with weak ordering guarantees on the job level, mostly independent of the active state of dependent units.

Any night you have insomnia, just read that a few times and you'll be out like a light! :-)

Re: Systemd, 10 years later (2020)

#24

Post by [deleted] »

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.

[deleted]

Re: Systemd, 10 years later (2020)

#25

Post by VTimofeenko »

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…

Anecdata: as someone not engaged in systemd development and one that likes tinkering with hardware tokens and luks, I found that at least the fido2/cryptsetup part of systemd was fairly easy and logical to follow and debug.

I would argue that locked and pentalobe metaphor is not very accurate - systemd is no more locked than most other open source software.

Re: Systemd, 10 years later (2020)

#26

Post by akagusu »

I am old enough to remember that problems with systemd were less technical and more political.

People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency.

Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.

Re: Systemd, 10 years later (2020)

#27

Post by smarterclayton »

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

Depending on the container runtime in use (containerd, crio), a separate process is managing and running those container processes (so k3s is telling that process what to do, but doesn’t “own” the containers). Also, modern container runtimes interface directly with systemd to launch transient units (think systemd services but without on disk config), so restarting a cri-o for example won’t restart those processes. That allows systemd to manage the process and for k3s/kubelet/cri-o to be upgraded / crash and recover.

Under crio to stop all containers you can (well, should but YMMV depending on any changes we’ve made recently)

systemctl stop kubepods.slice

Note that doing that a subsequent start shouldn’t bring the containers back unless k3s and crio were both running (the transient units don’t survive restart).

Note: there’s tons of complexity here that has changed over the last five or so years as container runtimes evolve, so if anything I said is wrong now it was right at one point and might actually be a bug.

Kube for instance didn’t use to gracefully shut down containers on node reboot, and over last few years we’ve gradually fixed all of the complexities so that you do get the correct shutdown behavior between systemd (which takes the “power down” input) to the unit (which encodes how long graceful shutdown should take based on the pod termination grace period seconds) to cri-o (which has to set the correct behavior in systemd) to kubelet (which has to stay running to keep updating the API) to the other components on the node (like container networking, which needs to stay up until all pod network pods are done).

systemd makes a lot of that a lot less painful than it would without.

Re: Systemd, 10 years later (2020)

#28

Post by mongol »

c0l0 wrote: post #18
mongol wrote: post #14

Earlier quoted context omitted.

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 (l…

Thanks for explaining that. My comment was not a criticism against systemd, more a surprise that k3s did something that was not expected by me when I interacted with it through systemd. For example, httpd does not supply a kill-all-httpd.sh script as far as I know. Perhaps there are systemctl verbs that can be added to support what k3s devs apparently thought neccessary to implement in a separate script.

Re: Systemd, 10 years later (2020)

#29

Post by zozbot234 »

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

For what it's worth, the OP argues the opposite - that systemd is insufficiently generic. Much of its complexity is a matter of conflating mechanisms and policy.

This is par for the course for what's essentially prototype-quality software that's trying to address a number of non-trivial issues - but let's not pretend that real improvement is not possible here, or that systemd-as-it-currently-is does not stray from what's often called 'the UNIX philosophy' or 'the art of UNIX programming', of which separating mechanism from policy is a key component.

Re: Systemd, 10 years later (2020)

#30

Post by kzrdude »

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…

systemd made it possible for me to write new service scripts - system and user kind - in a way I couldn't do before. It seems to have empowered me, because it's actually quite easy to use.
Post reply on HN