this post was submitted on 15 Aug 2023
140 points (98.6% liked)

Linux

48092 readers
899 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

I am a Linux user, but I don't really know how most things work, even after years of casual use on my Main, I just started getting into Devuan and wondered then, what exacly does systemd do that most distros have it? What even is init freedom? And why should I care?

all 50 comments
sorted by: hot top controversial new old
[–] bamboo@lemm.ee 139 points 1 year ago (5 children)

Systemd is the first program that runs once the kernel has started. It's job is mostly just starting up other processes, and managing those other processes. If you don't know what systemd is, then you probably shouldn't care about if you're using it or not, it's good software but there are fine alternatives.

What makes systemd particularly interesting is that it is different from historical init systems. Historically these init systems were an unholy mess of shell scripts. This offers maximum flexibility, but limits the functionality of the init system itself. Systemd replaces these shell scripts with simple ini-like service files that allow everything to be declared simply and declaratively, and allows specifying more rich metadata, like dependencies. But it's different, and some people place a higher value on "how it's always been" than pragmatism. I personally have zero sympathy for them because throwing out objective progress to hold onto a broken system designed for 1960s computing is just dumb.

[–] teft@startrek.website 41 points 1 year ago

throwing out objective progress to hold onto a broken system designed for 1960s computing is just dumb

Preach.

[–] tetha@feddit.de 15 points 1 year ago* (last edited 1 year ago)

I mean to a certain degree, I can understand if people find a problem with Poetterings approach of doing things !CORRECTLY!. Like, systemd-resolved resolving A-records with multiple addresses ina deterministic fashion because it's not defined not to be deterministic, and because actual load balancing would be better. It's not wrong, but it's breaking everything. And it got patched after some uproar. And there are a few things like that.

But at the same time - I don't think people appreciate how hard doing process management right on linux can be, especially if the daemon to run is shitty. Like, init scripts just triggering the shutdown port on a tomcat - except the tomcat is stuck and not reacting to the normal shutdown port and now you have a zombie process and an init script in a fucked up state. Or, just killing the main process and for some reason not really removing the children, now there's zombies all over the place. Or, not trying appropriate shutdown procedures first and just killing things, "because it's easier" - except my day just got harder with a corrupt dataset. Or, just trying soft and "Pwease wexit Mr Pwocess" signals and then just giving up. Or having "start" just crash because there was a stale PID from an OOM killed process around. Man I'm getting anxiety just thinking about this.

And that's just talking about ExecStart and ExecStop, pretty much, which I have done somewhat correct in a few init scripts back in the day (over months of iteration of edge cases). Now start thinking about the security features systemd-analyze can tell you about, like namespaces, unmapping syscalls, masking parts of the filesystem, ... imagine doing that with the jankyness of the average init.d script. At that point I'd start thinking about rebooting systems instead of trying to restart services, honestly.

And similarly, I'm growing fond of things like systemd-networkd, systemd-timesyncd. I've had to try to manage NetworkManager automatically and jeez... Or just directly handling networking with network-scripts. Always a pleasure. Chucking a bunch of pretty readable ini-files into /etc/systemd/networkd is a blessing. They are even readable even to people rather faint on the networking heart.

[–] BlahajEnjoyer@lemmy.blahaj.zone 7 points 1 year ago (1 children)

I thought people hate systemd because it’s a resource hog compared to OpenRC. TIL i guess

[–] Audacity9961@feddit.ch 3 points 1 year ago* (last edited 1 year ago) (1 children)

The difference is absolutely negligible.

I never used openRC (outside of Docker containers that run Alpine) so I wouldn’t know. Linux community has enough controversies, init utils shouldn’t be one of them

[–] morethanevil@lmy.mymte.de 5 points 1 year ago

Best answer I've ever read ☝🏻☺️

[–] lloram239@feddit.de 115 points 1 year ago (3 children)

When you boot up your Linux, it will mount the root file system and start one program. That program is systemd. Everything else on your system will be started through systemd or processes that systemd started.

That's why it is important, everything else on your system is build on top of it. That's also why it is difficult to replace, if you use something other than systemd, you need a completely new set of config files for that other thing or your software might not work properly. Most distributions have given up on that, as it's just more work for a niche audience, and they just require systemd instead.

As a regular user you don't really have to care all that much, most stuff systemd does will happen automatically in the background and be setup by your distribution. It can still help to get familiar with systemd tools like journalctl as that's where all your error messages go and systemctl is how you start, stop or disable services on your system. If you use something other than systemd those tools won't exist and something else will take their place.

As for why people don't like systemd, it follows the kitchen-sink approach to software and does a lot of things at once. It replaced a whole zoo of smaller utilities like inetd, syslog, cron, atd, ... Some people dislike this loss of modularity, while most the rest are happy that they have one tool that does all of those things well, especially since systemd can do a lot of those tasks better and in a more unified way than previously.

[–] m_randall@sh.itjust.works 26 points 1 year ago (4 children)

This is a good post.

As for why people don't like systemd, it follows the kitchen-sink approach to software and does a lot of things at once.

For people new to Linux I just want to point out - for better or for worse this goes against the Unix philosophy.

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

[–] NRoach44@lemmy.ml 14 points 1 year ago* (last edited 1 year ago)

One thing that people miss - either out of ignorance, or because it goes against the narrative - is that systemd is modular.

One part handles init and services (and related things like mounts and sockets, because it makes sense to do that), one handles user sessions (logind), one handles logging (journald), one handles networking (networkd) etc etc.

You don't have to use networkd, or their efi bootloader, or their kernel install tool, or the other hostname/name resolution/userdb/tmpfiles etc etc tools.

load more comments (3 replies)
[–] Napain@lemmy.ml 11 points 1 year ago

wow thank you for taking the time and explaining that! I didn't except to learn that today right before bed today or ever. It's these kind of great comments that i come to lemmy for. Just know that i really appreciate it!

[–] mateowoetam@lemmy.zip 4 points 1 year ago

Great comment, cleared up a lot of thing, thanks.

[–] jsveiga@sh.itjust.works 21 points 1 year ago* (last edited 1 year ago) (1 children)

What does exactly systemd do?

It mostly causes heated discussions and a feeling of nostalgia for simpler times.

When your computer finishes loading the kernel, you have to tell it what to do next. There are dozens of systems and services that have to run (once or keep running) for everything to work. Mounting your disk partitions, bringing the networking up, starting the GUI, initializing all kinds of services, etc.

Once upon a time most (all?) distros used sysVinit, adapted from Unix's System V to do that. It was simple and very easy to understand and setup: Very basically the init program would call scripts by alphanumerical order (passing "start" to scripts starting with S and "stop" to ones starting with K). You'd place these scripts in /etc/rcX.d, X being a number, the runlevel (and you had just a handful of runlevels, like halt, reboot, single user, gui, etc). Want to run something between starting the network and bringing up sshd? Just create a script in /etc/init.d and link it to /etc/rcX.d naming it SNNmyscript, with NN being a number between the ones in SNNnetwork and SNNsshd. Want to disable a service? Change its script name from S... to K... Change startup sequences? Just change the NN.

Beautiful. But although it worked perfectly for most of us, it did have deficiencies. An obvious one is that it ran these scripts sequentially. Even if your computer was using 0.1% of its power to run each of them, you'd be waiting for each one to run in a single queue.

So a very nice and polite guy came up with systemd. Instead of simple scripts running sequentially, you could now create "unit files", describing each "thing to do", for what "targets" (similar to runlevels) that thing is needed, which scripts to run to make that thing happen, and which previous things should have been done before this thing (dependencies). With this, your computer can fire up multiple startup scripts (and stopping scripts) at the same time, only making sure to queue stuff so dependencies are met. For example, you don't need to wait for sshd to start your database server, but you do need networking before you mount shared disks.

That made boot times much better, but at the cost of complexity and maintainability (and here come heated discussions...).

The problem is that not everyone wanted that tradeoff, but systemd was shoved down everyone's throat as most (all?) distros adopted it.

So init freedom is a reaction to that, offering you the option of multiple init systems (there are more than just sysVinit and systemd).

No offense to all the other init systems, but I'd stick with sysV if you're really after simplicity and backwards compatibility with most older systems (and the old ways), or systemd, because it became the de facto standard, it's faster and more modern.

Should you care? If you have to ask this, then no.

If you had to craft your own init scripts and configurations, and had a ton of legacy scripts, or maybe were building very simple barebones systems, or very complex, always changing startup scenarios and targets or runlevels, or want to exercise your "freedom" just for the heck of it, then you could care.

If you're a distro hopper (i.e. are more dedicated to "use Linux" than to use applications which run on Linux), having tried 5 different init systems may be one more thing to brag about in distro hopper meetings.

If you're getting into Linux to learn Linux administration for career purposes, systemd is what you'll find in commercial systems.

If you're after an OS to just be an OS (i.e. just run your programs), just pick a well supported (community) and mainstream one, it will most likely come with systemd, and you'll probably never need to touch systemd. My wife (not technical) has been using exclusively Linux for 15+ years, and I can assure you with 100% certainty that she doesn't know which init system is there, or what is systemd or sysV.

If you're new to Linux, curious and want to learn all you can about it, I'd say there are many other interesting and useful things in Linux to learn and care about before you go down this rabbit hole, summoning some nice nostalgic but outdated tech from the dead.

[–] BirdyBoogleBop@lemmy.dbzer0.com 2 points 1 year ago (2 children)

So if sytemd just tells the OS what to run next where does the complaint that it doesn't "do only one thing well" come from?

[–] technohacker@programming.dev 7 points 1 year ago* (last edited 1 year ago) (1 children)

Because systemd (the project) extends more than just systemd (the init system). It also includes things like:

  • systemd-journald (system logging)
  • systemd-timesyncd (Network Time Sync)
  • ~~NetworkManager~~ systemd-networkd (network interface/connection management)
  • systemd-homed (Home directory management)
  • systemd-resolved (DNS Resolver)

and so many more

Now, in my personal opinion, I do find it good in that these being under one umbrella project led to fairly good integration between these aspects of "system management" as a whole. But I do also concede that this may feel like too many responsibilities handled by one project

[–] cdombroski@programming.dev 3 points 1 year ago (1 children)

NetworkManager (network interface/connection management)

Pretty sure you mean systemd-networkd here. I find systemd-networkd to be very nice for headless systems, but NetworkManager seems to be a better fit for desktops because of the integrations it has available with KDE/Gnome/system tray

[–] technohacker@programming.dev 1 points 1 year ago

Ah I figured I had that one wrong, thanks!

[–] jsveiga@sh.itjust.works 1 points 1 year ago

It doesn't do "only" that; I was comparing it with other init systems and described their main, basic init functionality. Sorry if I didn't do it well.

[–] thisbenzingring@lemmy.sdf.org 16 points 1 year ago

In a very basic description, systemd is your system schedule agent. It's the component that kicks things off in order so all the vital parts start in order so they have the other parts in place before they load.

It's reputation is muddy because it's doing more than a single task and old fashioned thinking is that system components should only do one thing. It's easier to configure but harder to understand than the older init

[–] jecxjo@midwest.social 15 points 1 year ago (1 children)
[–] TCB13@lemmy.world 6 points 1 year ago (2 children)
[–] jecxjo@midwest.social 4 points 1 year ago

Soon systemd will include a feature where it replaces the user and does all the computing for you.

Systemd basically is what starts up other processes. You don't need systemd, but you do need some init manager. Kernel loads, then calls up the init manager to load everything else. Anything you want to make run on startup gets added to the init manager.

[–] fr_mg@lemmy.world 5 points 1 year ago

I have been a Linux user since 2000.

All your chat is about technical issues, and both sides allways talk about the technical pros and cons of each system.

But i remember reading when debian team changed to systemd the arguments included these: 1- now Linux works like Windows and we do not like it. 2- now all depends on the systemd team, while init gives more freedom, so started devuan. 3- init and systemd can do the same but...here all the technical blah blah. By the way, if devuan exists and works well... 4- last and not least, systemd lets lock out the system (distro).

I am not an IT guy, just an user...so an ignorant. My questions: are those statements still valid or wrong? Even today the number 4 gets mi confused, it is, or was, a real reason?

Sorry my wording, my first language is not English.

[–] Mysteriarch@slrpnk.net 4 points 1 year ago (1 children)

It's main purpose is to make some die-hards angry, I think.

[–] Shdwdrgn@mander.xyz 0 points 1 year ago (2 children)

After fighting with multiple network devices today, I feel like I have a right to be angry. Checking the info in dmesg what I see is that the system initially sets up all six NICs (two on the motherboard, four on a card) in the correct order with eth* names. Then something else comes along a couple seconds later (which I assume is systemd) and renames everything to enp* NIC names. If I move the card to a different slot or install a different card with the same model then all those enp* names change to something different, but dmesg still shows their initial eth* names in the expected order before being renamed.

"Predictable" names are anything but, and now you can't even use the standard udev naming or even put link files under /etc/network/interfaces.d/ because all that stuff has been changed again so now I have to move all the link files to /etc/systemd/network/. I don't know how anyone considers this a good thing when the convention keeps changing every few years and I actually have to do extra work to put the names back to what linux originally called them at each boot. Where does the madness end?

[–] TCB13@lemmy.world 2 points 1 year ago (1 children)
[–] Shdwdrgn@mander.xyz -2 points 1 year ago

Oh god, does anyone still use NetworkManager by choice??? How would you even use it from the command line? I just configure the interfaces file by hand.

[–] greyscale@lemmy.sdf.org 1 points 1 year ago (1 children)

There is a grub argument to pass to the kernel that disables that renaming behaviour entirely.

[–] Shdwdrgn@mander.xyz 2 points 1 year ago (2 children)

Yep I'm aware of it. Seemed like it worked for a bit, then reverted back to the enp* names. And then all the pages I was finding for manually renaming the devices said to put the files under interfaces.d for deb11 but oddly it only seemed to read those link files for a few reboots, then it would revert back to the enp names. Found something about using OriginalName because the name changes were overlapping, that worked for a few boots and then reverted back to the enp names. So then I found something about a Path statement using the full pci device names, and THAT worked for a few boots and then reverted. So now I found out that the link files have moved to the systemd/network folder so I'm waiting to see how long that lasts...

And I realize it sounds like I'm talking about a system I've been running for years... I actually just put together this machine last Thursday. I had to start with Debian 9 because I couldn't get any newer memory stick images to boot (this machine doesn't have EUFI support), upgraded to deb10 and everything was still working as expected with the grub lines to disable renaming. Upgraded to deb11 and it all went to hell. I'm having some serious thought of trashing the machine and switching to deuvian now even though I really want to support debian.

[–] Kangie@lemmy.srcfiles.zip 1 points 1 year ago (2 children)

Servers are cattle. Take it out the back and shoot it then find a less terrible server.

[–] Shdwdrgn@mander.xyz 2 points 1 year ago (1 children)

Uh... there's absolutely nothing wrong with the hardware, it all works exactly as it should. It's just systemd's insistence on rearranging things that aren't broken, and then changing how you fix the problems it created.

[–] greyscale@lemmy.sdf.org 2 points 1 year ago (1 children)

Have you considered Devuan a fork of Debian specifically intended to remove systemd.

[–] Shdwdrgn@mander.xyz 3 points 1 year ago

I have actually. I saw the post for their latest release earlier today and had been seriously considering switching over. This new machine is to replace my existing firewall as the old one has gone through several upgrades since Squeeze, so I'm trying to get something set up to rebuild everything from a clean installation and then I can simply swap out the hardware (and swap it back real quick if something doesn't work right away).

[–] greyscale@lemmy.sdf.org 1 points 1 year ago

Tell that to windows sysadmins. Windows would reaaaaally like to be treated like a pet. I feel for them.

[–] greyscale@lemmy.sdf.org 1 points 1 year ago (1 children)

Did a system upgrade overwrite your grub config?

[–] Shdwdrgn@mander.xyz 2 points 1 year ago (1 children)

No the changes for "net.ifnames=0 biosdevname=0" were still in there. Those worked fine for debian 8, 9, and 10 (with adjustments made in udev rules to rename eth4 and eth5 to wan0 and wan1), but neither option seemed to have any effect after upgrading to deb11. When I went searching for renaming the devices in deb11, the first several articles all stated to create link files in interfaces.d, but after all the trouble I went looking further and finally found one that referenced putting the link files in the systemd folder. I just linked the files so they are available in both locations, and that change has continued working for several further reboots so I'm crossing my fingers.

[–] greyscale@lemmy.sdf.org 1 points 1 year ago

Ah, they might have killed that option in newer kernels. Vaguely remember something about it being a temporary fix, I guess its time has come.

[–] Synthead@lemmy.ml 3 points 1 year ago* (last edited 1 year ago)

From man systemd:

DESCRIPTION
       systemd is a system and service manager for Linux operating systems. When run as first process on boot
       (as PID 1), it acts as init system that brings up and maintains userspace services. Separate instances
       are started for logged-in users to start their services.

       systemd is usually not invoked directly by the user, but is installed as the /sbin/init symlink and
       started during early boot. The user manager instances are started automatically through the
       user@.service(5) service.

       For compatibility with SysV, if the binary is called as init and is not the first process on the
       machine (PID is not 1), it will execute telinit and pass all command line arguments unmodified. That
       means init and telinit are mostly equivalent when invoked from normal login sessions. See telinit(8)
       for more information.

       When run as a system instance, systemd interprets the configuration file system.conf and the files in
       system.conf.d directories; when run as a user instance, systemd interprets the configuration file
       user.conf and the files in user.conf.d directories. See systemd-system.conf(5) for more information.
[–] TCB13@lemmy.world 1 points 1 year ago
[–] jman6495@lemmy.ml 0 points 1 year ago* (last edited 1 year ago)

You are asking the wrong question, my friend. You should be asking what doesn't systemd do?

[–] mrhh@discuss.tchncs.de -1 points 1 year ago (2 children)

What exactly does systemd do?

Too much.

[–] voidskull@lemmy.ml 12 points 1 year ago (1 children)

But makes your life easier, especially when you're a noob.

[–] 30p87@feddit.de 5 points 1 year ago

Not a noob and I'm still using it everywhere, because it helps making Arch "just works".

[–] skullgiver@popplesburger.hilciferous.nl 3 points 1 year ago* (last edited 11 months ago)

[This comment has been deleted by an automated system]