Avoiding Complexity with Systemd

whateveracct wrote: post #2

Use NixOS and you'll love systemd. You'll be defining your own systemd units with ease. systemd to you will be journalctl and systemctl. So pretty good.

I use mostly Ubuntu and Debian and defining systemd units just means you have to spit the right text into a .service file placed at the right spot.

How does NixOS make that easier?

Re: Avoiding Complexity with Systemd

#5

Post by folex » Sun, Jun 27, 2021, 8:53 AM UTC

I just learned about S6 recently. It simplified daemon supervision for me a lot.

Re: Avoiding Complexity with Systemd

#6

Post by nix23 » Sun, Jun 27, 2021, 9:02 AM UTC

atoav wrote: post #4

whateveracct wrote: post #2

Use NixOS and you'll love systemd. You'll be defining your own systemd units with ease. systemd to you will be journalctl and systemctl. So pretty good.

I use mostly Ubuntu and Debian and defining systemd units just means you have to spit the right text into a .service file placed at the right spot. How does NixOS make that easier?

https://nixos.wiki/wiki/NixOS:extend_NixOS

Re: Avoiding Complexity with Systemd

#7

Post by siraben » Sun, Jun 27, 2021, 9:02 AM UTC

atoav wrote: post #4

whateveracct wrote: post #2

Use NixOS and you'll love systemd. You'll be defining your own systemd units with ease. systemd to you will be journalctl and systemctl. So pretty good.

I use mostly Ubuntu and Debian and defining systemd units just means you have to spit the right text into a .service file placed at the right spot. How does NixOS make that easier?

In NixOS it's trivial to use and define NixOS modules, which handle restarting/starting/stopping systemd units. See the wiki example[0] on how to define and use a service that greets the user with GNU Hello. Also, since you have access to Nixpkgs, you can make the ExecStart as complicated as you want with whatever dependencies you desire, and trivially share it with others.

[0] https://nixos.wiki/wiki/Module#Example

Re: Avoiding Complexity with Systemd

#8

Post by djhworld » Sun, Jun 27, 2021, 9:15 AM UTC

Really enjoyed reading this article.

The LoadCredentials thing reminds me of configmaps in K8S, is there a more general thing in systemd e.g LoadConfig

Re: Avoiding Complexity with Systemd

#9

Post by Dah00n » Sun, Jun 27, 2021, 9:17 AM UTC

I read that as meaning "avoid systemd's complexity" as opposed to "avoid complexity by doing so and so using systemd". Oh well.

Re: Avoiding Complexity with Systemd

#10

Post by Dinux » Sun, Jun 27, 2021, 9:18 AM UTC

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts.

I remember when it took multiple days testing the configuration on different distributions, editions and versions to just get a single daemon process to start without failure. Then do the whole thing over again because the Debian based distros did not use the RedHat startup tools, different (or no) runlevel configurations, different service binders, different NTP daemon, different terminal deamon, etc.. And of course the French customers wanted the service to work with Mandriva, the German customers want SUSE support with extended security options like dropping permissions after boot.

Just like the article mentions you can define a portable service model with security and failure handling built in. There wasn't even anything that came close back in the day. Systemd may not have been built with the Unix philosophy in mind, but at some point that becomes a secondary concern.

Systemd unifies all systemd resources in units which work anywhere, its expandable and extendable, user friendly, allows for remote monitoring etc.