LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   What are the advantages/disadvantages of using systemd versus sysvinit? (http://www.linuxquestions.org/questions/linux-general-1/what-are-the-advantages-disadvantages-of-using-systemd-versus-sysvinit-4175422544/)

ReaperX7 08-17-2012 12:13 AM

What are the advantages/disadvantages of using systemd versus sysvinit?
 
Was looking into this, and I'm still confused as to why a stable init toolkit is being replaced with one that isn't as well known and trusted, so readily by Linux distributors.

If sysvinit isn't broken and is only marginally slower, why replace it much less any other working init system that isn't broken? It's like trying to fix something that doesn't need fixing.

What are the REAL advantages of systemd, and not just stuff from gossip and hearsay, mis-advertisements, and over-speculation, and what are the REAL advantages of continuing in using sysvinit or even BSDinit and Upstart?

Skaperen 08-17-2012 12:31 AM

The different init systems offer different advantages. These different advantages play out differently in different cases. I would refer to them as "static init" and "dynamic init", although that is likely a gross oversimplification. The advantage of static is explicit control. The disadvantage of static is the administrative difficult of figuring out the correct ordering, especially when packages are added and deleted. In many cases the static init model is suboptimal because the administrator does not see a shortcut, or because time waits are used where controlled waits otherwise could work. A dynamic init generally can start faster, but even it can have problems if the dependencies are not correctly and completely specified. The overlapping activities in rare cases may make dynamic init slower (increased disk seek contention).

IMHO a dynamic init is better for desktops where reboot speed is more important, and packages get changed more frequently. A static init is better for servers which just don't reboot very often, especially when a load sharing group has other services to cover the init time. But variations on this can exist. A given administrator may be not skilled or confident enough in tweaking init script and choose a dynamic init where another administrator would choose a static init.

I do find it disappointing that a simple and easy way to choose between these does not seem to exist within a distro.

Edit:
You do appear to be a Slackware user. If you are seeking to justify your usage of its static init model, go right ahead. That's one of the reasons I prefer Slackware, especially for servers (and hopefully soon for cloud instances).

ReaperX7 08-17-2012 05:42 AM

The lack of choice is something that could be addressed by not just the maintainers of distributions, but as the Linux community as a whole. By eliminating choice, we, I feel, violate the purpose of what Linux is about. Freedom of choice.

Edit:

I use a variety of systems actually, but I do prefer software that is tried and true with stability, and often at times I have not found that with some distributions.

So really what are the full lists of advantages and disadvantages of systemd and sysvinit, other than speed? Also, isn't systemd very similar to the init system used by Mac OSX?

linuxxer 08-17-2012 08:22 AM

My opinion is:
Systemd is just another feature Fedora wants to add in the feature list.
While designing Systemd, they collect all boot related features and add them into one single system.
I belive in UNIX philosophy, so I like Slackware and Debian.
Init is most important process in whole Linux system, so keep it small and make it more stable.

Like Skaperen says, Systemd may helpful for desktop.
But If I want to tweak my system then Sysvinit or BSDinit is best choice.

I think you may like to try this links:
http://www.jonmasters.org/blog/2011/...o-why-systemd/
http://monolight.cc/2011/05/the-systemd-fallacy/

sundialsvcs 08-17-2012 02:27 PM

What I appreciate most of all are real, well thought out alternatives.

You do have "a choice." In fact you have several compelling choices. That's what so great about Linux.

Obviously, distro writers are going to "choose one for you," because that's what distro writers are tasked to do. So that by-and-large it just works the way it's supposed to, without you having to think deeply about the choices that they made on your behalf.

ReaperX7 08-17-2012 05:23 PM

Actually as a desktop user, I care more about a system that is stable and works rather than something untested and unproven. I have files. Important personal files that, if lost, could be a problem if a system isn't bootable or doesn't boot correctly, and in the past I have lost files with certain distributions because they favored unstable software and unstable system tools.

Having a desktop system shouldn't mean sacrificing speed for stability. Far from it. The stability of server systems is what brought Linux to the desktop in the first place. If a server can be stable, can the desktop be equally stable?

Just because Red Hat issues a battle cry on the latest stuff, doesn't mean that everyone has to use it. It's a shame to see so many distributions choosing speed over stability for desktop systems.

Not only that, Lennart Peottering, his ideas and mindset, after reading his manifesto, isn't following the UNIX Philosophy Doug Mcllroy laid down at all with his software. His software does do one thing, but it hasn't done and doesn't do it well on any level. Dare I say, people like him are poisonous to UNIX as a whole.

Mr. Alex 08-20-2012 03:05 PM

After installing and activating systemd /etc/inittab will no longer affect booting, right?

DavidMcCann 08-21-2012 02:06 PM

Does anyone actually have any evidence for systemd being unstable? Can something used by Fedora, Mageia, and OpenSUSE (and available for Arch and Debian) be described as untested? People complain that I have a down on Slackers, but some of you do sound like the tinfoil-hat brigade on occasions! Incidentally, if you look you'll see I'm not a user and hence not an advocate (save for a sense of proportion).

Skaperen 08-27-2012 08:27 PM

Quote:

Originally Posted by DavidMcCann (Post 4760284)
Does anyone actually have any evidence for systemd being unstable? Can something used by Fedora, Mageia, and OpenSUSE (and available for Arch and Debian) be described as untested? People complain that I have a down on Slackers, but some of you do sound like the tinfoil-hat brigade on occasions! Incidentally, if you look you'll see I'm not a user and hence not an advocate (save for a sense of proportion).

I've not actually tested systemd, so I don't know if it is stable or not. I'll have to take the word of others because I have no intention to even try it. If I were to know it is not stable, of course I could point to that.

But for me, I just don't want to use that style of system initialization. I prefer critical things to be explicit. I want to know exactly what is or is not happening to the system, and I want to be able to look at the init code and be able to clearly see it with as few jump-arounds between files as possible. And I am willing to trade off the ability to just install something new that needs to be started at init time and have it automatically set up, just to have this explicit control. In fact, I don't want anything new to be started implicitly.

If your goals are different than mine, there should be no surprise if you choose a different way of things. IMHO, being able to make these choices is part of what makes Linux so great. We are not forced to completely choose one whole system or not, as is the case with Windows and I suppose also with OS X.

unbeldi 10-21-2012 07:15 PM

I think the interesting question is not really whether the new SYSVinit replacements, such as systemd are 'stable', but whether they actually accomplish anything better. systemd appears to be stable, in the sense of not crashing or failing inadvertently.

It does represent a definitive clash with UNIX philosophy of writing simple modular reusable components without 'featurism' baggage.

The goal of the author, and this is evident from the home page of the project, appeared to have been to make as many specialized operating system or kernel features available as possible and making thus the argument why anyone would NOT use something so sophisticated. I am sure they are proud of their programming effort, it just seems much misdirected energy.

I find this question quite more compelling: why would one not use something that has withstood the test of time, is extraordinarily simple to use, setup, and maintain and only uses methods, i.e. the UNIX shell, that are present on every UNIX-like system? This is certainly the SYSVinit framework. No extra *nix-knowledge is required to customize the startup behavior of services. Try this on the layers of extra configurations, XML formats, whatever..., with systemd. It's a canned, inflexible, obscure system.

For administration, nothing is simpler than SYSVinit, no special tools are needed to display, for example, the boot sequences of services for any run level, and I am not even talking about chkconfig tools, which were already a fancy addition to the original SYSVinit.

Surely, SYSVinit has some shortcomings in certain aspects, any established framework does. But those could most likely be fixed within the existing scheme. Some improvements for fast-booting desktop systems are clearly needed.

These distros now convert established sysvinit scripts to their chosen obfuscation method, and it hasn't made anything easier.

TobiSGD 10-21-2012 07:38 PM

systemd:
- Fast boot time, mainly achieved due to starting services in parallell. This can also be achieved with SystemV init, but has to be done manually, while it is a product of dependency handling on systemd.
- Automatic dependency handling.
- Monitoring of started services with the ability to restart crashed services.
- Modules written in compiled languages, probably hard to debug.
- Tries to replace several system services, from the actual init over hardware recognition and session management to the logging service, and many more. Not the Unix way.

SystemV:
- Boot time depends on the admins optimizations.
- Due to its static dependency handling relies on a knowledgeable admin. Decide for yourself if you count that as advantage or not.
- Needs often some hacks to monitor services, services can easily escape the monitoring.
- Written as Shell scripts, so easy to debug and alter if necessary.
- Minimal approach, doesn't try to be the one super-service running the system.

But anyways, it is not the function of systemd that is so controversial. People couldn't care less about just another init system, if it weren't for the aggressiveness with which it is forced onto the market as the one and only right solution for Linux init systems, totally against the spirit of open source and the Unix philosophy, closing out the BSDs (and Debian GNU/kfreebsd) and marking them as irrelevant and toy OSes.
In the future there will be no udev for OSes without systemd (udev was integrated into the systemd development and Lennart Poettering wants to cancel support for running it outside systemd as early as possible), Gnome will be dependent on systemd and I think many others will follow.

linuxxer 10-22-2012 11:22 AM

I am using Slackware, But I like to try different distroes.
I have Fedora and SuSe Linux DVDs.

When everything is normal every program works normally.
Nothing is great.
But when some UNEXPECTED problem occure, that time it is very difficult to handle.

For example,
Consider situation - Improper shutdown of entire system, like power failure.
When you next time restart the system, one server refuse to start.

That time it is very easy to read init-script and check each and every step.
And within few minute I am able to start the server.

Systemd starts server directly, Unit file contents path to binary and some command line options.
But if server need some kind of prepartory work, for that purpose it runs application program which is written in C.
That time it is very difficult to find the problem. Go through the C file, and try to find problem.
After that compile the source code, install it then check it and then try to start the server.
This means for long duration your server is down.
Such kind of boot speed is NOT important for ME.
In Systemd everything happens parallely, so it is very difficult to track.

Another example,
If I want to modify the system that time it is very easy to work with init-scripts.
If I compile differnet kernel versions with different patches.
And I want to maintaint different sysctl.conf file for each kernel.
When system boots as per `uname -r` I want to use different sysctl.conf configuration.
So within few minitue I am able to modify /etc/rc.d/rc.S init-script.
After that, During system bootup just use arrow key to select kernel.

Whether this is right/wrong, I don't care.
But if I want to modify my system in this way then it is very easily possible for me.

If you want to just use the Systemd then its OK.
One day if you decide to make changes in your system that time you will face real difficulties.

I want to say, If you use Systemd,
You will lose total control of your system.
You are NOT able to solve the problem EASILY by your own.
You are NOT able to make changes EASILY in your system.
You will become only user of the system.

BSD style init scripts are very flexible.
Systemd - you have to use system in predefined-way.

Systemd developers, they are making complicated things more complicated.

Red Hat Enterprise Linux is commerical product.
And Systemd is commerial Linux feacture.
For Red Hat, Systemd is very useful feacture.

Systemd, BSD style, Sysvinit style is just different approach.
Which one you like, its just matter of personal preference.
Nothing is right/wrong in it.

Systemd is good for desktop system.
OR tablet kind of computer,
low configuration and boot speed is very important.

I like to use Slackware Linux.
And I don't want Systemd in Slackware.

I like to use very simple system.
System which I can able to manage.

And sorry for BAD English (if I made any mistake).


All times are GMT -5. The time now is 09:04 PM.