systemd Clocks In At More Than 1.2 Million Lines

[aht0]

Its using pkill on PIDFILES Linux does not have any protection here. So if process dies while you trying to kill it and that PID gets recycled you have a kill race. Yes this can happen when you are attempting to restart a service because you think it locked up.

End up killing the wrong process is not something that is easy to do at will. But it will kind of Murphy law you. Its not just kill either if you use signals between processes thing can also get wacky.

Frankly, does not look like a situation I should meet more often than winning a million in lottery. Unless there is gazillion processes, software isn't quite stable and/or I somehow try to mass-kill many processes at once. Is the latter reason causing timeouts when trying to shut down systemd Linux machine? I remember it completely baffled me when I used OpenSUSE awhile a go - boot was actually fine but something during shutdown ALWAYS timed out..

[oiaohm]

Slackware still is using rc.

I am gonna install Slackware again somewhere to see, what 'wrong processes' get killed so persistently. Been long time.

Its using pkill on PIDFILES Linux does not have any protection here. So if process dies while you trying to kill it and that PID gets recycled you have a kill race. Yes this can happen when you are attempting to restart a service because you think it locked up.

End up killing the wrong process is not something that is easy to do at will. But it will kind of Murphy law you. Its not just kill either if you use signals between processes thing can also get wacky.

[aht0]

Old robust RC was in fact used by slackware and with a Linux kernel end up killing the wrong processes. Yes runit on Linux kernel also kills the wrong processes.
OpenRC half kind of works with cgroups.

Without systemd developers cgroup would still be cgroupv1 and still broken to hell. Without systemd developer proven past question there is no way at all to do pidfile safely on Linux is the reason why 5.1/5.2 Linux kernel are finally getting fixed.

Slackware still is using rc.

I am gonna install Slackware again somewhere to see, what 'wrong processes' get killed so persistently. Been long time.

[aht0]

This is not the history. Sysvinit that Linux used did end up hosted at GNU but early Linux this was not a gnu project.

Linux has had a userland mostly made up of GNU parts. But even right from the start there were non GNU parts.

Also if you look in the tools directory of the Linux kernel not everything in there is Linux kernel only. The Linux kernel has never merged stuff in like early freebsd did and the other BSD followed that lead.

Slackware used and is still employing BSD style init. It was one of the first Linux distros (excepting even earlier SLS it was based on). It did not even have SysV compatibility until 2000 or so. I was studying IT back around then and we used Slackware during courses. SysV compatibility appeared around then.

SysV was chosen by later distros for it's perceived advantages - which now seem to be have turned into purely "SysV init is baaaad..". One of them being complaint that service management sucked. Instead of fixing it, just using BSD style init or any of the alternatives, no, NIH - we need brand new super project.

No this is not true. late 1993 freebsd was the first time they did what was called self hosting. This was basically bring the individual parts of the core under 1 single project. Before that you have split tar.gz files making up BSD/OS in early 1993. Yes the merge its that far back the current BSD users forget it happened.

Exactly the double standard much.
People complain about systemd merging stuff into 1 package this is exactly what world BSD did with kernel and all in 1993 yet people meant to migrate to a BSD to get away from systemd merging thing. So pure double standards.
BSD different OS made using it source show it make sense to merge the init stuff up into a single package so it all is tested with each other and works.

FreeBSD itself appeared first time officially November 1993. It could not have done any self-hosting earlier. BSD/OS (or BSD/386) was separate distinct proprietary operating system, which finally died about ten years later. I don't know, maybe you thought 386BSD (free), which was indeed 'parent' for NetBSD and FreeBSD. I took a look at it's source, what's available of it (partial public repo online), and it looks like it followed the same pattern: kernel and world developed together.
Those 'split files' you do see even today: https://download.freebsd.org/ftp/sna...4/12.0-STABLE/ - I would thus not be putting much stock in your claims about things being done differently on early nineties.
Split up archive files make it easier for installer to install/unpack files according to certain pattern (like debug kernel vs ordinary kernel, ports sources, system sources, lib32 compatibility libs and so forth). It makes sense separating such files into distinct packages.

[oiaohm]

Why? When there is demand, there are providers. Multiple providers are always better than single mega-monopoly. It's been proven over and over, not only software-wise. It's time-proven tenet of economy.

This is not always true. Multiple providers causes a particular problem will be explained latter.

Now, one corporation has next best thing to vendor lock on GNU/Linux or what's left of it.

Systemd is resulting in the foundations being fixed this will come clear latter.

You only talk about sysV init and it's deficiencies - there were alternatives. Even on BSD I do have alternatives to old robust RC: runit and openRC.

Old robust RC was in fact used by slackware and with a Linux kernel end up killing the wrong processes. Yes runit on Linux kernel also kills the wrong processes.
OpenRC half kind of works with cgroups.

Sorry, but have you (systemd devs) done any better? systemD is almost 10 years old AND yet you still blame kernel. Instead of building knowingly on broken kernel functionality and blaming the kernel - your time would perhaps been better spent sending kernel patches upstream and trying to fix those in advance - only then building your thing.

Without systemd developers cgroup would still be cgroupv1 and still broken to hell. Without systemd developer proven past question there is no way at all to do pidfile safely on Linux is the reason why 5.1/5.2 Linux kernel are finally getting fixed.

You seem to have completely forget, which project is the more important one. Without kernel, systemd would be meaningless, at least as long as you haven't come up with systemd-kernel of your own.

I have not. There is a basic problem with sysvinit/runit/upstart... these were multi source assemble solutions. So when there was a issue did the user import a bad version of udev or some other incompatible part or init solution is wrong or is it a real kernel issue.

Systemd pulling the core init part into a single project means when you have a Linux kernel defect that systemd combination of parts is finding fingers can only be pointed in 2 directions either systemd is wrong or the Linux kernel is wrong. This has resulted in many hot debates on linux kernel mailing list and has resulted in a lot of core issues being fixed.

Basically systemd is providing the Linux kernel with the self host test freebsd has had since 1993. As in a bundle of software that should work. Freebsd merge is still better because you get down to 1 party. But being at 2 parties is better than the 20+ before systemd.

From user's perspective, there is some difference to whether 'broken thing' is new or old. It's still broken but 'old broken' is at least familiar and can be worked around using past experience. With 'new broken' you'll have to spend extra time finding ways around it. For most of us, computer is a tool for doing things. Fixing the tool does not enter into things we want to do before doing our jobs.

If the old broken is made up of multi parts doing a massive game of finger pointing the faults are never going to fixed. So the result has been before systemd you have been working around the same defects over and over again never fixing them. Systemd causing the kernel to fix stuff means in future lot of defects will disappear for good.

Patched a patch of a patch covering hole in the wall, or what?

With cgroupv1 vs cgroupv2 is basically systemd triggered a complete wall in the Linux kernel to be ripped down and basically rebuilt from the ground up fixed. Same with what is going on with file handles for sending signals to processes this is basically another rebuild. There is a long list of sections that systemd has triggered to be rebuilt from the ground up because finger pointing could not work.

To quite Australian politician "the recession we had to have" Paul Keating . "Systemd is the init system Linux had to have" after the Linux kernel internal issues are fixed up then we can restart the init solution fight this time instead of having stack broken badly behaving init systems in fact have init systems that do work.

Basically just like a recession once you get out the other side and everything fixed up then you can get rid of it.

[oiaohm]

BSD is NOT like GNU/Linux. LINUX is a kernel ONLY. GNU provides the userland. That is the biggest, most obvious difference between BSDs and GNU/Linux.

This is not the history. Sysvinit that Linux used did end up hosted at GNU but early Linux this was not a gnu project.

Linux has had a userland mostly made up of GNU parts. But even right from the start there were non GNU parts.

Also if you look in the tools directory of the Linux kernel not everything in there is Linux kernel only. The Linux kernel has never merged stuff in like early freebsd did and the other BSD followed that lead.

BSD has and always will integrate the base set of utilities with the kernel, with the design decision that this provides tight integration. Get it?

No this is not true. late 1993 freebsd was the first time they did what was called self hosting. This was basically bring the individual parts of the core under 1 single project. Before that you have split tar.gz files making upBSD/OS in early 1993. Yes the merge its that far back the current BSD users forget it happened.

So FreeBSD can have everything in one project and systemd can't ?

Exactly the double standard much.

People complain about systemd merging stuff into 1 package this is exactly what world BSD did with kernel and all in 1993 yet people meant to migrate to a BSD to get away from systemd merging thing. So pure double standards.

BSD different OS made using it source show it make sense to merge the init stuff up into a single package so it all is tested with each other and works.

[aht0]

FreeBSD devd when you get the project its from is quite a monster.

https://github.com/freebsd/freebsd/tree/master/sbin/devd

Longest C file in the folder is 1183 loc.

Yes devd is in the Freebsd project that happens to include everything you need to boot the system from the kernel to bootloaders to file system validation tools.

WHAT? It's a user space daemon...

Configuration errors in sysvinit done by distributions could end up in a fork bomb so claiming bogs down slower than sysvinit ever managed is wrong if you include distribution errors in configuration. Systemd does put an upper limit how bad a distribution configuration screw up can be.

You missed the fact there are race conditions systemd is in fact dealing with that are in fact coming from the Linux kernel implementation of processes.

Said upper limit could exist in other implementations as well. If it didn't, logical conclusion is, it never posed sufficient problem to be added.

Further logical extrapolation leads to another conclusion: that the issue might be 'create some problem, solve it successfully, justify existence based on solving said problem'.

Hard reality you cannot compare systemd issues to darwin/lauchd of apple vs freebsd boot scripts. Yes launchd on darwain is better performance than freebsd current solution. Why you cannot compare is systemd is dealing with a defective process handling in the Linux kernel this increase your overhead a lot. Or if you don't increase overhead and ignore the elephant in the room that pkill killing processes using pidfile in fact killing the wrong process randomly. You use sysvinit and claim faster but it faster by random-ally killing the wrong process.

With how broken the Linux kernel is systemd is the best option at this time. Now Linux kernel 5.1 or 5.2 someone should be able to implement a pkill program that in fact works right.

1) projects with only 1 developer key to boot the system need to be merged into a large project. Like it not systemd did this first. Maybe some of the parts like udev that were merged into systemd should have been merged into kernel tree. BSD had done this merge before a single line of code was written in the Linux kernel. So Linux is kind of late to the party on this bundling.

Why? When there is demand, there are providers. Multiple providers are always better than single mega-monopoly. It's been proven over and over, not only software-wise. It's time-proven tenet of economy.

Now, one corporation has next best thing to vendor lock on GNU/Linux or what's left of it.

You only talk about sysV init and it's deficiencies - there were alternatives. Even on BSD I do have alternatives to old robust RC: runit and openRC.

2) Posix/sysv compatible init systems that people tried for over the first 15 years of Linux resulted in developers being userspace and never fixing the low level Linux kernel faults. Freebsd init and kernel are in the same development tree so issues in init that are kernel caused have been fixed kernel side.

Sorry, but have you (systemd devs) done any better? systemD is almost 10 years old AND yet you still blame kernel. Instead of building knowingly on broken kernel functionality and blaming the kernel - your time would perhaps been better spent sending kernel patches upstream and trying to fix those in advance - only then building your thing.

You seem to have completely forget, which project is the more important one. Without kernel, systemd would be meaningless, at least as long as you haven't come up with systemd-kernel of your own.

3) When ever the is change people get upset and totally go back to old broken instead of looking at the replacement and working out what need fixed so their old broken ceases to be old broken and becomes old and fixed.

From user's perspective, there is some difference to whether 'broken thing' is new or old. It's still broken but 'old broken' is at least familiar and can be worked around using past experience. With 'new broken' you'll have to spend extra time finding ways around it. For most of us, computer is a tool for doing things. Fixing the tool does not enter into things we want to do before doing our jobs.

Think about it with cgroups systemd working on a service management system at long last started putting bugs against the Linux kernel and getting those low level issues fixed. Its not only been init systems that have been failing to put bugs against the Linux kernel to fix core defects there are a lot of things that have not be working on fixing core defects.

Patched a patch of a patch covering hole in the wall, or what?

[Britoid]

So FreeBSD can have everything in one project and systemd can't ?

[Bsdisbetter]

Really look again.
https://github.com/freebsd/freebsd this is the project /sbin/devd is in. The same personal who modify the devd in freebsd can also modify the kernel source.
Freebsd the kernel and devd like it or not are in exactly the same project.

https://github.com/systemd/systemd/tree/master/src/udev

Yes if your logic was true. src/udev means that udev is not part of project systemd right because it in a sub-directory.

So lines of code systemd vs freebsd core project that is call freebsd. Yes without question the freebsd one is bigger.

What the hell are you talking about?

BSD is NOT like GNU/Linux. LINUX is a kernel ONLY. GNU provides the userland. That is the biggest, most obvious difference between BSDs and GNU/Linux.

BSD has and always will integrate the base set of utilities with the kernel, with the design decision that this provides tight integration. Get it?

Therefore, utilities that appear in /sbin, /bin etc are just that, utilities.

The kernel source is in /sys

devd is NOT in /sys.

Therefore it is not in the kernel. Get it?

Your logic defies every known concept of kernel source trees and userland binaries. I am not going to explain it further because you are unable to grasp this simple concept.

Your argument is specious and attempts to bolster your other specious and fallacious argument about LOC. Either way, I've explained the BSD concepts, it's up to you to accept reality or continue being delusional.

[oiaohm]

[i cut the rest out tl;dr after this paragraph. Anything else you have to say about bsd is... dare i say, rot...]

What the hell are you on about? devd is not in the kernel, it's a userland daemon. You even linked to its git repository, hint /sbin part... A project does not a kernel make... or vice versa. Boy oh boy.

Really look again.
https://github.com/freebsd/freebsd this is the project /sbin/devd is in. The same personal who modify the devd in freebsd can also modify the kernel source.
Freebsd the kernel and devd like it or not are in exactly the same project.

https://github.com/systemd/systemd/tree/master/src/udev

Yes if your logic was true. src/udev means that udev is not part of project systemd right because it in a sub-directory.

So lines of code systemd vs freebsd core project that is call freebsd. Yes without question the freebsd one is bigger.