nice bait with systemd crap

i'm talking about a proper init, not one that thinks mounting a partition is a service
(in other words, not one that started as My First Init then went crazy)

order of starting things needs to be determined anyway
you need to mount /lib to load modules
you need to load the graphics modules (driver, drm etc.) to start Plymouth
you need to... actually there is not great many things that need you to explicitly take care of (maybe there was a few 10 years ago)
all those are common sense
it is people that make things complicated, and this is not complicated

can you tell me what "service" depends on ssh or apache ?
(yes i know they depend on the network; while we'r at it i looked at dhcp protocol couple days ago, its very simple)

https://sourceware.org/ml/libc-alpha.../msg00747.html
this is how a proper daemon starts, not with some dumb socket based uselessness

PS shell is a programming language, one that can be made parallel
(shell can even be compiled, idk why gcc and clang people didnt make a parser already)
C is not far and can easily be made parallel (actually easier with fork+exec as you can wait4() multiple children at a time)

They do certainly care.
the network not functioning properly was a big problem.

systemd will/has developped hardware deamons.

systemd-networkd.

there is also a patch (.service file) for NetworkManager that basically tells if the network is running.

So you aren't talking about systemd...
you need root mounted first...
True that.

The initrd I had investigated (fairly deeply) used the command line "root=" to mount root on /mnt. Then it scanned the fstab on /mnt/etc for required filesystems like /var, /usr, /var/log... and mounted them. Once these mounts completed it would do the piviot_root and start the systems init from /sbin.

If one of these required mounts fails it would start a shell so that the admin could fix things (usually a typo in the fstab, or to do fsck runs).
Well, one I ran across was monitoring software - it required apache to be running before it checked or it would report a system failure, even though that would be a "false alarm". And the monitoring checked as soon as it started. In the SysVinit it was a S99... which worked.

A more likely scenario is a database... and potentially clients of that database that provide services that are referenced by apache. I know this is usually just a CGI, but sometimes things get complicated, and it is considered better to separate that CGI from apache (it may require some data access barred to apache).

Yup - dhcp is simple, and works quite well. But it must wait for external service which is tricky for systemd to properly handle.
I know that... Unfortunately, that is exactly the process systemd is not useful for. Remember, systemd is also a process monitoring service, and can restart services if they fail. It is ALSO required to be monitored if a dependency is declared by a "requires" entry for a dependent service.

So what happens is that the service is "started"...the dependant service start - but because "required" service has exited, the dependent service can also be terminated... falsely. Alternatively (if systemd assumes the service is properly running), the service in question may exit for some other reason... and now the dependent service fails because the other service isn't running (a cascading failure).
That WOULD be my preferred method. Even most shells implement a wait using a wait4 now.

Personally, systemd is just a disaster waiting to happen, but the developers keep adding stuff to it: dbus, udev, journald,... if any of those abort, the system has a tendency to also crash. previously it was just a problem with the subsystem (and if syslog failed, the messages were still sent to the console).

Oh, this is very nice. Gonna give it a try.

Slackware already has Runit in the SlackBuilds and it can be used as an alternative Init, but my work with it was limited, but I can say it does work if proper scripts for it are made.

Perhaps eventually if and when a new init is needed Patrick can pull in Runit and look into it's inclusion.

Eudev from Gentoo and LFS can be easily imported if Patrick ever needs to update udev to a newer version that's sane to use.

Why use what we don't need?

2 members found this post helpful.

Note - most of it assumes the system is using systemd as it uses a number of systemd facilities.

Not going to try it anymore then lol

The beginning is fine - it doesn't start to use the systemd based utilities until the last third.

But it does hide a lot of the startup stuff in those utilities.

Don't worry, he only calls systemd utility to clean temporary files which can be trivially rewriten with File class.
He also starts udevd which is already bound to systemd in Arch Linux, however again it can be trivially rewriten to call either Slackware's init script /etc/rc.d/rc.udev or by invoking /sbin/udevadm directly.

That's all. So in fact it does not need systemd at all.

If it was just the simple things those facilities did, I wouldn't have mentioned it. But part of it is some of the monitoring for failures.

The real issue for me was that systemd has a lot of interdependencies that were not mentioned/identified when using those utilities.

And even using slackware utilities would be hiding part of the actual complexity of an init system for any fairly complex desktop.

Init systems for embedded on the other hand are relatively simple. And all init systems start at the same point...

See here.

1 members found this post helpful.

Correct me if I am wrong, but I got interested in the subject and did some reading up on systemd, and if I am not mistaken the fundamental driving force in their architecture is improved VPS performance. They want a linux optimized to run as a virtual machine, and to start and stop very quickly on demand in that environment, right?

The design makes a lot more sense in that context. You can be pretty certain that the DHCP response is coming within a certain number of seconds and just assume success and that will normally work. And saving a couple seconds on boot time would actually be worth some effort, if you are talking about booting thousands of virtual servers every hour it actually starts to add up.

If I understand correctly this is why they are building this entire layer of stuff around systemd instead of using something compatible like OpenRC - squeezing that last second out of your boot time is an incredible waste of time for a traditional user, but again makes sense if you are talking about booting VMs thousands of times an hour.

Can you be a more specific ?
In the code there is nowhere else used any part od systemd than I've described. The script is just a simplified example not 100% emulation of systemd init. It only monitors termination of processes at shutdown and responds to SIGCHLD signal.

And all of it assumes that you've installed Ruby.

1 members found this post helpful.

However this is not an issue in all GNU/Linux distributions known to me or Open/Net/FreeBSDs. Holds true for Slackware, of course