I've been seeing your videos pop up a lot recently. You have a much better historical understanding of how/why these systems work and it definitely shows in your explanation of things which leads to a much higher quality video than a lot of other people on UA-cam.
I can not express how much I like your channel which I recently discovered and the way you teach us all that knowledege you've acquired during your life. Thank you, thank you, thank you. Keep up the good work.
The only thing I like more than this video and topic is the fact that you're giving it in a Green Lantern shirt. You are channeling from a truly deep place. Thank you so much for doing the UA-cam thing. It's generosity beyond measure.
Thanks Mike...In brightest day, in blackest night, no evil shall escape my sight. Let those who worship evil's might beware my power… Green Lantern's light!
Thanks for the content, to be honest when I see you teaching I remember my grandpa teaching me something and then talking about how he became the teacher who once was teaching him.
nice to finally find you grandpa. you have some awesome stories and just hearing about old linux, file formats and softwares just makes my heart warm up. keep kicking.
Systemd is very simple compared to the botched old world of SysVInit with init scripts... That's why all Linux distribs maintainers adopted it so fast.
@@MaximilienNoal I wouldn’t necessarily call a project with 1+ million LOC simple compared to a bunch of shell scripts 😉 I’m not a fan of SysVInit either tbh.
Back in the early days of the Macintosh, Alan Kay said a system should be designed so that “simple things are simple, and complex things are possible”. With sysvinit, simple things can be quite fiddly to do. As for complex things ... don’t expect them to work reliably. With systemd, it really is simple to do simple things. And it manages to get complex things working reliably, too.
"... I'm not going to talk about Unix too much even though eunuchs played a large part in the early days of how Linux worked..." I know this is going to be another amazing video, but my mind got stuck on the automatically generated transcript and its historical revision. Seriously, thanks again for another very informative video.
Small corrections: 1. The kernel does know what init to run - it has a command line option for that, b and in the old days we used to override the init program name to circumvent a normal startup, for example to reset the root password. 2. The entire discussion of orphaned process is so wrong... Ughhh... From the top: a process is created by forking (that was described more or less correctly), then runs to completion - whether or not it's parent had died before that (no, orphans are never killed prematurely), when it is done running it turns into a zombie (immediately, there's no walking involved - the process exits back into the kernel, where the kernel marks it as a zombie so it knows never to schedule CPU time for it. The zombie label is important because the parent would often like to consult it's child's process table entry to figure out things like exit code and cause of death. Then it's the responsibility of the parent to reap the zombie - i.e tell the kernel that the table entry is no longer needed. For orphans - someone still needs to do the reaping, and it has always been PID 1's job to do that, and still is under systemd. 3. The naming of scripts in /etc/rc.d was designed so that the SysV init scripts just read the runlevel dir and execute all the scripts there in alphabetical order - the K and S prefix don't get special treatment, they were just chosen to make sure that all the "kill actions" run before any of the "start actions" due to K sorting before S. The K before S order was chosen so that if in a runlevel there are both K and S scripts of one specific service, the service will first be killed by then started again, so making sure services are preferred to be running. 4. There were a lot more init products offered during the "init proliferation" period of Linux - not just OpenRC and upstart. The table shown in screen shows a few of them (notably runit wasn't mentioned, though it was very important at the time) but there where many more, such as supervisord and tini, some are still surviving in container environments.
umm ok, but didn't you have to define which application to use as the init? The kernel did not know until you defined which one to run, so will stand by my statement, and thanks for adding this bit of info
@@CyberGizmo ok - when you said "the kernel runs /sbin/init because it doesn't know what process to run" I assumed you mean that the path is hardcoded and the kernel doesn't care which init software you use a long as it provides /sbin/init. But technically you could have multiple init systems installed and choose one on boot (I'm not claiming that is a sane setup 😅).
As a runit user, I find systemd mind-boggling to use. With runit, I just start processes and keep them running... that's it, that's all I need my init to do.
@@folksurvival That's exactly what systemd does too. It can restart things for you on crashes if you want to, or restrict resources, run services on timers, socket activation, and more, if you need it to. If you don't need that, it can also just start a process and keep it running until you tell it not to. I want my init system to be able to take responsibility for the things I tell it to manage, and keep them in line, so systemd suits my use case very well. I've not used runit, but I've also not had to look elsewhere.
From the title, I said to myself, I know all that, then when I finish the video I realized it full 80% of that I do not know about, DJ I can only say .. Well Done!
Run levels are great. I still use init 0 or init 6 sometimes symlink or not as long i don't ont have to write a paragraph to shut down or restart the system. I really love your knowledge and look forward to learning new things from your channel.
So like all the rest systemV is great as long as you don't have to do any work lol. The systemd developers say they same thing and like you they don't want to do the work of maintaining systemV for the reasons they clearly state if you bothered to do even a minimal education on emerging technology.
@Leopard lol. I have no clue what your point is. I just like shorter typing on the cmd line. I'm not in a production system, so I'm going to do it the way I want . If im in a production system, I'll follow standards. Otherwise, Path of least resistance.
very informative. I 've run some pre-systemd distros but didn't had much of awareness. systemd felt well organized for (re)starting services/daemons over other systems and it was easier to write units for stuff that didn't come with their own. lately it felt that it "eats" stuff which led me to see the "systemd or not systemd" conversation that happen for some years now. cleared some grey areas on my understanding and you kinda explained to me the reasons i am trying to go away from it. possibly an openrc approach (as i firstly saw that on archlinux i think) is what fits more my use-cases of system. Thank you, sir.
🎯 Key Takeaways for quick navigation: 00:00 *💻 Introduction to SysVinit and Systemd* - SysVinit was the traditional init system in Linux, responsible for system initializationd managing services. - SVinit had limitations, such as its serial execution model and lack of support for dependencies and parallel startup. 00:44 *🗺️ The Boot Sequence and Init Process* - The boot sequence starts with the BIOS/UEFI, which loads the bootloader, which then loads the kernel. - The kernel starts the init process (PID 1), which is responsible for system initialization and service management. - The init process can be different systems, like SysVinit, Upstart, or Systemd. 01:53 *🔍 The Functions of the Init Process* - The init process handles the later stages of the boot process, configures the system environment, starts processes for logging in, and cleans up after terminated processes. - In the pre-Systemd era, the init process would inherit orphaned processes and try to shut them down. 03:47 *🕰️ The SysVinit System* - SysVinit, also known as SysV or System V, was the traditional init system used in many early Linux distributions. - SysVinit organized the runtime environment into a sequential set of stages called runlevels, which had to complete before the next one could begin. - This sequential execution model led to slow startup times and issues with dependencies and conflicts. 09:41 *🔀 Alternatives to SysVinit* - After the limitations of SysVinit became apparent, alternative init systems emerged, such as OpenRC, Upstart, and Systemd. - OpenRC introduced parallelization and improved dependency management, while Upstart was developed by Canonical for Ubuntu. - Systemd, developed by a Red Hat engineer, aimed to address the shortcomings of Upstart and became widely adopted in the Linux ecosystem. 16:46 *🌐 The Systemd Init System* - Systemd defines services as "units" and allows for more flexible and dynamic management of dependencies and system state. - Systemd replaces the runlevels of SysVinit with "targets," which group units together to define specific system states. - Systemd is designed to be more responsive to changes in the system environment and can start services based on events, not just a predefined order. 24:28 *🌟 Pros and Cons of Systemd* - Pros: Faster boot process, more flexibility, standardized configuration files, and additional advanced features. - Cons: Concerns about feature creep, potential security risks due to running as a user process, and violation of the Unix philosophy. 27:08 *🗺️ Critique of Systemd's Design Approach* - Systemd's design approach has limitations, particularly in its tightly coupled nature and interlocking dependencies. - Tightly coupled systems are undesirable as they make it difficult to integrate with other applications and are prone to breaking. - Systemd's "all or nothing" strategy makes it challenging to replace or use it partially. 27:48 *🧪 Potential Issues with Systemd's Adoption* - Systemd's tight coupling to the Linux operating system may create challenges if Linux were to decline in the future. - There are ongoing concerns about the support and security of Systemd as it has grown increasingly complex. - The departure of Systemd's lead developer, Lennart Pottering, to Microsoft raises questions about the future direction of the project. 29:38 *🛠️ Systemd Configuration and Resources* - Systemd provides flexibility in configuring various components, such as setting up custom targets, units, and configurations. - The best manuals on Systemd are available in the Red Hat repository, which can be used as a resource for further exploration. - The speaker encourages the audience to explore the Systemd topic further by checking the recommended resources. Made with HARPA AI
More than a thumbs up! This is a five star tutorial! Personally I have no preferred preferences over Systemd, SysVinit, OpenRC. On my Archlinux systems (systemd) if I want to start or enable a printer all one has to do is sudo systemctl enable --now cups. Or stop bluetooth sudo systemctl stop bluetooth.service. On my ssh Gentoo installs from a host computer I use the OpenRC. Just boot the target machine with a USB thumb drive. Create a password for root. Use ifconfig command for a ssh ip address. Once boot into usb start the OpenRC rc-service sshd start to provide the connection for any host machine to issue commands from a terminal . From installation notes, or from the Gentoo wiki web page installs. I've done just recently a SysVinit install (LFS) Linux From Scratch which was very time consuming. But the install was successful. Example: -- linux: /etc/init.d # ./sshd status -- or linux: /etc/init.d # telinit 3. Yes -- Systemd might have some down falls but for the user the commands are simple and easy to remeber. So what am I using as of this moment? Slackware 15. Also a non systemd init system which you have stated in a video that "Slackware 15 is a Linux closest to a Unix system.." Slackware is an excellent and stable Linux. But I must say that my Archlinux and Gentoo system boxes are very reliable as well. :) Lot's of init system choices, other as well and much to learn.
I have worked with multiple init systems and I must say I love systemd. It makes writing of units very straight forward and easy. In contrast to those scripts in rcX.d directories, it's very simple and straight forward. Declare a name, dependencies, tell it what to start, how to start it, how to kill it, define what to do on failure, etc. Everything is on one page of text with minimal scripting. The interface with systemctl and service is very intuitive and simple to use, setting services up for startup or starting them manually is easy, with autocomplete and everything. I don't understand why people cry about it. Yes, it does come with a lot of features that might not typically be part of the startup, like dns or timers. But you can just not use those features and continue using cron.
Thanks Don. This channel is a gold mine. 👍 Thanks for getting back to the roots and explaining in detail why something exists/existed and how it works.
Very useful summary of the issues. I can assure you however that BSD users are not at all keen on SystemD coming over, so that's one less thing to worry about!!
Systemd never fixed anything that needed fixing in system initialisation anyway - it's a bloated piece of redundant software for "fashionistas". I don't use much *BSD (though like it for what it is) but I've used Gentoo Linux for almost 20 years now and have stuck with "openrc" as its default initialisation system that "just works".
Remember that systemd is more than just “system initialization”. Linux is a very dynamic environment, where services can be started and stopped at times other than system boot. systemd is designed to cope with that.
I thoroughly enjoy these video essays. I feel like I soak up something new almost every time. Personally I’m a Mac user, and those have tended to be my main machines have been since System 6 or 7, with an exception being a short period when I used Linux. I have also been using Solaris, BSDs, and several Linux flavours. When I started learning more intimately about the inner workings of computers, I did do that on Solaris and Linux machines so I really only feel properly at home in the unix-style systems. I did go back to Macs for my primary machines when they launched their OS X series, where I could feel at home and still have access to the commercial software I needed for work and studies.
After writing my own startup scripts for SysVinit, writing my own units for systemd was too easy. Now I have moved all of my crons to systemd timers, also - both as root and normal users.
5:47 It’s worth clarifying what the whole point of this “parent/child” relationship, and consequent possibility of “orphan” processes, is about: when a process terminates, it becomes a “zombie”, which means it still takes up a process slot, even though no process is running any more. At this point, it is up to its parent to pick up a notification of the termination of the child, via a call like wait(2) or similar; once it gets this notification, then the zombie process disappears, and that process slot is freed up to hold a new created process. So, if you write a program on Linux or other POSIX-type system, and you spawn lots of processes, then you have to remember this rule to avoid your system running out of process slots: always gobble your zombie children.
Outstanding video with great history and information! I've been using some flavor of Unix since 1983, and I really don't like systemd. SysVinit is what I'm used to, but openrc is pretty good. I like tiny programs that interact rather than "full-featured" systems that try and do everything.
I use a combination of Init processes on my network. Choice weighs on the role of device. Is it a server? General Desktop? Specialized application desktop? Firewall? I recently built out an old ambulance into a mobile home. There are 8 custom computers as part of the build which tie into my 24V solar system. The OS loads into ram very quickly and does not suffer any damage to data or hardware if power cycled. systemd is not a part of this design i went with OpenRC. Each INIT has it's own strengths and weaknesses.
10:42 Fun fact: Debian used to use runlevel 3 as its normal mode of full multiuser GUI login. Which just goes to show how wonderfully inconsistent sysvinit could be. With systemd, all runlevels (now called “targets”) are identified symbolically, so you don’t have to figure out what cryptic numbers mean, because there aren’t any.
But there are cryptic systemd commands that you have to learn, and make no logical sense. For the record, I can speak with considerable expertise on systemd due to having a day job for the past 20 years of building, administering and hardening Red Hat (Enterprise) Linux servers - I don't like systemd at all but my knowledge of it pays the mortgage. My home environment consists entirely of Gentoo Linux machines (since 2003) and openrc is far more simple and logical for starting services that "just works". Systemd is bloated, illogical and these days treated purely as a "fashion accessory" in Linux where half the users stand under the "systemd" flag shouting at everyone else stood under the "systemd is entirely unnecessary because it doesn't fix anything that needed fixing in system initialisation" flag.
@@lawrencedoliveiro9104 "Which commands are you referring to? They are all there for a purpose." On openrc, all I need to use are: /etc/init.d/[service name] start/restart/stop/status That's it.
Excellent video! You did a great job of explaining why many Linux distros moved to systemd. The structure and commands are slightly more complicated than good old sys5init, but clearly necessary. I started reading the Red Hat resource you linked, thank you!
A small correction regarding the zombie processes: I think they are a bit different from what is described in the video. When a process forks itself, the parent is given the child's PID, while the child sees 0 as a result of the call to fork(). The parent then can wait for the child to terminate and it can read its exit status. But what would happen if the child terminates before its parent has called `wait()/waitpid()` on it? The kernel needs to do 2 things: 1. it needs to preserve the exit status, and 2. it needs to preserve the PID until this status has been read. It does that by storing the exit status in the process table and by marking the entry as zombie. So a zombie process is just the entry in the process table of a process, who's already terminated. The entry will stay there until its parent process waits for it. If the parent terminates without checking on its children, the child process can remain a zombie forever. It doesn't take any memory or CPU resources, but it takes up this entry in the process table. This used to happen in earlier versions of linux, but now there are mechanisms to prevent this, but I'm not sure about the specifics. I think the re-parenting of child processes to PID 1 is part of this and also probably the zombie-walker that was mentioned in the video, but these are just guesses on my part.
No, UNIX had a subroutine which reaped zombie processes, it was called the zombie walker as I described it. Here is a link for you. medium.com/coding-in-simple-english/the-fear-of-zombie-processes-8d2f00449795 Zombie processes could not remain a zombie for longer than the zombie walk timer on UNIX. Linux has the kthreadd process which takes care of orphaned processes, don't confuse the two, they are not the same things.
Ivan Toshkov is right, DJ Ware is wrong. Note this part from the linked article: “When orphan processes die, they do not remain as zombie processes; instead, they are waited on by init. The result is that a process that is both a zombie and an orphan will be reaped automatically.” Note that only applies to orphan processes. Non-orphaned zombies cannot be automatically reaped; their parent process must do this.
@@CyberGizmo I wrote a small C program to test this: #include #include #include #include #include int main() { pid_t w, pid = fork(); int wstatus; if (pid == 0) { // we're in the child process printf("[CHILD] Terminating with status 7. "); exit(7); } else { // we're in the parent printf("Let's see if we get a zombie. Enter the following command in another terminal without pressing ENTER here:
"); printf("ps ax | grep %ld ", (long) pid); printf(" You should see that the child process is marker as [zombie] Now press ENTER: "); getchar(); printf("We are now checking for the child process return status ... "); wait(&wstatus); printf("status = %d ", WEXITSTATUS(wstatus)); printf("Now the zombie process is gone. You can check with the above ps command. "); printf("This process will still be active until you press ENTER. "); getchar(); exit(0); } } This program demonstrates the zombie process. It will stay as zombie as long as the parent process hasn't read its status. [EDIT] I just read the Medium article that you liked to and it describes exactly what I'm saying. There's no special "reaper" process, unless you count init as such. That the zombie is reaped as soon as its parent wait()s for it. If its parent terminates without waiting (orphan process), the child process is re-parented to init. And init will wait for it right away, thus "reaping" the zombie.
@@lawrencedoliveiro9104 Thanks. I assumed something had changed, but you've confimed it works as expected. I just spent 5 mins trying to get this thing to come and kill an orphaned process I intentionally created: john@buckbeak:~$ perl -e '$\=$/; $pid=fork; sleep(1); sleep(1) unless($pid); print $pid; sleep(1);' # experiments trying to get killer to come to sleeping child 6934 0
The real motivation behind systemd Fact 1: systemd is from Red Hat Lennart Poettering and Kay Sievers who started the systemd project in 2010 are both Red Hat employees. Initially systemd was released as a new init system, but it has slowly grown into what Poettering describes as "a suite of software that provides fundamental building blocks for a Linux operating system." This is by design, not by coincidence. The official reason for the development of systemd was described as: They wanted to improve the software framework for expressing dependencies, to allow more processing to be done concurrently or in parallel during system booting, and to reduce the computational overhead of the shell. Fact 2: The primary reason for developing systemd is Red Hat's business interests in embedded devices Red Hats primary business is in embedded devices, and the primary concerns addressed by systemd by design is embedded devices, such as the work towards removing /etc. In an interview with Red Had CEO Jim Whitehurst he states: We partner with the largest embedded vendors in the world, particularly in the telecom and automotive industries where stability and reliability is the number one concern. They easily adapted to systemd. Mentor Automotive has released their slides from a 2015 event In these slides the many benefits provided by systemd to the embedded automotive market is fairly well explained. The reason why they "easily adapted to systemd" is because systemd is specifically designed to suit their needs. The U.S. Military has been Red Hats biggest customer since 2002 and they have been a major source of motivation behind many of Red Hats decisions. In 2012 Lennart Poettering changed the systemd license from GPL to LGPL in order to better suit the embedded market. Fact 3: No, it's not a myth, systemd is truly a huge monolith In his blog post "The Biggest Myths", from January 2013, Lennart Poettering argue against calling systemd a "monolith", which is what many people consider it to be. Lennart says: A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle. The fact is however, that many of these so-called individual binaries has functionality that simply will not work without other systemd components. If we take a look at the man page for systemd-networkd it clearly states that if you set the option UseDNS as true the DNS servers received from the DHCP server will be used and take precedence over any statically configured ones. This corresponds to the nameserver option in /etc/resolv.conf. What the man page neglects to mention is that this setting (and multiple other settings) does not work without systemd-resolved. Other components of systemd are even more tightly integrated. Fact 4: Privacy concerns systemd-resolved has hard coded fallback DNS servers for Cloudflare, Quad9 and Google. Even if you turn these off, a bug might cause these to be used anyway (which actually happened at one point). Fact 5: Red Hat wants to become the next Microsoft Windows This is another major motivation at Red Hat and this is illustrated by Lennart Poetterings slides from FUDCON + GNOME.Asia Beijing 2014. Go to page 15 and scroll slowly forward to page 19. 0pointer.de/public/gnomeasia2014.pdf Eventually you end up with the project objectives: Turn Linux from a bag of bits into a competitive General Purpose Operating System. Build the Internet's Next Generation OS. Unifying pointless differences between distributions. Bringing innovation back to the core OS. Combined with the next set of slides that display the market Red Hat want to target: Desktop Server Container Embedded Mobile Cloud Cluster Much of the added functionality that the different systemd modules provide has zero benefit in the server industry. It is only added to make desktop systems like GNOME and KDE function like Microsoft Windows. Fact 6: Red Hat needs other major Linux distributions to cooperate If Red Hat was ever going to succeed in their long term plans for developing the "Internet's Next Generation OS" they knew they needed to somehow influence the other major Linux distributions. The reason for this is that if a major Linux distribution like Debian was going to reject systemd, Red Hat wouldn't be able to proceed with their plans because too many third party projects simply wouldn't care about how Red Hat would like things to work. This is very important to understand because many open source projects used to develop software with POSIX compatibility in mind. As such they try to make sure that their project compiles and works on several Unix-like operating systems. This is something that isn't in the interests of Red Hats. As long as you have to consider other operating systems such as Solaris, FreeBSD, OpenBSD, etc., Linux is "held back" when compared to functionality in Microsoft Windows. Functionality such as easy mounting and unmounting, simple privilege escalation, etc. Another problem for Red Hat was that if the other major GNU/Linux distributions had rejected systemd, it would have become much more difficult for them to get systemd relevant changes and code pushed into the kernel. But when the other major distributions also adopted systemd, it became a lot easier. Consequences The main problem with systemd is that its continued development is motivated by a company's economic interests and not the open source Linux community interests. Red Hat cannot be trusted from a security point of view and if the U.S. Military, or some other three letter organization, wants Red Hat to put a backdoor into systemd, then this can easily go unnoticed for many years, just like it did with the Heartbleed bug. And we have already seen several examples of these kind of exploitable bugs in systemd: Create a user called '0day', get root privs - not considered a bug! Remote Code Execution For Two Years Systemd Bug Lets Attackers Hack Linux Boxes via Malicious DNS Packets www.theregister.com/2017/07/05/linux_systemd_grants_root_to_invalid_user_accounts/ it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years Whether such bugs are introduced into the code on purpose, disguised as honest mistakes, or they truly are real mistakes, is impossible to tell. But one thing is very clear, Red Had do not have the Linux communities best interests at heart, they only have their own financial interests at heart. Another major problem is the previously mentioned hard coded DNS servers in systemd-resolved. Lennart Poettering explained that the hard coded values should be there in case of catastrophic failure of configuration files, and a lack of DHCP on the network (the DNS fallback is changeable but requires a recompile). However, that's the "embedded developer" speaking. If a bug is found in the application that makes these DNS servers run even though you have disabled them, or if a race issue bug is found, you could be facing a serious privacy issue. Furthermore running with Cloudflare, Quad9, and Google DNS servers hard coded into the systemd code is deeply problematic as these companies are not only known for violating peoples privacy, but also because NSA has previously infiltrated Googles data centers, something revealed by the Snowden documents. Such settings should never be opt-out (where you have to remember to remove them), they should be opt-in, and definitely not the default options. The way these issues are dealt with generally, and the extremely arrogant attitude of Lennart Poettering shows a complete disregard for user privacy and for the interests of the open source Linux community. Final comments It has surprised me that the initial discussion on the Debian mailing list somehow managed to only address SysVinit, Upstart and systemd. Nobody took a serious look at runit or s6. Not only are these systems much more aligned with the Unix philosophy, but they are also much more secure and easy to understand. Casper Ti. Vectors post on the Gentoo forum, s6/s6-rc vs systemd, or why you probably do not need systemd, also shows that s6 is a better and in many ways superior solution to systemd. forums.gentoo.org/viewtopic-t-1105854.html Many people mistakenly think that each and every systemd component is independent, but that's just not true. Take a look at the code and the documentation and see the tight integration between many of these so-called modules. www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ Corporate politics, maneuvers and manipulations has no place in the community driven open source projects. And while companies can be allowed to both use open source code, contribute code and also provide financial support from their earnings on these projects, they should never be allowed such massive control as Red Hat and others now have. Thank God for truly independent community driven projects, because without those we're left with crap like Microsoft Windows.
This explains the Red Hat paid shills attacks on Canonical/Ubuntu when they tried to go their own way some time ago. Might see it happen with System76 with their popos project. Already seen some attacks done with their own firmware update system.
That is not a review of the technical merits or lack of systemd it is an anti corporation anti red hat rant. Red hat can not force Debian to do anything. You will have to ask the Debian developers to explain their reasoning but my guess is after a preliminary review of the options they decided to consider the best 3. After their review they went with systemd. The logical conclusion is systemd is the best option for Debian. You can not make baseless accusations against corporations or Red hat without some evidence of which you have none thus your claims are baseless. At the end of the day people have to earn a living and the simple truth is that Red Hat continues more than any other distro to the kernel and Gnome because they earn a living. If you want an alternative either do the work yourself or pay someone to do it for you. There are a plethora of volunteer linux groups such as GNU / GUIX Debian arch etc and neither Red hat or Microsoft has any control over them nor can they shut them down. No one is forcing you to use Red Hat nor any of your baseless claims to this effect. You should be appreciative the Red Hat developers are communicating their thoughts and intentions as they contribute to progress. If you don't like it use GUIX or one of the Libre distros.
@@leopard3131 It is naïve to think RedHat or M$ or any other company can't force others to do things. They have more than enough corporate money to do that...
I find it amusing that systemd still claims it's faster, when in actual fact distros I've played with that uses either OpenRC or Runit boots much faster - on the same hardware. Oh well, some distros are better optimized than others I guess. In any case, I prefer OpenRC for its simplicity and the fact it's never got in my way. Seems to do exactly what it's supposed to with no fuss. Interesting video anyhow, glad to get some more insight. This is a topic I've never delved into really, so it was educational. :)
Faster at what? Sure you can build a simple system tailored to your personal needs and it is fast but have you tailored systemd the same way and can you post benchmarks? Even if you can such a claim is not going to be true over all use cases and as there are more and more complex tasks then systemd will be faster for the reasons the developers give. This argument is also uneducated and irrelevant.
Great insights, thanks for that. I'm comfortable with sysvinit and have accepted systemd as a practical necessity, as you say for events such as networks coming and going, displays disappearing, etc. I don't like its network handling, or in fact I'm frequently confused by what is going on with networking lately. I think I like the netplan concept though. For things that I like to have running and keep running, just a plug for supervisord - let systemd handle all the system stuff but have supervisord take care of the applications.
re: pros and cons: - I would have liked to hear a discussion of socket activation and possibly about the launchd origins of systemd. - The thing with interlocked dependencies and systemd requiring to be used a a whole or not at all - this is simply not true: all the systemd parts are optional, you can use just the init service without any other part, or use any part without the init service (not that it makes any sense). For an interesting discussion of systemd, its strengths and weaknesses - from the perspective of a BSD developer - and it goes deep into some of the social aspects of systemd development, rise to fame (add possibly future downfall), I recommend reading "The Tragedy of Systemd" by Benno Rice. I don't agree with everything written there, but it has a lot of nuanced discussion that is often missing from the rhetoric of the "Systemd bad... SysV good" camp. The main thing I, personally, have to say about the social aspects of systemd is that as a systemd fanboy, I have to agree that Poettering is a particularly annoying fella.
The definition of tightly coupled or loosely coupled is not defined by how it interfaces to its own components but rather how it easy or difficult it is to interface to external applications and external services. Try replacing systemd with any of the other init packages and let me know how well your system is running for you, and while you are at record the amount of time you need to spending fixing external services that are so dependent on systemd they will no longer run, and while you are at that record the number of hours before you give up in utter frustration trying to stitch your system back together to make it functional. That is how one measures tightly coupled, not by which systemd processes you add on or you can turn on and off. I am not trying to lash out at you, but I spent many years working with UNIX and the sometimes the people who wrote it. Minds much smarter than I will ever be, but the one thing the Bell Labs team impressed on me was making your code composable, so that it could be easily adapted quickly (and i mean in days, not months or years), or how parts of it could be lifted out and reused in other totally unrelated projects with simple interfaces, simple data structures that were easy to grasp, do you really think systemd fits the tenets of the UNIX Philosophy? If you really understand those, you would come to realize just how simple and elegant the progenitor of Linux was. Perfect? No, Composable? Yes. The systemd debates are long over, and we are stuck with it, but as an old developer I know it could be a lot better, a lot smaller, and a lot easier to maintain...its truly a shame Poettering didn't listen to us, but some people have to learn the hard way.
@@CyberGizmo I completely disagree, with just about all of that - I grew up in the (not that much) older days of maintaining SysV scripts by hand (often those that came with the OS and were insufficiently stable) and systemd service management architecture is not only a massive improvement on that, it is better (often much better) than any other service management that aimed to replace SysV (and I managed production services on all those you mentioned in the video and more). Granted, the fact that systemd provides useful capabilities over a more "classic" service management framework, and then applications taking advantage of that to provide better behavior (DBus activation anyone? How about nanosecond-resolution task scheduler? User services? Service namespacing? etc), can be looked at as detrimental to the ability to replace systemd (in whole or in parts), but why should we be stuck in the past with limited capabilities when we can do better? And *all* of systemd APIs - whether internal or external - are accessible and made available through standard files or DBus (which is not part of systemd and should be a requirement for an OS to call itself modern Unix), so should be easy to implement by competitors. IMHO systemd developers - as a systematic approach - build tools that are always optional and any non-classic capability they offer is clearly and publicly spec-ed in a way that it can be re-implemented by alternatives. Were there mishaps? For sure! But as a whole - if you believe that systemd is wrong in pursuing a new style of system management that is coherent, featurefull, and more than the sum of its parts - then I believe you are on the wrong side of history.
It is very easy to interface existing applications and services to systemd. An example of this sort of thing popped up on the Waikato Linux User Group list a few months ago. I found this systemd service file in an online forum that someone had written to automatically apply a certain charging profile to their laptop battery on boot. The actual command was a single line of shell script; the rest of the dozen or so lines were directives defining when and how to run the command (e.g. specifying that it was “oneshot” invocation, so there would be no ongoing running process after the command had done its job). I reposted it because I thought it was a good example of the simplicity of systemd. Somebody more familiar with sysvinit tried posting an init.d-style script to do the same thing. It came to be about 50% larger, all but one line of which was just boilerplate.
@@lawrencedoliveiro9104 I am not saying sysVinit is superior to systemd. I chose sysVinit for comparison, because it was the primary init process in Linux prior to systemd. Don't shoot the messenger. As for the 50% larger comment, meaningless to me, would need more information, like how proficient is the programmer, what language was used, and what OS was being used. For example on FreeBSD 12.x it takes one line to enable and start a system service. As for the design of systemd...its much much larger than the init program it replaced, and all to do parallel startup as it original goal? I would call it a cannon to kill an ant.
Can I be a little out of the context of the video? I enjoyed very much your HAL-9000 and the " Discovery " panel messages as a screensaver. 2001 is my favorite movie ever.
I'm mostly in the FreeBSD camp, and for me, the fact that SystemD can't easily be ported to FreeBSD is a good thing. I much prefer BSDInit. Yes, Debian boots faster on my hardware than FreeBSD, about 1 second on my hardware vs 10 seconds for FreeBSD. But that really isn't a big deal. Rebooting isn't something I do very often, and when I do, 9 seconds isn't going to make that much of a difference to the overall downtime impact. Maybe it is just that I'm a lot more familiar with FreeBSD than other systems, but I find that creating a new service in a few lines of shellscript in FreeBSD is a lot easier than trying to wrestle with SystemD.
As a Linux embedded developer I work with systemd on my development machine and luckily have not to go to deep into its configurations. For the embedded targets I usually use buildroot to tailor the system which uses a sysv style to boot the embedded system. For me it is easier to add our services to init.d to get them running.
As an embedded developer you don’t have to worry about dependencies, since you can provide all the necessary ones in your installation image. Heck, you could probably put all your necessary startup/shutdown sequencing in a single rc.local-type file and dispense with sysvinit altogether. systemd is designed to cope with much more complex, dynamic and variable situations.
Where is the boot sequence video? Maybe you can give us link about your previous video everytime you mentioned it.. just little pro tip here.. I really like the diagram approach you write btw.. Very good at giving me the big picture of what's going on..
Let me see if I understand correctly. Systemd started as a Canonical project, then was reimagined by IBM/RHEL which doesn't respect the community and basic principles of UNIX, has a lot of bloatware-complexity like Windows and now the main developer works for Microsoft? Sounds good
Launchd, the service manager I've been used to for almost two decades on Apple(-clone) machines, could have deserved a mention in this video of yours with which I agree mostly.. Wnen I first tried out a systemd-driven Linux like openSUSE, my guess was that systemd must have borrowed heavily from launchd. Even if that impression may have been incorrenct (you've mentioned the upstart prelude), systemd's concepts instantly »clicked« with me. (I'm glad to say I have never needed to get my hands dirty with distro-specific, obtuse, spaghetti-style SysV-style shell-scripts ever since - at least in private. For work, it's ok, I get paid and will service any legacy stuff thrown at me.) Optional tools like journald, systemd-analyze or systemd-networkd are pretty good too IMHO. I replaced systemd-network with my custom unit file of mine, though. There goes your »closely coupled« argument, no offence. One of the biggest advantages (speed aside): any bugs get fixed once for all distros using systemd simultaneously. Contrast and compare that with the distro-specific scripting out there, that accumulated during almost three decades. Nevertheless, here's hoping systemd will be replaced with a even better service manager soon - maybe one that's portable between *BSD, macOS and Linux. Cheers!
I debated including launchd in the video, but thought it deserved its own video. Yeah, I agree it would be great to see a cross platform system manager.
Your impression is pretty spot on with regard to launchd. In fact, I think you may not have sufficiently expressed how heavily it borrowed from launchd, as it was what influenced Lennart to give up on trying to fix upstart to be what they wanted, and instead created systemd. They just didn't use XML formatted configs, and opted for an ini style instead. Of course it grew from there, and diverged fairly significantly from launchd.
I can take or leave systemd, *except* for the systemd-journald non-text-file thing you mentioned (and you can kind of substitute in syslog), and the fact that the systemd developers decide for you that they will ignore your pager settings and truncate the logs at the edge of the terminal instead of wrapping (or respecting your pager settings) when you use their log viewer (journalctl). They definitely have a "screw you, we're writing what we want" attitude.
I don't think the systemd developers ignored pager issues. Start journalctl with --no-pager or set the environment variable SYSTEMD_PAGER to whatever you like.
@@danespen5772 Yeah, and it took me half an hour to find the SYSTEMD_PAGER environment variable in the source code. I now set it to FRXMK as a habit, but they should leave the default pager alone, and use optional obscure settings to modify from the defaults rather than require them to get back to defaults.
@@danespen5772 BTW, there was an argument about this in 2010 or so and they decided to go with their personal preferences for pager behavior as a default.
@@DennisGentry I started journalctl, pressed "h" and it was revealed that journalctl was using less. It may be passing a flag you don't like to less, but it's using less.
I started watching but had to pause, as I quickly got lost digesting the comment section below (I'm just a noob about to do a test run, dual-booting 2 versions of MXLinux on an old Acer laptop with a new SSD; both Xfce but one with SysV and the other straight-up systemd ((praise Satan!)) to see how they compare). The tech-talk, conflicting views and politics of this comment section was utterly fascinating to me, illuminating. _Now_ I'm gonna watch the video lol...
Very nice rundown on how system booting works! I'm a Debian linux user, but I wish we'd stayed with SYSV init, or even the older BSD /etc/rc style system. I hate two things about systemd. First, it violates what I, personally, consider to be one of the basic concepts of UNIX... .having small tools that can be used together to accomplish large tasks. By trying to pile everything into systemd, it creates a monolith that is fragile and hard to work around. Secondly, systemd seems to have been designed to make life simpler for large corporate environments where you want to deploy hundreds or thousands of machines to all behave alike, and thus having a simple template-based system is useful. For me, I have to constantly fight with the systemd "unit" system to get it to do what I want, whereas the older init system was a set of shell scripts that could be as simple or complex as you needed them to be. So, while I understand the appeal of systemd for one subset of uesrs, I'm not happy that almost every linux distribution out there feels that it has to push this onto everyone that uses it. However, I'm used to not getting my way. After all, I liked the Sunview desktop and hated X11. :)
I personally think systemd sticks more to the "do one thing" philosophy than most think. It's not one monolith but several parts working together, optional, allows for better resource controls, and a heck of a lot less complex to interact with than the spaghetti init scripts of old. Sorry to hear you're having problems and having to fight it, that has not been my experience at all. For me it's a lot easier to see how any new service I want o look at starts up thanks to the standardized unit files. Works just as great on my home desktop machines and servers as it does on our company workstations and servers. If you still want to use a hacky shell script to launch something, unit files still allow you to do that via the "oneshot" style, and you can even completely override what the one provided by your distribution by dropping your version in the overrides folder. Systemd even has the edit command to create those overrides for you. If you're having problems with something specific maybe I could help? I'm no expert at systemd or boot processes, but I do at least tend to get things to behave the way I want.
One of the downsides of systemd, is not the systemd itself but the users of systemd. Not the end user but, in my experience, the desktop environment developers. As an example, I don't think any DE handles a user logout. They handle system shutdowns just fine but it seems all of them end up with multiple logins on a user logout. The old session never gets stopped.
This is stunningly annoying when the workaround is to nuke all user processes on logout. Can't use Tmux or Screen on that user anymore. Just have to keep your terminal open.
@@thumbwarriordx There is actually a systemd service made just for this purpose. None of the DEs I have looked at use it though. It only stops user processes started within the logind session. The problem seems to be that the session end code is _all_ run as su and deals with systemd --system services. The session end or logout service has to be run as systemd --user.
I would argue that having processes that are tightly coupled are a direct violation of UNIX philosophy. One of the main takeaways of "do ONE thing and do it WELL" is that it can be used with other programs. That is, a "business" need can be done by simply running a specifically crafted chain of commands (programs). The "one thing" part mentioned before helps so that no matter the context, the program has no side/unwanted effects and doesn't waste resources for something you don't need. If you need something extra, it can be provided by another program or with an option. However, if your program is tightly coupled with another, well, then you don't have one program that does one thing and does it well, you have 2 programs masked as one, so essentially one program that does two things. Not being able to run a program with all its features standalone compromises its interoperability and use for composing a bigger program. Which is exactly what the UNIX philosophy stands for, whatever bigger/complex program you need, you can build it by using small dedicated programs. With systemd's dedicated programs you can reasonably build a single program: systemd itself. In conclusion, systemd is mostly a monolyth. It gets away because it does its job pretty well, it does cover most of the needs that people have. But not the concerns about its future.
composability is the key to Unix Philosophy, plus it can be understood by developers other than the creator. I dont think systemd qualifies on either of those principles of the UP either.
I recently realized, that using a dual-boot with one systemd-driven system and one without systemd (don't matter if it is Linux or Windows) does effect the clock-setting of the non-systemd system. That is somehow penetrating. And I don't know why this happens, but everytime I boot into Fedora, right after that I have to run a "ntpd -qg" on my artix installation to recalibrate the clock. Same after I boot into Ubuntu and then into Windows. On windows I will have to sync the clock again. First I thought this was a windows bug, until I installed artix with runit/openrc as init system. I find it as penetrant as some windows functions, that also have an effect on my linux system. So I hope systemd will loose importance over the time, like poetterings pulseaudio does at the moment.
Interesting! I had a similar problem in the other way around: booting into windows would cause side effects on linux. systemd doing a similar thing is the final nail in the coffin for me: it suc*s.
@Hanabishi 100% agree. The systemd topic is charged because of uneducated end users who have opinions but do not do the work or bother to keep up with the emerging technology . The systemd and Wayland trolls remind me of the flat earthers the use the same uneducated talking techniques.
@@mk72v2oq I followed the wikis, the arch and the artix wikis. And they help until I boot fedora(systemd) again. Sure, I can write a script to automate the clock sync, but I yet wonder why systemd does affect other systems clock sync anyway. If you're not familiar with it, try to replicate the problem. The dual boot is on BIOS mode. The BIOS-clock is set to the local time. If you then know something, I'm sure you can contribute more than just a bunch of smart-pretending letters. And if not, I'm sure you can be helpful in other topics.
SystemD and SysV init services are interchangeable for people with minor hacking. I Do prefer the .service format of systemD, because I can rely on the init system to manage things I wouldn't want to code.
SysV can be replaced by Openrc or runit without selling your distro to Redhat. Comparing SysV with Systemd is like comparing a Ford T with a Ford [insert a 2023 model].
I don’t know OpenRC but I’ve read and tried a bit of runit in Void Linux. It looked simple yet powerful. Then s6 came to my attention, then OpenRC, …is there an objective comparison of their design choices and implementations? Thanks
a very controversial topic, indeed.... I am not a friend of systemd, but I could imagine what Poettering had in mind - a world where most of the Linux is running on commodity workstations and laptops, with all its issues this creates (encrypted home drives etc) - and not mainly on servers (where a simple init would have been enough)... personally, I think systemd is really the wrong answer to this, but I might be biased already by all those hours of troubleshooting network and other issues related to systemd and its approaches to how to do things in the background... EDIT: and yes, I was _really_ shocked and disappointed, when a distro like Debian relatively lighthearted changed to systemd... x-(
A few simple changes in the beginning would have addressed most of the legitimate concerns about and resistance to systemd. It should have been more modular. Not insisting on being PID 1. It could easily have co-existed with sysVinit as a process manager. Implementing some sort of imperative command. Don't wait for something that will never happen, just do this because I said so. So many times I run across systemd dumping me to a shell saying a mount failed only to manually type in the mount command and it works immediately. Obviously systemd didn't even try to issue the command. Make it truly optional. There is no reason a service shouldn't just do it's best if systemd is unavailable on a given system. The developers swore it was impossible but soon after, a sort of stub library came about that mostly managed it. Don't be so grabby. There is no good reason it needs to do everything. There are daemons to synchronize the clock, to do DNS, handle network connections coming and going, etc. That is not the job of init. Every time I install a system, I have to smash bits of systemd with a hammer or the machine will be flaky.
Yup. The major problem solved by systemd was the lack of technicians with enough knowledge. Now sysadmins don't need to know how things works, they just copy/past a txt to configure a unit and systemd does the job. systemd is simply a very very very bad solution for the problem (but it gets the work done).
Again another uneducated user oblivious to the issues is shocked that progress happens even in Debian. Your lack of education does not mean systemd is bad and at least you admit you have a bias and that you have no idea what you are talking about other than your own personal opinion which is irrelevant.
@João Maria again as with all the rest of the anti systemd is the lack of education so go educate yourself. This is what any professional does often termed continuing education depending on the field.
6:07 kthreadd has nothing to do with any of this: it’s purely an internal kernel housekeeping mechanism. Remember, the semantics of userland processes is laid down by the POSIX spec, to which Linux adheres closely. systemd really makes no difference to this.
ummm no...kthreadd oddly enough runs in system space: To augment the need for running background operations, the kernel spawns threads (similar to processes). These kernel threads are similar to regular processes, in that they are represented by a task structure and assigned a PID. Unlike user processes, they do not have any address space mapped, and run exclusively in kernel mode, which makes them non-interactive. Various kernel subsystems use kthreads to run periodic and asynchronous operations. All kernel threads are descendants of kthreadd (pid 2), which is spawned by the kernel (pid 0) during boot. The kthreadd enumerates other kernel threads; it provides interface routines through which other kernel threads can be dynamically spawned at runtime by kernel services. Kernel ...
Great video, and your presentations are generally very good. Unfortunately I find the animation on the screen behind you very distracting. It is like those advertisement banner which constantly attract focus. Much better than background music some idiots use in lectures, but still.
I really don't like systemd, yeah the init wars have ended. I'll deal with systemd. But i don't have to be happy with it. Openrc is a lot easier. However, I'm currently in the planning stage migrating our servers from Funtoo to NixOS. So I'm condemned to systemd. Today I tried to deploy a NixOS flake on my laptop and it's blocking when booting up. How do I debug this with systemd? I have no idea. With openrc i could manage. Oh well. The world's moved on, so I'll figure it out.
I used to init 3 to install the nvidia drivers( after booting nomodeset), but in Fedora 36, it does not work for some reason and you have to get patched drivers.
Why? I'm not super familiar with Fedora, but in most distros you can just install the nvidia driver package like any other package at normal runlevels, then reboot or load the modules manually.
@@HenrikDanielsson I used to prefer to install the nvidia driver from them. In that case you have to disable nouveau to do it. In FC36 there is a change to the frame buffer in EFI model so it has not been resolved with the nvidia provided drivers yet.
How do you call a hanging process and gives me timeouts in dmesg logs and spawns a lot of warnings about timeout? For instance some wifi drivers freezes the whole system and you can't kill them. It's no a zombie process, the main process is running, how can we kill it (without force power off) ? - Kernel sysrq magic key for restarting the kernel doesn't do anything in this case.
I would've approached this topic somewhat differently, but this isn't is distressing as your video about X11 and Wayland. I noticed nothing that I would consider a significant inaccuracy.
System-d calls its bootloader module system-d boot nowadays. It only works on UEFI systems and overall it is a neat addition in the handful of distributions that have support for it due to it being relatively lightweight and fast compared to grub.
Damn, an awesome video. Absolutely agree on binary logs in systemd, i remember using it for the first time and wondering why i had to run journalctl to display the logs, was digging around to find the actual log files and just read those only to find out logs are binary, was like wtf, why would anyone do that xd
Binary logs are MUCH faster to process, and will also take significantly less space. So yeah, it's a pretty good change. You can pretty easily dump the logs into plain text if you actually need it, so there's no real tradeoff.
@@gogudelagaze1585 There is a change though: you have just added one more piece into your system, the log parser. Granted, most of time it is not a big deal. But in some cases it will be a pain in the ass. And on the other hand.... I can say that with processing and storage capacities nowadays, it doesn't matter to have log files in binary or text. There is plenty of processor power and plenty of storage. Now imagine: You have only one machine and it is not working for some reason. You decided to take the ssd out and look the system logs with a friend's machine. But your friend uses windows. If your logs are simple text files, no big deal. If your files are binary, you won't be able to read them.
What’s cool is things like automatic rotation, and also the fact that the timestamps are timezone-agnostic. So you can display the logs according to any timezone you like.
Well, Lennart had heard of it, and MacOS's version, and Upstart, and knew he was smarter but nobody at Redhat took him seriously, so he went on holiday and came back with the first version of SystemD. Fait-accompli.
Bootloaders and UEFI give headaches for many Linux-users. Installing a bootloader is easy enought but you can get many problems after that: custom kernels with not enough space for the EFI-partition (had that once), a GRUB-update which makes grub-customizer not work anymore, Systemd-boot which gets confused after installing a custom kernel with an invallid name, but GRUB handles it fine, good old Windows (yes, that is sarcasm) which decides to add a partition... DJ Ware, I recently saw your 2 years old video in which you claimed that Linux has plenty of less than optimal design. It would be interesting if someday you would go in depth on what you would like to see being done different for Linux or any future OS, if you haven't done that already. It seems to me that making a new open-source OS get traction should be easier than what it was for Linux because that new OS could make sure that all software for Linux runs. I don't suggest it is easy but it should not be as much a struggle as it was for Linux to get those Windows-programs to work.
It became more and more annoying , year after year for *BSD users just because so much of the software out there, starts to be dependent on systemd. For instance Gnome has some hard dependencies over systemd, which makes the life of the *BSD package maintainers literally hell. At some point, we on the BSD side, eventually will not have access to some major *nix/linux packages and that's pity. I am not going to make a tragedy out of this, just want to point out very clearly that systemd philosophy is not doing any good for the people outside linux community, even without it's direct presence.
I couldn't find anything on "zombie walker", it feels sus. In Linux zombie processes are used to hold the exit code for the process and graduates to the parent's parent when the parent ends, such a walker would need to go around killing running processes?? The other way to reap a zombie(happens for every process, they are zombie even if only for a few clock cycles) is for the current parent to call `wait` reading the exit code, pid 1(being an elder to everyone) should always be reading exit codes.
I switched from Debian/Ubuntu to Linux Mint because with systemd it did not finish booting on my hardware , Mint were even later in switching, but when they did AMD hardware worked without problems
You keep saying that systemd will boot faster than sysvinit but... Sure, sysvinit took longer to boot up back when it was being run on a P-III. How long do you suppose it would take to boot a P-III on systemd? An hour? The problem with systemd is feature creep and bloat. And it is part of the corporatization of Linux. Frankly, I don't even want to see, "The year of the Linux desktop." When I first started running Linux I started with Linux Mint 9 or 10. Everything _just_ _worked_. Man, do I miss those days. KDE was nice and easy to customize in whatever way you wanted to. Now? Not so much...
Same is true of all the systemV and Wayland trolls and the flat earth and creationism. They use complex words to make you think they know what they are talking about but at the end of the day they don't have a clue and their arguments are defeated with simple education.
@Konrad Koeppe this is an example of what I am calling a dumb comment. First what is "work better" and how do we benchmark that? Second it is next to impossible "work better" comes down to systemd considering the small part, if any, systemd plays in whatever task you are doing in user space. Then there are the thousands of apps in a typical insall the vast majority have nothing to do with systemd. And last Considing the list of distros that use systemd include arch, Debian, mint, manjaro, suse, rhel, Fedora, and ubuntu your claim becomes unbelievable as the list includes a range of distros the run the gamut from very stable to bleeding edge and arch at least is highly customizable. Thus comment is dumb and uneducated and impossible to benchmark.
@@leopard3131 I have two systems that system d based distros do not work well on. Sorry but that's a fact in my world. Various things don't work no matter the distro. Found several non system d distros and both computers work well. Not saying system d is the whole problem. I even stated it was my experience. So sad your so negative.
@Konrad Koeppe I am in no way negative I am trying to dispell the FUD people keep posting about systemd. So far we have the evil corporation RHEL crowd and the "Unix philosophy " crowd and the mystery secret person who claims to know more than the Debian technical board (or the Arch board or the Ubuntu board) and lets not forget the ones who deny the reasons systemd was built and then there are those who say well if Slackware or bsd uses it it is good with them although to my knowledge neither bsd nor Slackware have done any sort of technical review or at least not a public one and we have people like you who have some mystery problem but conclude systemd is the cause. I can at least accept the people who tinker with alternates to systemd or who are at least willing to admit it comes down to personal choice. Obviously in these 2 groups they have no need for systemd nor are they systemd experts. I did not see a single technical post here that addresses the task or problems with systemv that arise in modern computer science or business that systemd is not the best current tool as evidenced by its broad adaptation over the alternatives such as upstart.
This scheme can only work in countries with a few large firms that the govt heavily subsidizes and posess a high degree of economic nationalism. It also serves to entrench the established economic oligarchy. It wont work in the US because entrepreneurship is so high and is the engine of growth. Expecting a small firm to pay wages an benefits of a large firm.
Please don't use term "interrupt" when you mean a "signal". Parent gets a SIGCHLD signal to notify it to reap children. In general, user-space programs don't receive (hardware) interrupts. There''s an annoying term overloading. With "hardware interrupts" sent by the hardware, interrupting the program (like when receiving a signal), and likewise with signals as an IPC mechanism and signaling as an action of notifying someone. And also to some extent, software interrupts to call kernel from user-space (especially if you came from DOS programming space).
Remember when system was bricking motherboards pottering said that is not a bug Fact Red Hats main customer is the United States defense department They wanted a back door into lanix tour Falls refuse to put one in the kernal for them SO They had Red Hat do it for them in system d
Most current Linux systems choose systemd. The lightweight Peppermint used to be based on Ubuntu, which switched to systemd. Now Peppermint had its latest version based on Devuan and Debian. Debian is, the replacement, rebelling against systemd. Uncertain why so many Ubuntu based systems are now sometimes switching to Debian instead. Linux Mint is simultaneously running their Debian version, as well as their mainstream Ubuntu version (LMDE is its name). Both Mint versions are staying with systemd, afaik. There are also other Linux controversial "fashions". Perhaps someone could explain this further. Some Linux systems specialize with Gnomes GTK (GNOME tool kit). Most Linux systems choose af as ifaik, the latest version of QT. Some Linux systems offer a confusing system which use a confusing mix of both Qt and Gtk. Then the applications sometimes offer two versions of the application; over for gtk, and the other for qt. End-users like myself missy decide which of these two choices to use. This was qt or gtk choice gets further complicated, because sometimes still, the graphical display of the fonts and windows are not perfect enough. Luckily these bad displays are now disappearing.
Debian has by default been using systemd since Jessie was released in 2015, about the same time Ubuntu switched, and both are still using it with no plans to change. Regading Qt vs Gtk, you don't have to choose and both can be run simultaneously, they are just libraries used by whichever desktop environment and/or programs you want to run. Sure, they don't always look the same, but that doesn't really matter much. Some distros may only have one by default, typically the one their preferred desktop environment is based on, but you're pretty much guaranteed to end up installing both since many popular programs either don't agree with that decision or simply happened to know one of them better than the other.
You forgot various distros that do not use systemD and wrote artie instead of artix... all distros without systemD are superior compared these with shitstemD included. Also some distros like Puppy and alt linux offer systemD free version. Obarun, Puppy, Salix, Adelie, calculate linux, tinypaw linux, 4m linux, black artix, slitaz linux, Guix, heads linux, Chimera and batocera are all special distros some of them do not exist on systemD... and show some of them wherever you like search for systemctl that behaves like having systemD and 66suit that implements other inits to be more complete than systemD...
Yep, I did...however if i had listed them all most of my audience would have fallen asleep. As someone once said years ago, you can give them the books, explain the process, but they eat the pages instead. Thanks, RHTORAS.
@@CyberGizmo but you can show some of them in your channel... people do not even know some of them... and really need to learn them... it's a shame people are limiting theirselves on ubuntu arch and fedora... or even gentoo
I think you're a little off in your discussion of orphaned processes,. First, fork() is involved but exec() is not as it simply inherits the process slot. When the parent process exits, the child process is "reparented" by making PID 1 its parent. The use of namespaces complicates things but follows a similar approach. When a process is reparented, it does *not* get a signal, it just keeps running. If the parent died because a signal was sent to its control group, often done with control-C, and the child is in the same control group, it will get a signal, too, which might kill it. Zombie processes are processes that have exited but whose parents have not "reaped" them, i,e. the parent has not issued a wait() that returned information for the exited process. Since the init process spins waiting for orphaned processes you will practically never see one in a zombie state.
> When the parent process exits, the child process is "reparented" by making PID 1 its parent Not true in today's Linux. The closest ancestor which has its PR_SET_CHILD_SUBREAPER flag on becomes new parent of said process.
POSIX behaviour is indeed for PID 1 to become the parent of orphaned processes. Linux offers some extra options, in the form of the prctl(2) call, to modify this, if you want. Otherwise the POSIX behaviour is the default.
Umm, just to be sure, I rechecked the POSIX spec, and it doesn’t actually say anything specifically about PID 1. All it says is that the parent is initially the process that created the child, and that “After the creator’s lifetime has ended, the parent process ID is the process ID of an implementation-defined system process”.
"Responding to events" is the only feature of systemd that I find potentially useful. And also potentially dangerous. On the one hand it's certainly useful to be able to trigger responses to changes in the environment. However, I have enough experience of Windows mysteriously launching tasks that I didn't ask for, without explanation or even an easy way of diagnosing, that often cause serious issues, and they're so heavily obfuscated by the "convenience" of automation that I'm rendered helpless and at the mercy of Microsoft. Windows is exceptionally good at automating it's own destruction, and with it my time and data. I would much rather forgo this "convenience" and retain full control of the system. And that, sadly, is the only thing that's even remotely interesting about systemd. The fact that it has assimilated the entire Linux ecosystem is an absolute travesty. It doesn't surprise me in the least that Poettering defected to Microsoft. They were made for each other.
I've been seeing your videos pop up a lot recently. You have a much better historical understanding of how/why these systems work and it definitely shows in your explanation of things which leads to a much higher quality video than a lot of other people on UA-cam.
thank you hotshot, appreciate the very kind comment
coz he's brilliant compassionate & generous
@@CyberGizmo it's not just a kind comment, it's also 100% true!
I can not express how much I like your channel which I recently discovered and the way you teach us all that knowledege you've acquired during your life. Thank you, thank you, thank you. Keep up the good work.
The only thing I like more than this video and topic is the fact that you're giving it in a Green Lantern shirt. You are channeling from a truly deep place. Thank you so much for doing the UA-cam thing. It's generosity beyond measure.
Thanks Mike...In brightest day, in blackest night, no evil shall escape my sight. Let those who worship evil's might beware my power… Green Lantern's light!
I could listen to this guy talk for hours just listening to computer engineering history. 😊
Thanks for the content, to be honest when I see you teaching I remember my grandpa teaching me something and then talking about how he became the teacher who once was teaching him.
Thank you Amir
DJ is our wise Linux grandpa 💪😎
Yet another excellent video full of interesting and informative information.Thank you DJ.
Thanks Higher Self
@@CyberGizmo I am a big fan of overcoming the physical being and getting to the higher self 😜 that is real CONTROL
me and all my homies fuck wit aliens
grey, purple, green, white, black, orange etc
nice to finally find you grandpa. you have some awesome stories and just hearing about old linux, file formats and softwares just makes my heart warm up. keep kicking.
3:11 Not as far as I know. PID 1 is not automatically restarted if it dies; not only that, if PID 1 is ever terminated, your system goes down.
Thank you for a very balanced and clear presentation of a highly charged topic.
Well this is a loaded topic 🙂 great video as usual. As an avid BSD user, I am glad for the simplicity afforded by a BSD-style init.
Systemd is very simple compared to the botched old world of SysVInit with init scripts... That's why all Linux distribs maintainers adopted it so fast.
i know, but I like walking in mine fields :)
@@MaximilienNoal I wouldn’t necessarily call a project with 1+ million LOC simple compared to a bunch of shell scripts 😉 I’m not a fan of SysVInit either tbh.
Back in the early days of the Macintosh, Alan Kay said a system should be designed so that “simple things are simple, and complex things are possible”.
With sysvinit, simple things can be quite fiddly to do. As for complex things ... don’t expect them to work reliably.
With systemd, it really is simple to do simple things. And it manages to get complex things working reliably, too.
@@m1k3e You're not counting LoC for shell itself and lots and lots of other utilities these scripts are using.
"... I'm not going to talk about Unix too much even though eunuchs played a large part in the early days of how Linux worked..."
I know this is going to be another amazing video, but my mind got stuck on the automatically generated transcript and its historical revision.
Seriously, thanks again for another very informative video.
LoL, praise the eunuchs!
Nice to know that Winnetou or hopefully at least a Karl May fan is laughing with me.
Small corrections:
1. The kernel does know what init to run - it has a command line option for that, b and in the old days we used to override the init program name to circumvent a normal startup, for example to reset the root password.
2. The entire discussion of orphaned process is so wrong... Ughhh... From the top: a process is created by forking (that was described more or less correctly), then runs to completion - whether or not it's parent had died before that (no, orphans are never killed prematurely), when it is done running it turns into a zombie (immediately, there's no walking involved - the process exits back into the kernel, where the kernel marks it as a zombie so it knows never to schedule CPU time for it. The zombie label is important because the parent would often like to consult it's child's process table entry to figure out things like exit code and cause of death. Then it's the responsibility of the parent to reap the zombie - i.e tell the kernel that the table entry is no longer needed. For orphans - someone still needs to do the reaping, and it has always been PID 1's job to do that, and still is under systemd.
3. The naming of scripts in /etc/rc.d was designed so that the SysV init scripts just read the runlevel dir and execute all the scripts there in alphabetical order - the K and S prefix don't get special treatment, they were just chosen to make sure that all the "kill actions" run before any of the "start actions" due to K sorting before S. The K before S order was chosen so that if in a runlevel there are both K and S scripts of one specific service, the service will first be killed by then started again, so making sure services are preferred to be running.
4. There were a lot more init products offered during the "init proliferation" period of Linux - not just OpenRC and upstart. The table shown in screen shows a few of them (notably runit wasn't mentioned, though it was very important at the time) but there where many more, such as supervisord and tini, some are still surviving in container environments.
umm ok, but didn't you have to define which application to use as the init? The kernel did not know until you defined which one to run, so will stand by my statement, and thanks for adding this bit of info
@@CyberGizmo ok - when you said "the kernel runs /sbin/init because it doesn't know what process to run" I assumed you mean that the path is hardcoded and the kernel doesn't care which init software you use a long as it provides /sbin/init. But technically you could have multiple init systems installed and choose one on boot (I'm not claiming that is a sane setup 😅).
As a runit user, I find systemd mind-boggling to use. With runit, I just start processes and keep them running... that's it, that's all I need my init to do.
I use Void and I find runnit to be very simple and easy.
@@folksurvival That's exactly what systemd does too. It can restart things for you on crashes if you want to, or restrict resources, run services on timers, socket activation, and more, if you need it to. If you don't need that, it can also just start a process and keep it running until you tell it not to. I want my init system to be able to take responsibility for the things I tell it to manage, and keep them in line, so systemd suits my use case very well. I've not used runit, but I've also not had to look elsewhere.
Great video again, sir. Even though I knew all that it was a pleasure to listen to you :)
👍 👍- Another great vid! I would vote yes on examples of setting up systemd units, etc...
From the title, I said to myself, I know all that, then when I finish the video I realized it full 80% of that I do not know about, DJ I can only say .. Well Done!
Thank my friend, am glad you liked the video
Run levels are great. I still use init 0 or init 6 sometimes symlink or not as long i don't ont have to write a paragraph to shut down or restart the system. I really love your knowledge and look forward to learning new things from your channel.
alias r='reboot'
alias s='shutdown now'
So like all the rest systemV is great as long as you don't have to do any work lol. The systemd developers say they same thing and like you they don't want to do the work of maintaining systemV for the reasons they clearly state if you bothered to do even a minimal education on emerging technology.
@Leopard lol. I have no clue what your point is. I just like shorter typing on the cmd line. I'm not in a production system, so I'm going to do it the way I want . If im in a production system, I'll follow standards. Otherwise, Path of least resistance.
@Hanabishi I like that idea.
You’re bringing me back Thanks DJ :)
very informative. I 've run some pre-systemd distros but didn't had much of awareness. systemd felt well organized for (re)starting services/daemons over other systems and it was easier to write units for stuff that didn't come with their own. lately it felt that it "eats" stuff which led me to see the "systemd or not systemd" conversation that happen for some years now. cleared some grey areas on my understanding and you kinda explained to me the reasons i am trying to go away from it. possibly an openrc approach (as i firstly saw that on archlinux i think) is what fits more my use-cases of system.
Thank you, sir.
His experience in that land are something to note down.
Thanks for sharing
🎯 Key Takeaways for quick navigation:
00:00 *💻 Introduction to SysVinit and Systemd*
- SysVinit was the traditional init system in Linux, responsible for system initializationd managing services.
- SVinit had limitations, such as its serial execution model and lack of support for dependencies and parallel startup.
00:44 *🗺️ The Boot Sequence and Init Process*
- The boot sequence starts with the BIOS/UEFI, which loads the bootloader, which then loads the kernel.
- The kernel starts the init process (PID 1), which is responsible for system initialization and service management.
- The init process can be different systems, like SysVinit, Upstart, or Systemd.
01:53 *🔍 The Functions of the Init Process*
- The init process handles the later stages of the boot process, configures the system environment, starts processes for logging in, and cleans up after terminated processes.
- In the pre-Systemd era, the init process would inherit orphaned processes and try to shut them down.
03:47 *🕰️ The SysVinit System*
- SysVinit, also known as SysV or System V, was the traditional init system used in many early Linux distributions.
- SysVinit organized the runtime environment into a sequential set of stages called runlevels, which had to complete before the next one could begin.
- This sequential execution model led to slow startup times and issues with dependencies and conflicts.
09:41 *🔀 Alternatives to SysVinit*
- After the limitations of SysVinit became apparent, alternative init systems emerged, such as OpenRC, Upstart, and Systemd.
- OpenRC introduced parallelization and improved dependency management, while Upstart was developed by Canonical for Ubuntu.
- Systemd, developed by a Red Hat engineer, aimed to address the shortcomings of Upstart and became widely adopted in the Linux ecosystem.
16:46 *🌐 The Systemd Init System*
- Systemd defines services as "units" and allows for more flexible and dynamic management of dependencies and system state.
- Systemd replaces the runlevels of SysVinit with "targets," which group units together to define specific system states.
- Systemd is designed to be more responsive to changes in the system environment and can start services based on events, not just a predefined order.
24:28 *🌟 Pros and Cons of Systemd*
- Pros: Faster boot process, more flexibility, standardized configuration files, and additional advanced features.
- Cons: Concerns about feature creep, potential security risks due to running as a user process, and violation of the Unix philosophy.
27:08 *🗺️ Critique of Systemd's Design Approach*
- Systemd's design approach has limitations, particularly in its tightly coupled nature and interlocking dependencies.
- Tightly coupled systems are undesirable as they make it difficult to integrate with other applications and are prone to breaking.
- Systemd's "all or nothing" strategy makes it challenging to replace or use it partially.
27:48 *🧪 Potential Issues with Systemd's Adoption*
- Systemd's tight coupling to the Linux operating system may create challenges if Linux were to decline in the future.
- There are ongoing concerns about the support and security of Systemd as it has grown increasingly complex.
- The departure of Systemd's lead developer, Lennart Pottering, to Microsoft raises questions about the future direction of the project.
29:38 *🛠️ Systemd Configuration and Resources*
- Systemd provides flexibility in configuring various components, such as setting up custom targets, units, and configurations.
- The best manuals on Systemd are available in the Red Hat repository, which can be used as a resource for further exploration.
- The speaker encourages the audience to explore the Systemd topic further by checking the recommended resources.
Made with HARPA AI
Excellent explanations, thanks so much!
You're very welcome!
Thank you DJ ware it's really educational to know the differences and what they actually are.
More than a thumbs up! This is a five star tutorial! Personally I have no preferred preferences over Systemd, SysVinit, OpenRC. On my Archlinux systems (systemd) if I want to start or enable a printer all one has to do is sudo systemctl enable --now cups. Or stop bluetooth sudo systemctl stop bluetooth.service.
On my ssh Gentoo installs from a host computer I use the OpenRC. Just boot the target machine with a USB thumb drive. Create a password for root. Use ifconfig command for a ssh ip address. Once boot into usb start the OpenRC rc-service sshd start to provide the connection for any host machine to issue commands from a terminal . From installation notes, or from the Gentoo wiki web page installs.
I've done just recently a SysVinit install (LFS) Linux From Scratch which was very time consuming. But the install was successful. Example: -- linux: /etc/init.d # ./sshd status -- or linux: /etc/init.d # telinit 3.
Yes -- Systemd might have some down falls but for the user the commands are simple and easy to remeber. So what am I using as of this moment? Slackware 15. Also a non systemd init system which you have stated in a video that "Slackware 15 is a Linux closest to a Unix system.."
Slackware is an excellent and stable Linux. But I must say that my Archlinux and Gentoo system boxes are very reliable as well. :) Lot's of init system choices, other as well and much to learn.
I have worked with multiple init systems and I must say I love systemd. It makes writing of units very straight forward and easy. In contrast to those scripts in rcX.d directories, it's very simple and straight forward. Declare a name, dependencies, tell it what to start, how to start it, how to kill it, define what to do on failure, etc. Everything is on one page of text with minimal scripting. The interface with systemctl and service is very intuitive and simple to use, setting services up for startup or starting them manually is easy, with autocomplete and everything.
I don't understand why people cry about it. Yes, it does come with a lot of features that might not typically be part of the startup, like dns or timers. But you can just not use those features and continue using cron.
Thanks Don. This channel is a gold mine. 👍 Thanks for getting back to the roots and explaining in detail why something exists/existed and how it works.
wow, in-depth OS reviews, thank you sir
Thank you, this is needed for everyone !
Very useful summary of the issues. I can assure you however that BSD users are not at all keen on SystemD coming over, so that's one less thing to worry about!!
It never will, because it depends too much on Linux-specific functionality.
Systemd never fixed anything that needed fixing in system initialisation anyway - it's a bloated piece of redundant software for "fashionistas".
I don't use much *BSD (though like it for what it is) but I've used Gentoo Linux for almost 20 years now and have stuck with "openrc" as its default initialisation system that "just works".
@@terrydaktyllus1320 quite 👍
Remember that systemd is more than just “system initialization”. Linux is a very dynamic environment, where services can be started and stopped at times other than system boot. systemd is designed to cope with that.
I thoroughly enjoy these video essays. I feel like I soak up something new almost every time.
Personally I’m a Mac user, and those have tended to be my main machines have been since System 6 or 7, with an exception being a short period when I used Linux. I have also been using Solaris, BSDs, and several Linux flavours. When I started learning more intimately about the inner workings of computers, I did do that on Solaris and Linux machines so I really only feel properly at home in the unix-style systems. I did go back to Macs for my primary machines when they launched their OS X series, where I could feel at home and still have access to the commercial software I needed for work and studies.
MacOS got it right with launchd
@@CyberGizmo I tend to agree, it is also reasonably easy to deal with. But that may only be down to me being most familiar with it these days…
After writing my own startup scripts for SysVinit, writing my own units for systemd was too easy. Now I have moved all of my crons to systemd timers, also - both as root and normal users.
5:47 It’s worth clarifying what the whole point of this “parent/child” relationship, and consequent possibility of “orphan” processes, is about: when a process terminates, it becomes a “zombie”, which means it still takes up a process slot, even though no process is running any more. At this point, it is up to its parent to pick up a notification of the termination of the child, via a call like wait(2) or similar; once it gets this notification, then the zombie process disappears, and that process slot is freed up to hold a new created process.
So, if you write a program on Linux or other POSIX-type system, and you spawn lots of processes, then you have to remember this rule to avoid your system running out of process slots: always gobble your zombie children.
Excellent content - very interesting. Well earned sub!
Welcome aboard, irbaboon
Outstanding video with great history and information! I've been using some flavor of Unix since 1983, and I really don't like systemd. SysVinit is what I'm used to, but openrc is pretty good. I like tiny programs that interact rather than "full-featured" systems that try and do everything.
I use a combination of Init processes on my network. Choice weighs on the role of device. Is it a server? General Desktop? Specialized application desktop? Firewall? I recently built out an old ambulance into a mobile home. There are 8 custom computers as part of the build which tie into my 24V solar system. The OS loads into ram very quickly and does not suffer any damage to data or hardware if power cycled. systemd is not a part of this design i went with OpenRC. Each INIT has it's own strengths and weaknesses.
10:42 Fun fact: Debian used to use runlevel 3 as its normal mode of full multiuser GUI login. Which just goes to show how wonderfully inconsistent sysvinit could be.
With systemd, all runlevels (now called “targets”) are identified symbolically, so you don’t have to figure out what cryptic numbers mean, because there aren’t any.
>Fun fact: Debian used to use runlevel 3 as its normal mode of full multiuser GUI login
I'm pretty sure it was level 2 by default.
But there are cryptic systemd commands that you have to learn, and make no logical sense.
For the record, I can speak with considerable expertise on systemd due to having a day job for the past 20 years of building, administering and hardening Red Hat (Enterprise) Linux servers - I don't like systemd at all but my knowledge of it pays the mortgage.
My home environment consists entirely of Gentoo Linux machines (since 2003) and openrc is far more simple and logical for starting services that "just works".
Systemd is bloated, illogical and these days treated purely as a "fashion accessory" in Linux where half the users stand under the "systemd" flag shouting at everyone else stood under the "systemd is entirely unnecessary because it doesn't fix anything that needed fixing in system initialisation" flag.
@@terrydaktyllus1320 Which commands are you referring to? They are all there for a purpose.
@@lawrencedoliveiro9104 "Which commands are you referring to? They are all there for a purpose."
On openrc, all I need to use are:
/etc/init.d/[service name] start/restart/stop/status
That's it.
@@terrydaktyllus1320 Sorry, I didn’t read your comment any further.
Excellent video! You did a great job of explaining why many Linux distros moved to systemd. The structure and commands are slightly more complicated than good old sys5init, but clearly necessary. I started reading the Red Hat resource you linked, thank you!
You put up relevant tech videos I am interested in, you won my subscription Sir and thank you very much for your knowledge and insight
A small correction regarding the zombie processes: I think they are a bit different from what is described in the video.
When a process forks itself, the parent is given the child's PID, while the child sees 0 as a result of the call to fork(). The parent then can wait for the child to terminate and it can read its exit status. But what would happen if the child terminates before its parent has called `wait()/waitpid()` on it? The kernel needs to do 2 things: 1. it needs to preserve the exit status, and 2. it needs to preserve the PID until this status has been read. It does that by storing the exit status in the process table and by marking the entry as zombie.
So a zombie process is just the entry in the process table of a process, who's already terminated. The entry will stay there until its parent process waits for it.
If the parent terminates without checking on its children, the child process can remain a zombie forever. It doesn't take any memory or CPU resources, but it takes up this entry in the process table. This used to happen in earlier versions of linux, but now there are mechanisms to prevent this, but I'm not sure about the specifics. I think the re-parenting of child processes to PID 1 is part of this and also probably the zombie-walker that was mentioned in the video, but these are just guesses on my part.
No, UNIX had a subroutine which reaped zombie processes, it was called the zombie walker as I described it.
Here is a link for you. medium.com/coding-in-simple-english/the-fear-of-zombie-processes-8d2f00449795
Zombie processes could not remain a zombie for longer than the zombie walk timer on UNIX. Linux has the kthreadd process which takes care of orphaned processes, don't confuse the two, they are not the same things.
Ivan Toshkov is right, DJ Ware is wrong. Note this part from the linked article: “When orphan processes die, they do not remain as zombie processes; instead, they are waited on by init. The result is that a process that is both a zombie and an orphan will be reaped automatically.”
Note that only applies to orphan processes. Non-orphaned zombies cannot be automatically reaped; their parent process must do this.
@@CyberGizmo I wrote a small C program to test this:
#include
#include
#include
#include
#include
int main()
{
pid_t w, pid = fork();
int wstatus;
if (pid == 0)
{
// we're in the child process
printf("[CHILD] Terminating with status 7.
");
exit(7);
}
else
{
// we're in the parent
printf("Let's see if we get a zombie. Enter the following command in another terminal without pressing ENTER here:
");
printf("ps ax | grep %ld
", (long) pid);
printf("
You should see that the child process is marker as [zombie]
Now press ENTER:
");
getchar();
printf("We are now checking for the child process return status ...
");
wait(&wstatus);
printf("status = %d
", WEXITSTATUS(wstatus));
printf("Now the zombie process is gone. You can check with the above ps command.
");
printf("This process will still be active until you press ENTER.
");
getchar();
exit(0);
}
}
This program demonstrates the zombie process. It will stay as zombie as long as the parent process hasn't read its status.
[EDIT] I just read the Medium article that you liked to and it describes exactly what I'm saying. There's no special "reaper" process, unless you count init as such. That the zombie is reaped as soon as its parent wait()s for it. If its parent terminates without waiting (orphan process), the child process is re-parented to init. And init will wait for it right away, thus "reaping" the zombie.
@@lawrencedoliveiro9104 Thanks. I assumed something had changed, but you've confimed it works as expected. I just spent 5 mins trying to get this thing to come and kill an orphaned process I intentionally created:
john@buckbeak:~$ perl -e '$\=$/; $pid=fork; sleep(1); sleep(1) unless($pid); print $pid; sleep(1);' # experiments trying to get killer to come to sleeping child
6934
0
What Ivan described is how I have always understood Unix did it, since starting as a system programmer on 4.2BSD. Never heard of a zombie walker.
Are zram and zswap large enough topics for a video? What if they're combined with covering swap in a modern context (often ample RAM and SSDs).
I Love You!! ❤ in the first 5 minuts you simply taught to me a lot!! ❤
The real motivation behind systemd
Fact 1: systemd is from Red Hat
Lennart Poettering and Kay Sievers who started the systemd project in 2010 are both Red Hat employees. Initially systemd was released as a new init system, but it has slowly grown into what Poettering describes as "a suite of software that provides fundamental building blocks for a Linux operating system." This is by design, not by coincidence.
The official reason for the development of systemd was described as:
They wanted to improve the software framework for expressing dependencies, to allow more processing to be done concurrently or in parallel during system booting, and to reduce the computational overhead of the shell.
Fact 2: The primary reason for developing systemd is Red Hat's business interests in embedded devices
Red Hats primary business is in embedded devices, and the primary concerns addressed by systemd by design is embedded devices, such as the work towards removing /etc.
In an interview with Red Had CEO Jim Whitehurst he states:
We partner with the largest embedded vendors in the world, particularly in the telecom and automotive industries where stability and reliability is the number one concern. They easily adapted to systemd.
Mentor Automotive has released their slides from a 2015 event In these slides the many benefits provided by systemd to the embedded automotive market is fairly well explained. The reason why they "easily adapted to systemd" is because systemd is specifically designed to suit their needs.
The U.S. Military has been Red Hats biggest customer since 2002 and they have been a major source of motivation behind many of Red Hats decisions.
In 2012 Lennart Poettering changed the systemd license from GPL to LGPL in order to better suit the embedded market.
Fact 3: No, it's not a myth, systemd is truly a huge monolith
In his blog post "The Biggest Myths", from January 2013, Lennart Poettering argue against calling systemd a "monolith", which is what many people consider it to be. Lennart says:
A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.
The fact is however, that many of these so-called individual binaries has functionality that simply will not work without other systemd components. If we take a look at the man page for systemd-networkd it clearly states that if you set the option UseDNS as true the DNS servers received from the DHCP server will be used and take precedence over any statically configured ones. This corresponds to the nameserver option in /etc/resolv.conf. What the man page neglects to mention is that this setting (and multiple other settings) does not work without systemd-resolved. Other components of systemd are even more tightly integrated.
Fact 4: Privacy concerns
systemd-resolved has hard coded fallback DNS servers for Cloudflare, Quad9 and Google. Even if you turn these off, a bug might cause these to be used anyway (which actually happened at one point).
Fact 5: Red Hat wants to become the next Microsoft Windows
This is another major motivation at Red Hat and this is illustrated by Lennart Poetterings slides from FUDCON + GNOME.Asia Beijing 2014. Go to page 15 and scroll slowly forward to page 19.
0pointer.de/public/gnomeasia2014.pdf
Eventually you end up with the project objectives:
Turn Linux from a bag of bits into a competitive General Purpose Operating System.
Build the Internet's Next Generation OS.
Unifying pointless differences between distributions.
Bringing innovation back to the core OS.
Combined with the next set of slides that display the market Red Hat want to target:
Desktop
Server
Container
Embedded
Mobile
Cloud
Cluster
Much of the added functionality that the different systemd modules provide has zero benefit in the server industry. It is only added to make desktop systems like GNOME and KDE function like Microsoft Windows.
Fact 6: Red Hat needs other major Linux distributions to cooperate
If Red Hat was ever going to succeed in their long term plans for developing the "Internet's Next Generation OS" they knew they needed to somehow influence the other major Linux distributions. The reason for this is that if a major Linux distribution like Debian was going to reject systemd, Red Hat wouldn't be able to proceed with their plans because too many third party projects simply wouldn't care about how Red Hat would like things to work. This is very important to understand because many open source projects used to develop software with POSIX compatibility in mind. As such they try to make sure that their project compiles and works on several Unix-like operating systems. This is something that isn't in the interests of Red Hats. As long as you have to consider other operating systems such as Solaris, FreeBSD, OpenBSD, etc., Linux is "held back" when compared to functionality in Microsoft Windows. Functionality such as easy mounting and unmounting, simple privilege escalation, etc.
Another problem for Red Hat was that if the other major GNU/Linux distributions had rejected systemd, it would have become much more difficult for them to get systemd relevant changes and code pushed into the kernel. But when the other major distributions also adopted systemd, it became a lot easier.
Consequences
The main problem with systemd is that its continued development is motivated by a company's economic interests and not the open source Linux community interests.
Red Hat cannot be trusted from a security point of view and if the U.S. Military, or some other three letter organization, wants Red Hat to put a backdoor into systemd, then this can easily go unnoticed for many years, just like it did with the Heartbleed bug.
And we have already seen several examples of these kind of exploitable bugs in systemd:
Create a user called '0day', get root privs - not considered a bug!
Remote Code Execution For Two Years
Systemd Bug Lets Attackers Hack Linux Boxes via Malicious DNS Packets
www.theregister.com/2017/07/05/linux_systemd_grants_root_to_invalid_user_accounts/
it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
Whether such bugs are introduced into the code on purpose, disguised as honest mistakes, or they truly are real mistakes, is impossible to tell. But one thing is very clear, Red Had do not have the Linux communities best interests at heart, they only have their own financial interests at heart.
Another major problem is the previously mentioned hard coded DNS servers in systemd-resolved.
Lennart Poettering explained that the hard coded values should be there in case of catastrophic failure of configuration files, and a lack of DHCP on the network (the DNS fallback is changeable but requires a recompile). However, that's the "embedded developer" speaking. If a bug is found in the application that makes these DNS servers run even though you have disabled them, or if a race issue bug is found, you could be facing a serious privacy issue. Furthermore running with Cloudflare, Quad9, and Google DNS servers hard coded into the systemd code is deeply problematic as these companies are not only known for violating peoples privacy, but also because NSA has previously infiltrated Googles data centers, something revealed by the Snowden documents. Such settings should never be opt-out (where you have to remember to remove them), they should be opt-in, and definitely not the default options.
The way these issues are dealt with generally, and the extremely arrogant attitude of Lennart Poettering shows a complete disregard for user privacy and for the interests of the open source Linux community.
Final comments
It has surprised me that the initial discussion on the Debian mailing list somehow managed to only address SysVinit, Upstart and systemd. Nobody took a serious look at runit or s6. Not only are these systems much more aligned with the Unix philosophy, but they are also much more secure and easy to understand.
Casper Ti. Vectors post on the Gentoo forum, s6/s6-rc vs systemd, or why you probably do not need systemd, also shows that s6 is a better and in many ways superior solution to systemd.
forums.gentoo.org/viewtopic-t-1105854.html
Many people mistakenly think that each and every systemd component is independent, but that's just not true. Take a look at the code and the documentation and see the tight integration between many of these so-called modules.
www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
Corporate politics, maneuvers and manipulations has no place in the community driven open source projects. And while companies can be allowed to both use open source code, contribute code and also provide financial support from their earnings on these projects, they should never be allowed such massive control as Red Hat and others now have.
Thank God for truly independent community driven projects, because without those we're left with crap like Microsoft Windows.
This explains the Red Hat paid shills attacks on Canonical/Ubuntu when they tried to go their own way some time ago. Might see it happen with System76 with their popos project. Already seen some attacks done with their own firmware update system.
Reading this comment especially the RedHat part felt like watching StarWars prequel trilogy.
Top 5 blunders in human history...
I knew RedHat was part of the problem. But it is worst than I imagined.
Thanks for the infos.
That is not a review of the technical merits or lack of systemd it is an anti corporation anti red hat rant.
Red hat can not force Debian to do anything. You will have to ask the Debian developers to explain their reasoning but my guess is after a preliminary review of the options they decided to consider the best 3. After their review they went with systemd. The logical conclusion is systemd is the best option for Debian.
You can not make baseless accusations against corporations or Red hat without some evidence of which you have none thus your claims are baseless.
At the end of the day people have to earn a living and the simple truth is that Red Hat continues more than any other distro to the kernel and Gnome because they earn a living. If you want an alternative either do the work yourself or pay someone to do it for you.
There are a plethora of volunteer linux groups such as GNU / GUIX Debian arch etc and neither Red hat or Microsoft has any control over them nor can they shut them down.
No one is forcing you to use Red Hat nor any of your baseless claims to this effect. You should be appreciative the Red Hat developers are communicating their thoughts and intentions as they contribute to progress.
If you don't like it use GUIX or one of the Libre distros.
@@leopard3131 It is naïve to think RedHat or M$ or any other company can't force others to do things. They have more than enough corporate money to do that...
Great talk, great insights, a thumbs up 👍
Thank you for more clarity
I find it amusing that systemd still claims it's faster, when in actual fact distros I've played with that uses either OpenRC or Runit boots much faster - on the same hardware. Oh well, some distros are better optimized than others I guess. In any case, I prefer OpenRC for its simplicity and the fact it's never got in my way. Seems to do exactly what it's supposed to with no fuss.
Interesting video anyhow, glad to get some more insight. This is a topic I've never delved into really, so it was educational. :)
Real question. How does systemd get in your way?
@@KeithBoehler I wouldn't know since I don't really use it. Wasn't meant as critique, just saying I'm happy with how simple OpenRC has been for me.
@@KeithBoehler If I may answer to this, as I described in my comment, it affects the clock of my dual-boots.
@thisDay no it does not another user explained it to you you are uneducated in this regard so stop making this baseless claim.
Faster at what? Sure you can build a simple system tailored to your personal needs and it is fast but have you tailored systemd the same way and can you post benchmarks? Even if you can such a claim is not going to be true over all use cases and as there are more and more complex tasks then systemd will be faster for the reasons the developers give. This argument is also uneducated and irrelevant.
Great insights, thanks for that. I'm comfortable with sysvinit and have accepted systemd as a practical necessity, as you say for events such as networks coming and going, displays disappearing, etc. I don't like its network handling, or in fact I'm frequently confused by what is going on with networking lately. I think I like the netplan concept though. For things that I like to have running and keep running, just a plug for supervisord - let systemd handle all the system stuff but have supervisord take care of the applications.
re: pros and cons:
- I would have liked to hear a discussion of socket activation and possibly about the launchd origins of systemd.
- The thing with interlocked dependencies and systemd requiring to be used a a whole or not at all - this is simply not true: all the systemd parts are optional, you can use just the init service without any other part, or use any part without the init service (not that it makes any sense).
For an interesting discussion of systemd, its strengths and weaknesses - from the perspective of a BSD developer - and it goes deep into some of the social aspects of systemd development, rise to fame (add possibly future downfall), I recommend reading "The Tragedy of Systemd" by Benno Rice. I don't agree with everything written there, but it has a lot of nuanced discussion that is often missing from the rhetoric of the "Systemd bad... SysV good" camp. The main thing I, personally, have to say about the social aspects of systemd is that as a systemd fanboy, I have to agree that Poettering is a particularly annoying fella.
The definition of tightly coupled or loosely coupled is not defined by how it interfaces to its own components but rather how it easy or difficult it is to interface to external applications and external services. Try replacing systemd with any of the other init packages and let me know how well your system is running for you, and while you are at record the amount of time you need to spending fixing external services that are so dependent on systemd they will no longer run, and while you are at that record the number of hours before you give up in utter frustration trying to stitch your system back together to make it functional. That is how one measures tightly coupled, not by which systemd processes you add on or you can turn on and off. I am not trying to lash out at you, but I spent many years working with UNIX and the sometimes the people who wrote it. Minds much smarter than I will ever be, but the one thing the Bell Labs team impressed on me was making your code composable, so that it could be easily adapted quickly (and i mean in days, not months or years), or how parts of it could be lifted out and reused in other totally unrelated projects with simple interfaces, simple data structures that were easy to grasp, do you really think systemd fits the tenets of the UNIX Philosophy? If you really understand those, you would come to realize just how simple and elegant the progenitor of Linux was. Perfect? No, Composable? Yes. The systemd debates are long over, and we are stuck with it, but as an old developer I know it could be a lot better, a lot smaller, and a lot easier to maintain...its truly a shame Poettering didn't listen to us, but some people have to learn the hard way.
@@CyberGizmo I completely disagree, with just about all of that - I grew up in the (not that much) older days of maintaining SysV scripts by hand (often those that came with the OS and were insufficiently stable) and systemd service management architecture is not only a massive improvement on that, it is better (often much better) than any other service management that aimed to replace SysV (and I managed production services on all those you mentioned in the video and more).
Granted, the fact that systemd provides useful capabilities over a more "classic" service management framework, and then applications taking advantage of that to provide better behavior (DBus activation anyone? How about nanosecond-resolution task scheduler? User services? Service namespacing? etc), can be looked at as detrimental to the ability to replace systemd (in whole or in parts), but why should we be stuck in the past with limited capabilities when we can do better? And *all* of systemd APIs - whether internal or external - are accessible and made available through standard files or DBus (which is not part of systemd and should be a requirement for an OS to call itself modern Unix), so should be easy to implement by competitors.
IMHO systemd developers - as a systematic approach - build tools that are always optional and any non-classic capability they offer is clearly and publicly spec-ed in a way that it can be re-implemented by alternatives. Were there mishaps? For sure! But as a whole - if you believe that systemd is wrong in pursuing a new style of system management that is coherent, featurefull, and more than the sum of its parts - then I believe you are on the wrong side of history.
@@guss77 Then we agree to disagree and there is no need to discuss this further you have your ideas and I have mine
It is very easy to interface existing applications and services to systemd.
An example of this sort of thing popped up on the Waikato Linux User Group list a few months ago. I found this systemd service file in an online forum that someone had written to automatically apply a certain charging profile to their laptop battery on boot. The actual command was a single line of shell script; the rest of the dozen or so lines were directives defining when and how to run the command (e.g. specifying that it was “oneshot” invocation, so there would be no ongoing running process after the command had done its job).
I reposted it because I thought it was a good example of the simplicity of systemd.
Somebody more familiar with sysvinit tried posting an init.d-style script to do the same thing. It came to be about 50% larger, all but one line of which was just boilerplate.
@@lawrencedoliveiro9104 I am not saying sysVinit is superior to systemd.
I chose sysVinit for comparison, because it was the primary init process in Linux prior to systemd.
Don't shoot the messenger.
As for the 50% larger comment, meaningless to me, would need more information, like how proficient is the programmer, what language was used, and what OS was being used.
For example on FreeBSD 12.x it takes one line to enable and start a system service.
As for the design of systemd...its much much larger than the init program it replaced, and all to do parallel startup as it original goal? I would call it a cannon to kill an ant.
Can I be a little out of the context of the video? I enjoyed very much your HAL-9000 and the " Discovery " panel messages as a screensaver. 2001 is my favorite movie ever.
I'm mostly in the FreeBSD camp, and for me, the fact that SystemD can't easily be ported to FreeBSD is a good thing. I much prefer BSDInit.
Yes, Debian boots faster on my hardware than FreeBSD, about 1 second on my hardware vs 10 seconds for FreeBSD. But that really isn't a big deal. Rebooting isn't something I do very often, and when I do, 9 seconds isn't going to make that much of a difference to the overall downtime impact.
Maybe it is just that I'm a lot more familiar with FreeBSD than other systems, but I find that creating a new service in a few lines of shellscript in FreeBSD is a lot easier than trying to wrestle with SystemD.
Agreed it was more important years and years ago when we loaded from slow disk drives. And I much prefer the simplicity of the BSDInit
5:20 Doesn’t matter whether the child does an exec(2) call or not. It still remains a child of its parent.
As a Linux embedded developer I work with systemd on my development machine and luckily have not to go to deep into its configurations. For the embedded targets I usually use buildroot to tailor the system which uses a sysv style to boot the embedded system. For me it is easier to add our services to init.d to get them running.
As an embedded developer you don’t have to worry about dependencies, since you can provide all the necessary ones in your installation image. Heck, you could probably put all your necessary startup/shutdown sequencing in a single rc.local-type file and dispense with sysvinit altogether.
systemd is designed to cope with much more complex, dynamic and variable situations.
Great video and info
Thank you!
Where is the boot sequence video?
Maybe you can give us link about your previous video everytime you mentioned it.. just little pro tip here..
I really like the diagram approach you write btw.. Very good at giving me the big picture of what's going on..
Opps missed this comment, I did a brief intro to it here: ua-cam.com/video/BBUPc0aO5lw/v-deo.html
Let me see if I understand correctly. Systemd started as a Canonical project, then was reimagined by IBM/RHEL which doesn't respect the community and basic principles of UNIX, has a lot of bloatware-complexity like Windows and now the main developer works for Microsoft? Sounds good
Launchd, the service manager I've been used to for almost two decades on Apple(-clone) machines, could have deserved a mention in this video of yours with which I agree mostly..
Wnen I first tried out a systemd-driven Linux like openSUSE, my guess was that systemd must have borrowed heavily from launchd. Even if that impression may have been incorrenct (you've mentioned the upstart prelude), systemd's concepts instantly »clicked« with me. (I'm glad to say I have never needed to get my hands dirty with distro-specific, obtuse, spaghetti-style SysV-style shell-scripts ever since - at least in private. For work, it's ok, I get paid and will service any legacy stuff thrown at me.)
Optional tools like journald, systemd-analyze or systemd-networkd are pretty good too IMHO. I replaced systemd-network with my custom unit file of mine, though. There goes your »closely coupled« argument, no offence.
One of the biggest advantages (speed aside): any bugs get fixed once for all distros using systemd simultaneously. Contrast and compare that with the distro-specific scripting out there, that accumulated during almost three decades.
Nevertheless, here's hoping systemd will be replaced with a even better service manager soon - maybe one that's portable between *BSD, macOS and Linux. Cheers!
I debated including launchd in the video, but thought it deserved its own video. Yeah, I agree it would be great to see a cross platform system manager.
Your impression is pretty spot on with regard to launchd. In fact, I think you may not have sufficiently expressed how heavily it borrowed from launchd, as it was what influenced Lennart to give up on trying to fix upstart to be what they wanted, and instead created systemd.
They just didn't use XML formatted configs, and opted for an ini style instead. Of course it grew from there, and diverged fairly significantly from launchd.
I can take or leave systemd, *except* for the systemd-journald non-text-file thing you mentioned (and you can kind of substitute in syslog), and the fact that the systemd developers decide for you that they will ignore your pager settings and truncate the logs at the edge of the terminal instead of wrapping (or respecting your pager settings) when you use their log viewer (journalctl). They definitely have a "screw you, we're writing what we want" attitude.
I don't think the systemd developers ignored pager issues. Start journalctl with --no-pager or set the environment variable SYSTEMD_PAGER to whatever you like.
@@danespen5772 Yeah, and it took me half an hour to find the SYSTEMD_PAGER environment variable in the source code. I now set it to FRXMK as a habit, but they should leave the default pager alone, and use optional obscure settings to modify from the defaults rather than require them to get back to defaults.
@@danespen5772 BTW, there was an argument about this in 2010 or so and they decided to go with their personal preferences for pager behavior as a default.
@@DennisGentry I started journalctl, pressed "h" and it was revealed that journalctl was using less. It may be passing a flag you don't like to less, but it's using less.
I started watching but had to pause, as I quickly got lost digesting the comment section below (I'm just a noob about to do a test run, dual-booting 2 versions of MXLinux on an old Acer laptop with a new SSD; both Xfce but one with SysV and the other straight-up systemd ((praise Satan!)) to see how they compare). The tech-talk, conflicting views and politics of this comment section was utterly fascinating to me, illuminating. _Now_ I'm gonna watch the video lol...
Very nice rundown on how system booting works!
I'm a Debian linux user, but I wish we'd stayed with SYSV init, or even the older BSD /etc/rc style system. I hate two things about systemd. First, it violates what I, personally, consider to be one of the basic concepts of UNIX... .having small tools that can be used together to accomplish large tasks. By trying to pile everything into systemd, it creates a monolith that is fragile and hard to work around. Secondly, systemd seems to have been designed to make life simpler for large corporate environments where you want to deploy hundreds or thousands of machines to all behave alike, and thus having a simple template-based system is useful. For me, I have to constantly fight with the systemd "unit" system to get it to do what I want, whereas the older init system was a set of shell scripts that could be as simple or complex as you needed them to be.
So, while I understand the appeal of systemd for one subset of uesrs, I'm not happy that almost every linux distribution out there feels that it has to push this onto everyone that uses it. However, I'm used to not getting my way. After all, I liked the Sunview desktop and hated X11. :)
I personally think systemd sticks more to the "do one thing" philosophy than most think. It's not one monolith but several parts working together, optional, allows for better resource controls, and a heck of a lot less complex to interact with than the spaghetti init scripts of old.
Sorry to hear you're having problems and having to fight it, that has not been my experience at all.
For me it's a lot easier to see how any new service I want o look at starts up thanks to the standardized unit files. Works just as great on my home desktop machines and servers as it does on our company workstations and servers.
If you still want to use a hacky shell script to launch something, unit files still allow you to do that via the "oneshot" style, and you can even completely override what the one provided by your distribution by dropping your version in the overrides folder. Systemd even has the edit command to create those overrides for you.
If you're having problems with something specific maybe I could help? I'm no expert at systemd or boot processes, but I do at least tend to get things to behave the way I want.
I'd like a Debian with OpenRC
One of the downsides of systemd, is not the systemd itself but the users of systemd. Not the end user but, in my experience, the desktop environment developers. As an example, I don't think any DE handles a user logout. They handle system shutdowns just fine but it seems all of them end up with multiple logins on a user logout. The old session never gets stopped.
This is stunningly annoying when the workaround is to nuke all user processes on logout.
Can't use Tmux or Screen on that user anymore. Just have to keep your terminal open.
@@thumbwarriordx There is actually a systemd service made just for this purpose. None of the DEs I have looked at use it though. It only stops user processes started within the logind session. The problem seems to be that the session end code is _all_ run as su and deals with systemd --system services. The session end or logout service has to be run as systemd --user.
Loved this very educational
I would argue that having processes that are tightly coupled are a direct violation of UNIX philosophy. One of the main takeaways of "do ONE thing and do it WELL" is that it can be used with other programs. That is, a "business" need can be done by simply running a specifically crafted chain of commands (programs). The "one thing" part mentioned before helps so that no matter the context, the program has no side/unwanted effects and doesn't waste resources for something you don't need. If you need something extra, it can be provided by another program or with an option.
However, if your program is tightly coupled with another, well, then you don't have one program that does one thing and does it well, you have 2 programs masked as one, so essentially one program that does two things.
Not being able to run a program with all its features standalone compromises its interoperability and use for composing a bigger program. Which is exactly what the UNIX philosophy stands for, whatever bigger/complex program you need, you can build it by using small dedicated programs. With systemd's dedicated programs you can reasonably build a single program: systemd itself.
In conclusion, systemd is mostly a monolyth. It gets away because it does its job pretty well, it does cover most of the needs that people have. But not the concerns about its future.
composability is the key to Unix Philosophy, plus it can be understood by developers other than the creator. I dont think systemd qualifies on either of those principles of the UP either.
text at 0:34:
"I'm not gonna talk about Unix so much even though eunuchs played a part in the"
I recently realized, that using a dual-boot with one systemd-driven system and one without systemd (don't matter if it is Linux or Windows) does effect the clock-setting of the non-systemd system. That is somehow penetrating. And I don't know why this happens, but everytime I boot into Fedora, right after that I have to run a "ntpd -qg" on my artix installation to recalibrate the clock. Same after I boot into Ubuntu and then into Windows. On windows I will have to sync the clock again.
First I thought this was a windows bug, until I installed artix with runit/openrc as init system.
I find it as penetrant as some windows functions, that also have an effect on my linux system. So I hope systemd will loose importance over the time, like poetterings pulseaudio does at the moment.
How about to just RTFM? Arch Linux wiki -> System time -> Time standard.
(yes, youtube don't allow links)
Interesting!
I had a similar problem in the other way around: booting into windows would cause side effects on linux. systemd doing a similar thing is the final nail in the coffin for me: it suc*s.
@@joaomaria2398 RTFM you too. It has nothing to do with systemd. Stop making claims in topics you have 0 knowledge about.
@Hanabishi 100% agree. The systemd topic is charged because of uneducated end users who have opinions but do not do the work or bother to keep up with the emerging technology .
The systemd and Wayland trolls remind me of the flat earthers the use the same uneducated talking techniques.
@@mk72v2oq I followed the wikis, the arch and the artix wikis. And they help until I boot fedora(systemd) again. Sure, I can write a script to automate the clock sync, but I yet wonder why systemd does affect other systems clock sync anyway.
If you're not familiar with it, try to replicate the problem. The dual boot is on BIOS mode. The BIOS-clock is set to the local time.
If you then know something, I'm sure you can contribute more than just a bunch of smart-pretending letters. And if not, I'm sure you can be helpful in other topics.
SystemD and SysV init services are interchangeable for people with minor hacking. I Do prefer the .service format of systemD, because I can rely on the init system to manage things I wouldn't want to code.
SysV can be replaced by Openrc or runit without selling your distro to Redhat. Comparing SysV with Systemd is like comparing a Ford T with a Ford [insert a 2023 model].
In the Wiki table all have 'parallel system startup' capability, except Epoch. Hmm.
i like OpenRC
I use it all the time on alpine linux and I like it too, so simple and lightweight
OpenRC is great!
agree with openrc i like it and have been using it in my gentoo since 2003.. and to have binary logs was the worst idea in systemd ever - i hate it.
I don’t know OpenRC but I’ve read and tried a bit of runit in Void Linux. It looked simple yet powerful.
Then s6 came to my attention, then OpenRC, …is there an objective comparison of their design choices and implementations?
Thanks
a very controversial topic, indeed.... I am not a friend of systemd, but I could imagine what Poettering had in mind - a world where most of the Linux is running on commodity workstations and laptops, with all its issues this creates (encrypted home drives etc) - and not mainly on servers (where a simple init would have been enough)... personally, I think systemd is really the wrong answer to this, but I might be biased already by all those hours of troubleshooting network and other issues related to systemd and its approaches to how to do things in the background...
EDIT:
and yes, I was _really_ shocked and disappointed, when a distro like Debian relatively lighthearted changed to systemd... x-(
A few simple changes in the beginning would have addressed most of the legitimate concerns about and resistance to systemd. It should have been more modular.
Not insisting on being PID 1. It could easily have co-existed with sysVinit as a process manager.
Implementing some sort of imperative command. Don't wait for something that will never happen, just do this because I said so. So many times I run across systemd dumping me to a shell saying a mount failed only to manually type in the mount command and it works immediately. Obviously systemd didn't even try to issue the command.
Make it truly optional. There is no reason a service shouldn't just do it's best if systemd is unavailable on a given system. The developers swore it was impossible but soon after, a sort of stub library came about that mostly managed it.
Don't be so grabby. There is no good reason it needs to do everything. There are daemons to synchronize the clock, to do DNS, handle network connections coming and going, etc. That is not the job of init. Every time I install a system, I have to smash bits of systemd with a hammer or the machine will be flaky.
Yup. The major problem solved by systemd was the lack of technicians with enough knowledge. Now sysadmins don't need to know how things works, they just copy/past a txt to configure a unit and systemd does the job.
systemd is simply a very very very bad solution for the problem (but it gets the work done).
Again another uneducated user oblivious to the issues is shocked that progress happens even in Debian. Your lack of education does not mean systemd is bad and at least you admit you have a bias and that you have no idea what you are talking about other than your own personal opinion which is irrelevant.
@PyroNine9 as they are so simple let's see you maintain it problem solved.
@João Maria again as with all the rest of the anti systemd is the lack of education so go educate yourself. This is what any professional does often termed continuing education depending on the field.
6:07 kthreadd has nothing to do with any of this: it’s purely an internal kernel housekeeping mechanism.
Remember, the semantics of userland processes is laid down by the POSIX spec, to which Linux adheres closely. systemd really makes no difference to this.
ummm no...kthreadd oddly enough runs in system space: To augment the need for running background operations, the kernel spawns threads (similar to processes). These kernel threads are similar to regular processes, in that they are represented by a task structure and assigned a PID. Unlike user processes, they do not have any address space mapped, and run exclusively in kernel mode, which makes them non-interactive. Various kernel subsystems use kthreads to run periodic and asynchronous operations.
All kernel threads are descendants of kthreadd (pid 2), which is spawned by the kernel (pid 0) during boot. The kthreadd enumerates other kernel threads; it provides interface routines through which other kernel threads can be dynamically spawned at runtime by kernel services. Kernel ...
@@CyberGizmo None of which has anything to do with the POSIX-specified behaviour of userland processes, which is what we are discussing here.
Thanks man
Welcome, Pro
Oh what did oracle do?
Great video, and your presentations are generally very good. Unfortunately I find the animation on the screen behind you very distracting. It is like those advertisement banner which constantly attract focus. Much better than background music some idiots use in lectures, but still.
I really don't like systemd, yeah the init wars have ended. I'll deal with systemd. But i don't have to be happy with it. Openrc is a lot easier. However, I'm currently in the planning stage migrating our servers from Funtoo to NixOS. So I'm condemned to systemd.
Today I tried to deploy a NixOS flake on my laptop and it's blocking when booting up. How do I debug this with systemd? I have no idea. With openrc i could manage. Oh well. The world's moved on, so I'll figure it out.
How about
man systemd-analyze
just as a starting point ...
A. Tanenbaum had a go himself at that kind of OS architecture, it was called Amoeba
I used to init 3 to install the nvidia drivers( after booting nomodeset), but in Fedora 36, it does not work for some reason and you have to get patched drivers.
Why? I'm not super familiar with Fedora, but in most distros you can just install the nvidia driver package like any other package at normal runlevels, then reboot or load the modules manually.
@@HenrikDanielsson I used to prefer to install the nvidia driver from them. In that case you have to disable nouveau to do it. In FC36 there is a change to the frame buffer in EFI model so it has not been resolved with the nvidia provided drivers yet.
How do you call a hanging process and gives me timeouts in dmesg logs and spawns a lot of warnings about timeout?
For instance some wifi drivers freezes the whole system and you can't kill them. It's no a zombie process, the main process is running, how can we kill it (without force power off) ? - Kernel sysrq magic key for restarting the kernel doesn't do anything in this case.
I would call it a bug
I would've approached this topic somewhat differently, but this isn't is distressing as your video about X11 and Wayland. I noticed nothing that I would consider a significant inaccuracy.
System-d calls its bootloader module system-d boot nowadays. It only works on UEFI systems and overall it is a neat addition in the handful of distributions that have support for it due to it being relatively lightweight and fast compared to grub.
How is GRUB not fast? Are you comparing milliseconds here?
Damn, an awesome video. Absolutely agree on binary logs in systemd, i remember using it for the first time and wondering why i had to run journalctl to display the logs, was digging around to find the actual log files and just read those only to find out logs are binary, was like wtf, why would anyone do that xd
Binary logs are MUCH faster to process, and will also take significantly less space. So yeah, it's a pretty good change. You can pretty easily dump the logs into plain text if you actually need it, so there's no real tradeoff.
@@gogudelagaze1585 There is a change though: you have just added one more piece into your system, the log parser. Granted, most of time it is not a big deal. But in some cases it will be a pain in the ass.
And on the other hand.... I can say that with processing and storage capacities nowadays, it doesn't matter to have log files in binary or text. There is plenty of processor power and plenty of storage.
Now imagine:
You have only one machine and it is not working for some reason. You decided to take the ssd out and look the system logs with a friend's machine. But your friend uses windows. If your logs are simple text files, no big deal. If your files are binary, you won't be able to read them.
@@joaomaria2398 Well, you can probably boot of a liveusb and inspect it through that, but that's a fair point.
What’s cool is things like automatic rotation, and also the fact that the timestamps are timezone-agnostic. So you can display the logs according to any timezone you like.
Absolutely agree with you - completely illogical design in systemd.
I still don't get how this is superior to the Solaris Service Management Facility (SMF) introduced almost 20 years ago.
Well, Lennart had heard of it, and MacOS's version, and Upstart, and knew he was smarter but nobody at Redhat took him seriously, so he went on holiday and came back with the first version of SystemD. Fait-accompli.
Bootloaders and UEFI give headaches for many Linux-users. Installing a bootloader is easy enought but you can get many problems after that: custom kernels with not enough space for the EFI-partition (had that once), a GRUB-update which makes grub-customizer not work anymore, Systemd-boot which gets confused after installing a custom kernel with an invallid name, but GRUB handles it fine, good old Windows (yes, that is sarcasm) which decides to add a partition...
DJ Ware, I recently saw your 2 years old video in which you claimed that Linux has plenty of less than optimal design. It would be interesting if someday you would go in depth on what you would like to see being done different for Linux or any future OS, if you haven't done that already. It seems to me that making a new open-source OS get traction should be easier than what it was for Linux because that new OS could make sure that all software for Linux runs. I don't suggest it is easy but it should not be as much a struggle as it was for Linux to get those Windows-programs to work.
It became more and more annoying , year after year for *BSD users just because so much of the software out there, starts to be dependent on systemd. For instance Gnome has some hard dependencies over systemd, which makes the life of the *BSD package maintainers literally hell. At some point, we on the BSD side, eventually will not have access to some major *nix/linux packages and that's pity. I am not going to make a tragedy out of this, just want to point out very clearly that systemd philosophy is not doing any good for the people outside linux community, even without it's direct presence.
And that is truly a tragedy and a one more nail in the coffin of systemd as far as I am concerned
Great video !
I couldn't find anything on "zombie walker", it feels sus. In Linux zombie processes are used to hold the exit code for the process and graduates to the parent's parent when the parent ends, such a walker would need to go around killing running processes?? The other way to reap a zombie(happens for every process, they are zombie even if only for a few clock cycles) is for the current parent to call `wait` reading the exit code, pid 1(being an elder to everyone) should always be reading exit codes.
It was used in Unix System V
I switched from Debian/Ubuntu to Linux Mint because with systemd it did not finish booting on my hardware , Mint were even later in switching, but when they did AMD hardware worked without problems
did you mean pid = 0?
no, pid=1
pid=0 is always the kernel itself.
Uh? Id pid1 dies the kernel will usually panic, not restart it.
You keep saying that systemd will boot faster than sysvinit but... Sure, sysvinit took longer to boot up back when it was being run on a P-III. How long do you suppose it would take to boot a P-III on systemd? An hour?
The problem with systemd is feature creep and bloat. And it is part of the corporatization of Linux. Frankly, I don't even want to see, "The year of the Linux desktop."
When I first started running Linux I started with Linux Mint 9 or 10. Everything _just_ _worked_. Man, do I miss those days. KDE was nice and easy to customize in whatever way you wanted to. Now? Not so much...
20:28 "the world WAS moved into", comply :)
I seriously used to be on the anti-systemd hypetrain without even knowing what the hell that is 😅 Nowadays I just wish for a system that works 🙏
Same is true of all the systemV and Wayland trolls and the flat earth and creationism. They use complex words to make you think they know what they are talking about but at the end of the day they don't have a clue and their arguments are defeated with simple education.
Same here. I find non system d distros usually work better for some reason.
@Konrad Koeppe this is an example of what I am calling a dumb comment.
First what is "work better" and how do we benchmark that?
Second it is next to impossible "work better" comes down to systemd considering the small part, if any, systemd plays in whatever task you are doing in user space.
Then there are the thousands of apps in a typical insall the vast majority have nothing to do with systemd.
And last Considing the list of distros that use systemd include arch, Debian, mint, manjaro, suse, rhel, Fedora, and ubuntu your claim becomes unbelievable as the list includes a range of distros the run the gamut from very stable to bleeding edge and arch at least is highly customizable.
Thus comment is dumb and uneducated and impossible to benchmark.
@@leopard3131 I have two systems that system d based distros do not work well on. Sorry but that's a fact in my world. Various things don't work no matter the distro. Found several non system d distros and both computers work well. Not saying system d is the whole problem. I even stated it was my experience. So sad your so negative.
@Konrad Koeppe I am in no way negative I am trying to dispell the FUD people keep posting about systemd. So far we have the evil corporation RHEL crowd and the "Unix philosophy " crowd and the mystery secret person who claims to know more than the Debian technical board (or the Arch board or the Ubuntu board) and lets not forget the ones who deny the reasons systemd was built and then there are those who say well if Slackware or bsd uses it it is good with them although to my knowledge neither bsd nor Slackware have done any sort of technical review or at least not a public one and we have people like you who have some mystery problem but conclude systemd is the cause.
I can at least accept the people who tinker with alternates to systemd or who are at least willing to admit it comes down to personal choice. Obviously in these 2 groups they have no need for systemd nor are they systemd experts.
I did not see a single technical post here that addresses the task or problems with systemv that arise in modern computer science or business that systemd is not the best current tool as evidenced by its broad adaptation over the alternatives such as upstart.
This scheme can only work in countries with a few large firms that the govt heavily subsidizes and posess a high degree of economic nationalism. It also serves to entrench the established economic oligarchy. It wont work in the US because entrepreneurship is so high and is the engine of growth. Expecting a small firm to pay wages an benefits of a large firm.
Please don't use term "interrupt" when you mean a "signal". Parent gets a SIGCHLD signal to notify it to reap children. In general, user-space programs don't receive (hardware) interrupts.
There''s an annoying term overloading. With "hardware interrupts" sent by the hardware, interrupting the program (like when receiving a signal), and likewise with signals as an IPC mechanism and signaling as an action of notifying someone. And also to some extent, software interrupts to call kernel from user-space (especially if you came from DOS programming space).
Just like process vs task vs thread. It's all over the place.
Remember when system was bricking motherboards pottering said that is not a bug
Fact Red Hats main customer is the United States defense department
They wanted a back door into lanix tour Falls refuse to put one in the kernal for them
SO
They had Red Hat do it for them in system d
As if SELinux from the NSA couldn’t already have done that ...
@@lawrencedoliveiro9104 why does the CIA use slackware then
Most current Linux systems choose systemd.
The lightweight Peppermint used to be based on Ubuntu, which switched to systemd. Now Peppermint had its latest version based on Devuan and Debian. Debian is, the replacement, rebelling against systemd.
Uncertain why so many Ubuntu based systems are now sometimes switching to Debian instead. Linux Mint is simultaneously running their Debian version, as well as their mainstream Ubuntu version (LMDE is its name).
Both Mint versions are staying with systemd, afaik.
There are also other Linux controversial "fashions". Perhaps someone could explain this further. Some Linux systems specialize with Gnomes GTK (GNOME tool kit).
Most Linux systems choose af as ifaik, the latest version of QT. Some Linux systems offer a confusing system which use a confusing mix of both Qt and Gtk. Then the applications sometimes offer two versions of the application; over for gtk, and the other for qt. End-users like myself missy decide which of these two choices to use.
This was qt or gtk choice gets further complicated, because sometimes still, the graphical display of the fonts and windows are not perfect enough. Luckily these bad displays are now disappearing.
Debian has by default been using systemd since Jessie was released in 2015, about the same time Ubuntu switched, and both are still using it with no plans to change.
Regading Qt vs Gtk, you don't have to choose and both can be run simultaneously, they are just libraries used by whichever desktop environment and/or programs you want to run. Sure, they don't always look the same, but that doesn't really matter much. Some distros may only have one by default, typically the one their preferred desktop environment is based on, but you're pretty much guaranteed to end up installing both since many popular programs either don't agree with that decision or simply happened to know one of them better than the other.
The switch to Debian is more to do with snap packages than anything about the init system.
yeah....but most current linux systems are nothing but fattened or striped clones of the other linux systems
Binary logfiles -> no go, security issues -> check, already had this
And now the rat has left the ship.
You forgot various distros that do not use systemD and wrote artie instead of artix... all distros without systemD are superior compared these with shitstemD included. Also some distros like Puppy and alt linux offer systemD free version. Obarun, Puppy, Salix, Adelie, calculate linux, tinypaw linux, 4m linux, black artix, slitaz linux, Guix, heads linux, Chimera and batocera are all special distros some of them do not exist on systemD...
and show some of them wherever you like
search for systemctl that behaves like having systemD and 66suit that implements other inits to be more complete than systemD...
Yep, I did...however if i had listed them all most of my audience would have fallen asleep. As someone once said years ago, you can give them the books, explain the process, but they eat the pages instead. Thanks, RHTORAS.
@@CyberGizmo but you can show some of them in your channel... people do not even know some of them... and really need to learn them... it's a shame people are limiting theirselves on ubuntu arch and fedora... or even gentoo
Arch can also be run without SystemD, it's in the wiki how to do that.
I think you're a little off in your discussion of orphaned processes,. First, fork() is involved but exec() is not as it simply inherits the process slot. When the parent process exits, the child process is "reparented" by making PID 1 its parent. The use of namespaces complicates things but follows a similar approach. When a process is reparented, it does *not* get a signal, it just keeps running. If the parent died because a signal was sent to its control group, often done with control-C, and the child is in the same control group, it will get a signal, too, which might kill it. Zombie processes are processes that have exited but whose parents have not "reaped" them, i,e. the parent has not issued a wait() that returned information for the exited process. Since the init process spins waiting for orphaned processes you will practically never see one in a zombie state.
> When the parent process exits, the child process is "reparented" by making PID 1 its parent
Not true in today's Linux. The closest ancestor which has its PR_SET_CHILD_SUBREAPER flag on becomes new parent of said process.
POSIX behaviour is indeed for PID 1 to become the parent of orphaned processes.
Linux offers some extra options, in the form of the prctl(2) call, to modify this, if you want. Otherwise the POSIX behaviour is the default.
@@lawrencedoliveiro9104 Ah, mentioning prctl() is an excellent addition to the discussion. Thanks!
Umm, just to be sure, I rechecked the POSIX spec, and it doesn’t actually say anything specifically about PID 1. All it says is that the parent is initially the process that created the child, and that “After the creator’s lifetime has ended, the parent process ID is the process ID of an implementation-defined system process”.
/bin/sh as init.
"Responding to events" is the only feature of systemd that I find potentially useful. And also potentially dangerous.
On the one hand it's certainly useful to be able to trigger responses to changes in the environment. However, I have enough experience of Windows mysteriously launching tasks that I didn't ask for, without explanation or even an easy way of diagnosing, that often cause serious issues, and they're so heavily obfuscated by the "convenience" of automation that I'm rendered helpless and at the mercy of Microsoft. Windows is exceptionally good at automating it's own destruction, and with it my time and data.
I would much rather forgo this "convenience" and retain full control of the system.
And that, sadly, is the only thing that's even remotely interesting about systemd. The fact that it has assimilated the entire Linux ecosystem is an absolute travesty.
It doesn't surprise me in the least that Poettering defected to Microsoft. They were made for each other.