SysVinit 2.90 Released With Fixes & Better Support For Newer Compilers

[starshipeleven]

Because not every software package comes with the scripts for your favorite init system. The software may have complicated internal startup/monitoring and not wish to support multiple init systems. So it's nice when they can bring their init system, and you can plug that as one unit into your OS's native init.

No offence but there is no way in hell that I'm letting a service designed for a different init run in another without looking very closely at it and doing some test runs. I've had issues running (admittedly complex) services supposed to run on Debian's sysvinit when ported over to CentOS's sysvinit, just because the system was configured differently and some tools called from the script were giving slightly different answers (screwing up stuff).

I've had less problems mixing openrc, sysvinit, and runit scripts, probably because those don't try as hard to be the sole source of truth as systemd does.

I can't think of a single program that has only openrc or runit script at all, much less those that I would run in a server.

Custom solutions for logging, managing control groups, monitoring health, etc are possible under systemd but you have to fight for it.

Afaik init scripts that call the older logging facilities still work normally, I'm not sure about what issues you have with managing users, monitoring health is so much better with systemd, but again I don't see the issues with the old systems.

Subsystems like udev and logind that could (or used to) be independent projects get lumped into systemd seemingly just to strong-arm people into using systemd

Yeah, udev working fine on its own too, and logind using standard and stable protocols towards the userspace with the stated intent of allowing people to replace it with their own daemons if they so choose. Illuminati confirmed.

It is these reasons, not some internal architechture, that make systemd monolithic.

Being monolithic in this case is not having dependencies and integrating all things in a single software, which systemd (the project) is NOT doing and never did.

If you are calling something "monolithic" and it is not doing the above you are using the word wrong.

[starshipeleven]

Proves nothing other than more distributions use it and/or are forced to use it.

It proves that the distro maintainers, (the people who actually care the most about their distro and the time they spend working on it, have decided to use it.

To the contrary of most users that just take and don't understand, the maintainer know and are invested in the distro.

Core dumps? Where are they hiding?

you have issues reading documentation?

Binary logs - crap can't forward them without installing rsyslog anyway.

What do you mean with "forward them"?

[starshipeleven]

But, i do believe in the Linux philosophy: do one thing, and do it well.
And systemd does not abide by that philosophy.

Yeah, it does not split the init, the logger, the login manager, the boot loader and anything else into different processes, which have their own damon name and their own source code, and communicate over standard and stable interfaces.

If systemd does not abide to "do one thing, and do it well", then neither GNU coreutils do.

All i'm calling out (and many others. maybe not all) is for systemd to be just an Init System. Everything else should be it's own project.
And, with that 'simple' change, i would (gladly) use SystemD. The difference being: gladly, becasue it's already 'my' init system.

Unix philosophy never said each thing should have its own project though (see coreutils above), they were talking about software and best practices for software. Not politics. So while you're allowed to make these requests, it's just your own personal needs.

[Bsdisbetter]

It proves that the distro maintainers, (the people who actually care the most about their distro and the time they spend working on it, have decided to use it.

To the contrary of most users that just take and don't understand, the maintainer know and are invested in the distro.

you have issues reading documentation?

What do you mean with "forward them"?

Let me reiterate for those who have trouble understanding, i dont care what others think of it, i only care about my exposure to it. In an enterprise environment having to work on a systemd server WAS a nightmare. Coming from environments that are unix-lke it breaks every rule imaginable, from the hijacking of pid 1 to core dump 'management'. Having to debug code was horrid. Having to spend hours reading up on where systemd hides core dumps and the commands used to extract/view etc them is time wasting in the extreme. Similarly binary logs are laughable (and broke our audit rules to boot). So some maintainers of a distro like it, more likely because it's common than it's great, doesnt make it great for all. The average click & point user doesnt care anymore than a windows user does of svrman.exe.
Some of us get paid to fix problems and when they occur on linux systems running systemd i baulk at doing them. I simply dont have the time to spend hours reading countless documents to accomplish a task on any non-systemd system that could take me minutes.

So yes, mr passive aggresive, I do have issues reading documentation and learning how to specify 400 options in order to read a simple log.

Oh and go learn about syslog forwarding - try reading sone documentation.

[trek]

I can't think of a single program that has only openrc or runit script at all, much less those that I would run in a server.

qmail?

[oiaohm]

Let me reiterate for those who have trouble understanding, i dont care what others think of it, i only care about my exposure to it. In an enterprise environment having to work on a systemd server WAS a nightmare. Coming from environments that are unix-lke it breaks every rule imaginable, from the hijacking of pid 1 to core dump 'management'. Having to debug code was horrid. Having to spend hours reading up on where systemd hides core dumps and the commands used to extract/view etc them is time wasting in the extreme. Similarly binary logs are laughable (and broke our audit rules to boot). So some maintainers of a distro like it, more likely because it's common than it's great, doesnt make it great for all. The average click & point user doesnt care anymore than a windows user does of svrman.exe.
Some of us get paid to fix problems and when they occur on linux systems running systemd i baulk at doing them. I simply dont have the time to spend hours reading countless documents to accomplish a task on any non-systemd system that could take me minutes.

So yes, mr passive aggresive, I do have issues reading documentation and learning how to specify 400 options in order to read a simple log.

Oh and go learn about syslog forwarding - try reading sone documentation.

For me it solved more problems that systemd caused. Yes it took awhile to get use to the differences but having everything nicely cgrouped so known that services had properly stopped instead of having the random lost process holding a file somewhere causing service to bust.

I found systemd no worse than changing from sysvinit Linux to freebsd and their bsd init. Both required a lot of documentation reading. I guess you were not taking care of a mix of BSD, Solaris and Linux.

[starshipeleven]

qmail?

did Openrc and runit even exist in 1999? qmail was used with sysv back then.

netqmail (which is the updated version) has a systemd unit, and before that it also had a sysv script https://packages.debian.org/jessie/qmail

[starshipeleven]

Coming from environments that are unix-lke it breaks every rule imaginable, from the hijacking of pid 1

It's an init, it's supposed to use PID1.

to core dump 'management'. Having to debug code was horrid. Having to spend hours reading up on where systemd hides core dumps

It takes around 3 minutes to find that info.

So yes, mr passive aggresive, I do have issues reading documentation and learning how to specify 400 options in order to read a simple log.

Are you trolling? just writing "journalctl" dumps all the events on stdin, from there you can hack around to filter the output with pipes to grep and awk just like you did with older syslog.

Main difference is that you can use journalctl arguments to filter stuff instead, which is faster, much faster if you have a ton of logs.

Oh and go learn about syslog forwarding - try reading sone documentation.

I asked because it's something trivial to me, maybe you were talking about something else.

change ForwardToSyslog= to "yes" in /etc/systemd/journald.conf, then systemctl restart systemd-journald

[oiaohm]

did Openrc and runit even exist in 1999? qmail was used with sysv back then.

netqmail (which is the updated version) has a systemd unit, and before that it also had a sysv script https://packages.debian.org/jessie/qmail

rough times of first used releases in somewhere production around the world.
1997-2001 daemontools Yes there are disputes on when that classed as functional. Yes 1999 with qmail you saw daemontools around qmail trying to address sysvinit limitations.
runit 2004
Upstart 2006
Openrc 2007
systemd is 2010

GPL sysvinit is somewhere around 1992.

https://blog.darknedgy.net/technology/2015/09/05/0/

For a long time ever few years someone attempted to write a new init system. Majority have disappeared into history. Yes qmail developers have been known to try quite a few of them.

[trek]

did Openrc and runit even exist in 1999? qmail was used with sysv back then.

may be too old for you, but runit is the reimplementation of daemontools, required by qmail