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.

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

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.

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

Once the kernel has loaded itself, it needs to start up userspace as well. This is usually (perhaps exclusively) done by starting an 'init' program as process number 1, which then starts up all the other userspace programs: systemd is no different in that regard. It solves a variety of problems that traditional inits have, though:

• rather than having near-incomprehensible shell scripts to start, stop, etc. all your programmes and services, it uses INI-style service files which are merely fiddly. They're kept in a few logical places, not 'everywhere'

• starting and stopping services is done with simple, consistent commands - systemctl enable tomcat will start the Tomcat webserver at next boot; start, restart, stop and disable do basically what you think. Shell scripts are... less predictable, especially between distros.

• rather than having to inspect all of your scripts and work out what order they start in, SystemD just lets you declare what they depend on, and it works it out for you - much simpler, much more robust.

• rather than needing a separate tool to manage scheduled events (usually a chron-like, like anachron), SystemD just lets you write a 'timer' with the same syntax as its service files. They can be set to only trigger based on other events, like start-up, so you can do once-an-hour database snapshots (but only if the DB is running) very easily. That's painful with traditional inits.

• also manages disk and network mounts, so you don't need a separate tool for those, and you can trigger other events off of them as well. That was also painful in older inits.

• and power events too, if you want to trigger other tasks before sleep or when your laptop wakes up. (Again, was painful before.)

• log files all in one place and controlled in the same way and accessed with one tool - again, traditional inits aren't like that.

• (advanced usages) works well with cgroups, so if you're looking to limit the CPU time on a web service and make sure that it only uses its share of memory, that's dead easy. Very difficult with traditional init.

You can get a reasonable idea of what systemd is doing with a systemctl status at the command line; shows you the overall system status, with a nice tree view of what's running and what caused it to start. Getting that kind of overview on a eg. SysV init is much less simple.

Administrators and devops generally love it; it's very simple and straightforward and consistent and predictable. Certain devs dislike it, due to the original author, or feelings of overreach and complexity (although it's much simpler than learning everything that it replaces), or because they're attached to Bash scripts. (You can trigger Bash scripts with SystemD if you like, but they're not 'in control'.)

Linux is based on unix, which was an operating system designed to run on computers like the PDP-11 of the 1970s.

The problem is that computers have changed a lot, and Richie and Thompson couldn't perfectly forecast all those changes. Most notably, it predates the internet.

Anyways, computers changed and so systemd was invented to copy MacOS Tiger's launchd service model. Here's the only video you need to watch on the subject

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

Why should you care? Tech diversity is good, and people can try out different approaches. Aside from that, there’s not a reason. Systemd is a really good desktop init.

What is init freedom? It means the init system can be changed without other software breaking because there is a dependency on some functionality of the init. In this case, a dependency on systemd. Although it’s probably a dependency on a subproject under the systemd umbrella rather then systemd itself.

Why systemd? It’s tailored to weirdnesses in the Linux kernel. The Linux kernel isn’t perfect, and it’s user land isn’t tied to the kernel. Systemd is a shim which papers over the oddities. I don’t remember which oddities, but they’re there and people ignore them.

Were there dumb decisions made? Yes, especially for the server side. I should test out some other inits for servers, but it ultimately works fine.

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.

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.

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.

It does everything you might think of and much more https://tadeubento.com/2023/systemd-hidden-gems-for-a-better-linux/