The fact that enough libraries and parts can be stripped out of systemd only makes it less and less necessary as a whole. We already can strip udev, as well as keymaps, gudev, and the gobject files (otherwise known as the udev-extras), so realistically if these are the only required parts of systemd needed by other software, why do we need the rest of the mess to replace sysvinit?

My question is a logical one:

If LFS based and other minimalist systems do not need or require the whole mangled mess of systemd and only require a few ripped out parts, why do we need systemd at all on the whole?

It doesn't make sense to bloat a core system with a utility set that serves zero purpose other than management services which can effectively be done via another service at less costliness to the system resources.

1 members found this post helpful.

While not necessarily a fan of systemd, there are features of systemd that are difficult to do. I mean you could try to write your own "systemd" that controls certain common resources and creates the relationships between resources and deamons, etc... and does monitoring and auto-restart, etc...

But at the end of the day, you might well end up with a better "systemd"... which is certainly systemd-like...

It all depends on what you actually "need". I think the idea of a sysvinit style system suits many people's needs... so the act of forcing, or at the very least, coercing a change... well... that's probably where most of systemd's problems reside (apart from all of the bugs and the fact that replacing shell scripts isn't quite as trivial as once believed).

Things I don't like may have more to do with the "common" implementation. The goal was to "standardize" the initialization process...

So I find that systemd fires up things unexpectedly... the implementation (the targets, etc.) makes too many wild assumptions about what "everyone" wants. And I don't think it's a one shoe fits all world... but again, realizing that is more or less one of the stated goals of systemd.

So... maybe it's like this...

Red Hat/Fedora engineers are not good script writers (never have been).

They hate scripts, they can't write them, etc... (and there are some very big closed source players that want to see the end of busybox, etc.).

Therefore, replacing sysvinit and init scripts *must* be the problem to be solved.

Sure... there are many other things that systemd tries to *solve*... but a lot of it again is based on assumption.. especially when talking about the "standard" deployment goal.

I guess what I'm trying to say is that at the end of the day, I'll likely have to do more work to "fix" the default configuration of a systemd box than I would an old sysvinit box.

Maybe "job security" is also a goal of systemd??

5 members found this post helpful.

Whatever the driving motivation, I think that this is right on the mark...

None of the purely technical arguments in favor of systemd seem to hold water. And all of the excellent arguments in favor of Sys V init seem to be summarily ignored...

The reason: none of those are the problem addressed by systemd. But if systemd had elimination of Sys V init itself as its goal... well, here we are...

If that's the case then Red Hat/Fedora engineers need to be seriously evaluated on their ability to using basic tools of a Linux operating because script writing is technically a basic of the basics of Linux 101. My God, who hired these people?

You can't even pass a CompTIA Linux+ exam much less CompTIA A+ exams without understanding how a script works. I should know because when I took the 601/602 A+ exams a few years ago, I got asked about 10 questions on scripting.

To be perfectly honest, they should be fired for not knowing how to write the most basic of basics of functionality, or at least sent back to college to take a remedial course on understand operating system scripts.

Scripts are a core feature not just of Linux, but every major operating system uses scripts in some shape and form regardless of how you look at it. Even the Windows Registry Hives are basically one huge set of scripts.

According to these developers' flawed logic of wanting a script-less system, by containing everything for a program in a C code framework that doesn't rely on a script, you take not just setup out of the picture, but troubleshooting as well. On paper it works fine, but in reality it's completely stupid and idiotic. You might as well not even have a program because if something screws up, you have no possible way to fix it. Once it's compiled and installed into the system, there's no way to fix it other than chrooting in from another system, resetting the code framework in the source, rebuilding, reinstalling, and rebooting to test and hope and pray it work, or else its back to the drawing board.

BusyBox isn't even a mainstream toolkit. Yes it's a compact composite of various GNU/Linux tools, but realistically it's mostly targeted at embedded systems, systems that are too small to have any benefit from systemd and any other init system.

1 members found this post helpful.

you guys really thing strange about systemd and the purpose of it.

1. systemd is a service manager
2. you can directly control cgroups, cpu, memory scaling and distribution in the service files.
3. you can give services restricted access to parts of the system.
4. autorespawn

for point 4 an example, you are connected by ssh, and your ssh dies. your socket is still open, you just aare unable to complete 1 command, so when the ssh service restarts you are back.

5. killing programs.
If you want to kill apache, you dont only kill apache, but you kill all programs that have been started by apache (cgi, php)
this is impossible on classic sysvinit

Which of those 5 things are not like the other?

1. Services are for Windows, Daemons are for UNICES.

2. Yes, but those already exist in modularized form that already work well enough especially libcgroups.

3. Already exists through permissions management.

4. When daemons shut down, they shut down for a specific reason. Auto-respawning them is not the best recourse to management. When a daemon is shutdown, it often should stay shutdown because there could be a problem such as a security breach, error, or memory leak. And actually if SSH is shutdown, that port should not exist any longer because the daemon has stopped. Even then if you have a proper security implementation such as a firewall, the firewall will detect if the daemon is active or not and control access to the port.

5. Learn proper scripting and script management and you'll know how to shut down a daemon without using "kill" with the PID codes, or even xkill, and even then if you can't read PID codes, you should learn to. Laziness is not an acceptable excuse for anyone. You, in general, wanted to use Linux, which has some of the best documentation of any operating system, so, you need to read.

systemd already can be effectively duplicated by combining various software in existence:

OpenRC can effectively perform the same actions if not more and it's not as intrusive into the system and doesn't create a proverbial dependency hell causality loop.

SysVinit when combined with udev, udev-extras, libcgroups, runit or s6, and existing utilities can do the same stuff. Even then you can substitute out sysvinit for runit or s6 and get the same results for much less system resource usage. Plus, it's modular and if one part goes down, it doesn't bring down the entire system as a whole.

If libcgroups crashes, then the system still functions and libcgroups manager can be restarted.

If runit or s6 falls, it can be restarted.

If udev falls, again, it can be restarted.

The only lynch-pin is sysvinit, but sysvinit is very stable and doesn't do much, and having it crash, is fairly rare.

If systemd crashes even at one point, you not only loose daemon management abilities, but the console, the system resource manager, the init system, cgroups, various other things like udev and disk management, and pretty much the whole entire system collapses.

It's too big to fail, and if and when it falls, it's big.

UNICES were designed to be modular against the monolithic design Windows had originally. Windows NT only has barely started to embrace the fact that the system can be broken down into various services that don't have to be all intertwined and interconnected. You can even restart the GDI now without rebooting which has been a huge difference.

Why of all things would Windows NT go from a monolithic design to a modular design like UNICES have? Because modular works better and ensures that if a daemon falls, it can be troubleshooted, restarted, and work can continue without bring down the entire system as a whole.

So in that regards, why would it be better to go from a modular design to a monolithic design where if one thing falls, the whole thing falls apart?

1 members found this post helpful.

All this tells me is that it is written from the perspective of a Microsoft developer.

I can already control these things without systemd.

There are already ways to restrict daemons' access to different parts of the system, without systemd.

SysV init already gives me two ways to accomplish this -- I can either have an rc script which backgrounds, starts its daemon, and loops when that daemon exits, or I can write a respawn rule directly into /etc/inittab (Slackware's inittab respawns agetty this way, for example).

This is far from impossible. It is basic UNIX knowledge. All processes have a PID and a PPID. Writing a shutdown script which kills all child processes (whose PPID is the same as the targeted PID) is easy-peasy, and does not actually involve the init system.

Perhaps Poettering finds it easier to write systemd than learn how UNIX works?

3 members found this post helpful.

Just my opinion, but Lennart seems like one of the most laziest and clueless developers for a Linux based project like systemd in that he knows nothing about the operating system he is intending it for. Not only that but him and Kay Seivers both should be seriously called into question in their abilities to do anything for Linux as both are about as bad as the other, though Kay seems to have his head more glued to his shoulders, though he has nearly incurred the wrath of Linus Torvalds from time to time with udev being a "broken piece of sh*t" according to Linus.

I could get around the issues with the *Kits, udev, udisks 1 and 2, and about all the rest as they have proven useful. But systemd has proven to be anything but useful if not just a redundancy against existing software that can be completely independent of everything.

I see thread marked as SOLVED. Does that mean sysvinit has been improved? Or all you guys are just fanning the flame to bump post counts? :P

guys, complaining here about Poettering is pointless.
you should tell the facts RedHat so that they know wherefore they spend their money
and when doing this, also suggest them to use your knowledge and your solutions to solve their problems and needs, possible this will get you a cool job.

1. my wording as service manager should be service/daemon manager.

2. and yes, setting cpufreq, cgroups, memory is possible. with other programs off course.

3. same as point 2 actually

4. the respawn, will that keep your existing connection for example open.
Lets say you use SSH, and sshd crashes.
currently, your connection will get lost. and yes there might be tools out there that prevents you from loosing your connection.
with systemd, your socket is still active, so you get a could not execute command response, and a sec later when sshd has been respawned, you can keep on working without loosing your connection.

5. I have 1 apache PID, from there 1 cgi PID (parent is apache) and some other scripts which has CGI as parent.

Maybe a good point to watch: https://access.redhat.com/site/videos/403833

And dont get me wrong, systemd still has alot of improvements to do.
but talks like memory and cpu footprint are so 2011.

as seen here, even my sshd takes more.
and in this case sshd is running through a unit/service file by systemd, which spawns the daemon.

I do love the classic SysVinit.
However like a real Linux/Unix user you should always look at alternatives.
The strongest point of systemd in my opinion is there journal.

it is directly started, even if you have a kernel panic, you can still read the journal with a live CD.
where ksyslogd, rsyslog and those logging daemons are not starting untill your boot is further down the line.

The people who decide, if Red Hat gets lots of money, are usually not the people who have to administer and use that stuff. That's how corporate IT usually works. It's just the same with Microsoft Windows and Oracle Solaris.

Red Hat wants systemd. Full stop.

But design decisions inside the Windows and Solaris projects have almost no effect on Linux. So if MS screws up, we can happily live on. On the other side you get the impression, that Red Hat has not only the right to decide the direction of Fedora, but of every Linux distribution under the sun.

cgroups are actually simple
kernel.org/doc/Documentation/cgroups/cgroups.txt

arnt there other ways of finding out why a system didnt boot ?
like booting to busybox or bash instead of init

edit: funny is that kay sievers, the systemd codeveloper, wants to make cgroups less user friendly

No... a real Linux person would want choice, look for the lowest costly solution that is minimalistic, modular, and user/admin-friendly.

Linux already has tools to do all you're asking, and extras can be added with RunIt, S6, OpenRC, and other software that is not as invasive, hostile, and overtaking as systemd is.

You still haven't really answered the question about the modularity of what exists currently versus the monolithic design of systemd.

How is the monolithic design better when if systemd crashes and disrupts the whole system and everything is taken out, whereas in a more modular design of sysvinit plus various other helper programs where if one thing fails, it can be easily examined, restarted, etc. were as I said having sysvinit to crash is a RARE occurrence.