Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

[andyprough]

MX is nice, but I actually prefer antiX with Xfce installed from the repository.

Yeah, antiX is quite likely the best performing, easiest to use distro I've ever tried. I'm just sorry that it took me so many years to find it. If it is maintained and updated in its current form, which there's no reason to believe it won't be, I think I've found a distro home for years to come.

[tuxd3v]

Systemd API is public and documented. If other init systems want to implement it they can.

You see.. that is exactly the problem..
A project looking only to its belly.. that is not a standard

A standard is something that is agreed by several projects.. that is a open API.

[tuxd3v]

shell scripts are fragile, and few of them are tested with multiple shells and non-standard tools (busybox userspace, hush/ash shell).

I don't understand your comment..
If you for example, have a bash script, why does you want it to run with hush/ash shells?

Does you run java programs in a Python vm, or otherwise?
because a lot of scripts are created to work so so, in different shells doesn't mean they need to be compatible with all shells..

you just need to use the correct one for the job..
The same applies to other language/vms, etc..

[uxmkt]

True, the ability to have multiple applications play audio streams simultaneously, the ability to easily move streams to different devices is awesome! I could do that in 2009, on KDE 4 with a simple GUI, almost 9 years before Windows finally introduced equivalent capabilities.

Uh, playing audio streams concurrently is something that worked pretty much forever (that is, '96 on Windows 95, and '03 with alsa dmix).

[k1e0x]

Well, i worked through the years with many OSes all the way from Caldera/SCO to Solaris and recently to Archlinux(since 2012 i think) and i have enough experience with filesystems to trust ZFS with my life. I did try BTRFS several times through the years and honestly is not even on the same league as ZFS is for me because it lacks many features i consider tier 1 (like proper RAID 6/0+ for example) and compared to ZFS is quite easy to make it unusable and also it doesn't work properly with virtualization(huge no no for my workflow).

I did use FreeBSD from 4.3 up to 10(i still use FreeBSD derived tools like opnsense firewall tho) quite commonly on my workflow(as i did use hardened openBSD a lot) but since systemd 100+ i replaced them all with ArchLinux throughout the years and honestly once you do understand how systemd works is better than anything you can find and easier than anything you can find even windows and apple systems(an boy i did use launchd a loooot same as Solaris SMF).

The level of reproducibility, automation and resource management/security systemd provides is unique specially if you are a developer with enough skill to work with DBUS.

Now i do agree with you in the sense most Linux distros just barely use the power of systemd and many for lazyness or lack of taking 5 minutes to read the documentation just add some very idiotic defaults and call it a day that have given argument to the regular haters and i do admit that systemd may seem overkill for someone who wanna just push power on and open firefox and have a minimal understading how code/security works making it seems like systemd use gigabytes of RAM and bloat your hard drives, etc ,etc etc. when in reality is not even close to how it works but yeah FreeBSD is a good OS as Linux is, just use what you can understand better for your workflow and thats it

I do know systemd. I'm a sysadmin. If find it's syntax to be revolting and a difficult way to do things. I tend to avoid it as much as possible when there are other ways to accomplish the same thing. (supervisord job control etc) Helps me keep my sanity.

[oiaohm]

I do know systemd. I'm a sysadmin. If find it's syntax to be revolting and a difficult way to do things. I tend to avoid it as much as possible when there are other ways to accomplish the same thing. (supervisord job control etc) Helps me keep my sanity.

supervisord is one of the tools I hate finding that people have used.

https://serverfault.com/questions/459456/supervisord-leaking-child-processes-launched-through-shell-script

You common end up having to deal with leaking child processes problem. Supervisord cgroup support is basically non existent. Yes the "How to propagate SIGTERM to a child process in a Bash script" instructions are unreliable on Linux this is the kind of hack you find people using supervisord users doing all the time.

If you don't want to use systemd fine. Use something else based around cgroups like docker so that service restart is reliable please.

Items like supervisord need to be put in the broken bin and left there or use a freebsd kernel. sysvinit, Runit, daemontools and supervisord operation pattern is not compatible with the way Linux kernel tracks child processes. The platform that are compatible to use Runit, daemontools and supervisord you don't have systemd. BSD based kernel child process tracking is required Runit, daemontools and supervisord to work right so freebsd, netbsd.... Yes Launchd is the same if you ported it to Linux without adding cgroup support it would be mega busted as well.

There is truly only a handful of service management things that work on Linux that don't leak child processes. Its fairly quick to sort once you work out there is no option bar to use cgroups due to the fact Linux kernel allows child processes to change every other associating value themselves with a parent.

Only way you can do a dependable SIGTERM walk on Linux is to have assigned cgroup value there is no other way hello kernel design limitation.

[k1e0x]

supervisord is one of the tools I hate finding that people have used.
https://serverfault.com/questions/45...h-shell-script

You common end up having to deal with leaking child processes problem. Supervisord cgroup support is basically non existent. Yes the "How to propagate SIGTERM to a child process in a Bash script" instructions are unreliable on Linux this is the kind of hack you find people using supervisord users doing all the time.

If you don't want to use systemd fine. Use something else based around cgroups like docker so that service restart is reliable please.

Items like supervisord need to be put in the broken bin and left there or use a freebsd kernel. sysvinit, Runit, daemontools and supervisord operation pattern is not compatible with the way Linux kernel tracks child processes. The platform that are compatible to use Runit, daemontools and supervisord you don't have systemd. BSD based kernel child process tracking is required Runit, daemontools and supervisord to work right so freebsd, netbsd.... Yes Launchd is the same if you ported it to Linux without adding cgroup support it would be mega busted as well.

There is truly only a handful of service management things that work on Linux that don't leak child processes. Its fairly quick to sort once you work out there is no option bar to use cgroups due to the fact Linux kernel allows child processes to change every other associating value themselves with a parent.

Only way you can do a dependable SIGTERM walk on Linux is to have assigned cgroup value there is no other way hello kernel design limitation.

I've heard that before, I've always found it reliable. (and yes you need to use it correctly, on the actual daemon process not a script.)
It's a bandaid anyhow.. if your services are dying unexpectedly there is something wrong with the system. (in my book maybe not yours)

I believe OpenRC implements this too but they also have their own called supervise-daemon. I'll watch it with my eyes before I trust systemd tho. lol

If you haven't figured it out yet.. I like simplicity. I want to run top on the box and see everything the system is doing in one page and know everything in there.

[tuxd3v]

This can be cgroup-utils, syslog, cron, etc.. in many cases the user/developer api for these services is same even with different implementations. The average user doesn't care about any of this, they care about what udev/networkmanager/pulseaudio/xrandr can do for them. Make that functionality consistent with decent fallbacks over rolling or monolithic upgrades and there would be less distro hopping and more Linux adoption in general. You can have a same-looking networkmanager almost anywhere and it works! More of that please.

The user/dev experience with systemd is worse in some cases (wtf does masking a service need to exist?), and marginally better in others (logging). If you want to make an improvement, you can do it with better APIs all around. There is no need for a user or developer to use most of the functionality in the systemd repo if they just want to deploy a service. Interfacing with the Linux system in general is a much bigger problem, and cgroups is about the last place I would start. Do you know what would be the first? f*&^ing temperatures and cooling!

Agree..

[tuxd3v]

A major problem with systemd alternatives is that they have not moved with the times. They should have developed a shim to read systemd style service files. That way most startup scripts would no longer be necessary and the syntax for services could become standardised.

No one has done this.

So... If the scripts are not needed,
Why in Corporate Midlewares, you have services that to create a deamon for them you need zillions of parameters, environment variables and another stuff more..
How will be implemented, in a very poorly capable, systemd scripting language?

Some people say that scripts are bad, but systemd created a systemd own language for it( the systemd service file, itself is a script.. ).
After all, the user end with, the service file plus the real script( the one that configure the real service ),

So the user end with some sort of 2 services to launch 1 real Service( the systemd service - Loading the systemd service file, and the real service - loading the real application )..

I don't know what would be if they liked..

[oiaohm]

I've heard that before, I've always found it reliable. (and yes you need to use it correctly, on the actual daemon process not a script.)

Depends on what the deamon is. Apache, nginx, postgresql, mysql, cups and many more can themselves run programs that can get disconnected from parent. Monitoring the actual deamon process does not stop process leaks.

So this use supervisord correctly and not using scripts it still breaks. What you have given me here is a works for me arguement digging your head in the sand not wanting to admit it does not work for a lot of groups.

It's a bandaid anyhow.. if your services are dying unexpectedly there is something wrong with the system. (in my book maybe not yours)

Yes it a bandaid. Not all cases do you have the means to run a perfect system. I have run into cases with brother printers closed source driver leaking processes and been really thankful for systemd cgroup solution to kill everything in cups after printing to get everything back in order. So sometimes you know what is wrong with no option to fix it.

I believe OpenRC implements this too but they also have their own called supervise-daemon. I'll watch it with my eyes before I trust systemd tho. lol

https://wiki.gentoo.org/wiki/OpenRC/CGroups

I don't mind openrc as long as you remember to turn cgroups on.

If you haven't figured it out yet.. I like simplicity. I want to run top on the box and see everything the system is doing in one page and know everything in there.

I like different simplicity. I like cgroups around services so I can see what a service has in fact started so I can blame the right service for eating me out of cpu/ram/io. I really don't like when you have a leaked process that is eating you out of house and home with no clue on what service started it as you end up with solutions like sysvinit, Runit, daemontools and supervisord.

I also don't like when thing have gone out of control and I tell stuff to stop and they don't. Think about this when a system is working perfectly I mostly have to-do nothing to it. When I have to work on a system things have gone wrong so I want my debugging of a system that has problems as simple as possible.

I want service management to have set up the information so when I have to debug the problem is straight forwards to see what service was responsible for the disaster so the first time the disaster happens I can fix it so it never happens again without any guess work.

Process leaks cause the following problems that are fixed by cgroups.
1) failure to be able stop/restart service
2) Logging information from a leaked process that does not seam to be associated with anything.
3) Failure to track problem quickly to what service was the cause.

cgroups provide io limitation and memory limitation in systemd as well. This is useful to prevent a service from eating all the resources as well.

By the way the systems I run a top command will most likely give you between 2000-5000 processes so not a single page of top. Yes services with process per connection makes a long list very quickly. Yes 2000-5000 is depending on time of day what one it closer to. My printed out cgroups is under a page. Even your basic desktop setups for Linux get over 200 processes showing in top.

These more complex systems chasing down a process leak is a major pain in the ass without cgroups.

If you can run top and everything appears on 1 page you are running very simple systems. Not all of us are running stuff that simple and once you are not running stuff that simple you cannot manually search down process leaks without the assistance information of cgroups on Linux.

Really a lot of people who are running ultra simple init/service management normally turn out to be using container/vm containment. If that the case supervisord not the correct solution either. Like for example kubernetes has what is called Auto-Healing Containers and the like. So your orchestration system in container/vm solutions do what supervisord/runit/demaontools... do and work in all cases.

I can understand someone wanting sinit that is a super basic init for container. No service management because when using orchestration inside the container you are not needing service management as the orchestration is doing service management properly at the container/vm level Why would I want more service management to deal with in this case supervisord/runit/demaontools/systemd... basically comes duplication in this use case. Worse supervisord does not match the reliability of the orchestration solutions.

See my problem with supervisord now. Simple systems vm/containers its extra part you don't need. More complex systems supervisord useless because it does not produce the information or the tools to debug the more complex solution when things go wrong.

If something provides service management it need to work. I have cases that don't need service management because I have orchestration as well. So my solutions go from very big in process count to very small.

What I am after will work in all cases not just only if I have a few processes per system that I can see in 1 top screen.