systemd Clocks In At More Than 1.2 Million Lines

[nomadewolf]

In the "old days" linux was for power users only - People that understood or wanted to understand how things work.
Linux was very user friendly, but it was picky about it's users.

Then came the drive to bring linux to the masses.
Slowly but surely they took away the character of what was "linux" to make it more "windowsy", so that people with limited capacity can still feel at home.
The current state of "Linux" is a bunch of bloated applications trying to mimic windows.

Systemd is just another (albeit huge) step towards taking control away from power users.
If you like systemd you are not a power user, you are just someone who wants a free OS.

Sadly the power users have to start looking elsewhere.
I recommend they look at "Alpine linux" and "Void linux"
I won't even recommend Devuan since its based on Debian, who has lost its way.

The world urgently needs a new OS.
I suspect that if that OS ever sees the light, it will be written in zig.

The beauty of Linux are all the flavours avaliable to us!
That's the true spirit.
More flavours mean more choice, and that is always good.

[skeevy420]

and here was me thinking this thread would not deliver fireworks since hreindl got banned

It's a thread about systemd. That's all that I should have to say.

[grumbert]

and here was me thinking this thread would not deliver fireworks since hreindl got banned

[oiaohm]

Diagnose done, after administering the cure and all the problems fixed, we can then happily ditch 1,2M loc diagnostic software? :P
Just kidding.

I am not going to try further autopsy on the topic. Just happy to be in non-Linux camp.

LOL this is such a joke of answer. Process leak issues with background services effects OS X, Windows, BSD, Linux ...

Unless you are using SMF from Solaris or Systemd init at this stage you are lacking the tools to deal detect the defect.

Really we cannot ever 100 percent ditch the diagnostic software. With cgroup and pidfile stuff fixed up items like openrc could be built and have the required diagnostics to detect this issues early.

Also the 1.2 million lines of code in systemd is way smaller than freebsd min selfhost. If you are suggesting BSD as option you are a hypocrite because it has a large block of diagnostic software..

This is the laugh this is the hard reality of systemd its find issues that have been silent faults in background that random-ally hit people. Systemd is also working on the frameworks required to address these silent faults.

aht0 serous-ally look closely at your current solution how would you find a process leak event and know you are going to need to fix it. Under freebsd you will have to put services in jails to find out. Out the box you will not be informed you have a problem.

So since aht0 is happy to live with random hard to diagnose problems I cannot stop him/her from being that foolish.

[aht0]

Those timeouts that systemd does on shutdown is not a defect in systemd.

The cause of why systemd does timeouts on shutdown and service stop/restart is that it detects due to cgroups that processes are still running. So systemd runs the stop command on a service on shutdown then checks if all processes owning to that service have in fact stopped if not it waits after X amount time it brute force kills it.
..

Systemd timeout messages on shutdown are just symptom of non systemd defects. Yes defects that sysvinit would silent hide until the day it catches you where you end up reboot a server instead of just restarting a service because a service will not restart.

Yes these messes is why I say systemd is the init system we had to have. One of the results of systemd was a lot of sysvinit scripts in fact got fixed or deprecated with a systemd unit file that is also fixed.

Diagnose done, after administering the cure and all the problems fixed, we can then happily ditch 1,2M loc diagnostic software? :P
Just kidding.

I am not going to try further autopsy on the topic. Just happy to be in non-Linux camp.

[boxie]

What if the user has no smartphone or another computer to be able to Google? (remember that his computer is borked and can't connect to Internet)

Sure, let's play the mitigating game. We can come up with ever increasing silly scenarios and how we get out of them.

This user had access to install media - so they could have live booted it, done the google search and fixed their problem.

Not knowing is fine (how would we ever learn anything knew?). Being able to figure out what is going on is a real learnt skill - and I understand that too.

Annoying problem? sure (I'd be annoyed too). But pining for the "Good Old Days (tm)" and forgetting that there nightmares there too is a little on the nose.

[oiaohm]

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..

Those timeouts that systemd does on shutdown is not a defect in systemd.

The cause of why systemd does timeouts on shutdown and service stop/restart is that it detects due to cgroups that processes are still running. So systemd runs the stop command on a service on shutdown then checks if all processes owning to that service have in fact stopped if not it waits after X amount time it brute force kills it.

Lets look how sysvinit and the like handle it.
On shutdown.
1) sends all the services running stop in order of the kill number.
2) After all services have been sent stop run a killall to clean house.
Please note if the last process to get a stop order next operation is the killall by sysvinit there basically no delay between killall clean up coming. Systemd changes this to a predictable delay. Yes this is one of the cause how sysvinit at times screwed over databases delayed by IO for some reason to be killed before final writes were done due to no delay.

Next is kind of worse.
You attempt a sysvinit service restart and the service fails to restart. There is a leaked process holding something the service needs to restart. Yes systemd by systemctl doing a restart on something like this you would see a timeout as well and the service be successfully restarted.

Basically systemd using normal sysvinit scripts if you are seeing timeouts you sysvinit scripts have a defect that needs fixing.

Systemd turns what was a silent failure on shutdown with sysvinit into a loud message making failure with those timeout messages. That failure does not just effect the services with that problem at shutdown it also effect those services when ever you wish to restart them.

This is some of the problem. People complain about the shutdown timeout issue of systemd without think maybe systemd is right here might pay to research why. Systemd shutdown timeouts is point you to broken init scripts.

For the complete time I run systemd I have not had a single shutdown timeout but my init scripts had been audited well before using PID namespaces for process leakage. Process leakage has been insanely common defect causing random issues well before systemd existance.

Systemd timeout messages on shutdown are just symptom of non systemd defects. Yes defects that sysvinit would silent hide until the day it catches you where you end up reboot a server instead of just restarting a service because a service will not restart.

Yes these messes is why I say systemd is the init system we had to have. One of the results of systemd was a lot of sysvinit scripts in fact got fixed or deprecated with a systemd unit file that is also fixed.

[aht0]

50 to 18. I switched to systemd in my Arch install now, and I can finally:

- Mount my disks without root (Artix can't do this)
- Power off from the desktop (without logging out)

I believe you could do either from Artix too. Polkit & udisks/udisks2 for the former, systemd-logind & polkit for the latter (Edit: somehow escaped me that you initially didn't use systemd. In that case polkit/upower combo would probably work, it does for me in BSD. Combined with doas but you could replace it with sudo and give your user shutdown/reboot rights. Should enable powering off from desktop)

[Bsdisbetter]

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.

Look, you're digging a deeper hole in which to bury yourself. Linux was and is a kernel. The other stuff is fluff.
Unix/UNIX/SYSV and then BSD was kernel plus userland binaries, ALWAYS.

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.

Again, what the hell are you talking about? "self hosting"? "1 single project"? This is just plain gibberish.

I've been using *BSD since 386BSD with my first exposure being Unix/BSD on Pyramids, I've seen the history unfold. I remember loading tapes of the thing.

You're talking nonsense.

The kernel has always been the kernel. Your attempt to obfuscate your argument into one of "the kernel" equals "the project" is just plain desperation.

If I can recall correctly, the original BSDs had a /src directory rather than a /sys but apart from that little has changed in structure, even across multiple branches, though I do admit not using openbsd at all.

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.

Again, you're talking nonsense.

Just to make it clear, you're totally wrong. Absolutely.

You're also wrong, as is this topic, in comparing lines of code to some sort of metric of efficiency or waste. It's neither. It's a failed metric that means nothing apart from a meaningless comparison of lines. It's akin to measuring lines in a book and considering their worth based on that fact. Utter nonsense and long discredited by anyone who deals with large projects.

That's why I originally wrote that this article posted by Michael seems to be an attempt to draw out the trolls and ignoramuses. Mission accomplished.

Going back to your original accusation:

FreeBSD devd when you get the project its from is quite a monster.
https://github.com/freebsd/freebsd/t...ster/sbin/devd
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.

If you are suggesting Linux copies how FreeBSD does it you are in fact suggesting merging systemd into the Linux kernel tree.

You are clearly wrong. devd is a userland utility it is not part of the kernel.
But rather than accept your error, you continue with this fantasy.
So, continue believing BSDs are a kernel with all the userland included (nonsensical argument by virtue of the name 'userland', but hey, that's the depth of your argument).


I'm done conversing with you. I can argue points with logical beings but no matter how hard I try, this would not occur with you.

[tildearrow]

I know right?
The other day, my dog came in and pissed on my power supply. It caused my computer with Arch Linux and systemd to short circuit. Solution? Get rid of systemd. How is this unstable garbage even popular?

Instead, I'm going to move to a poorly supported distro that uses out dated bash scripts that are specific to Debian, can't be reasonably supported by the daemon developer themselves, and that everyone hates working with. That way, I can have some sense of stability.

50 to 18. I switched to systemd in my Arch install now, and I can finally:

- Mount my disks without root (Artix can't do this)
- Power off from the desktop (without logging out)